Security is key to Crossing Minds. Following the security research community to keep improving the security of your data and applications on Crossing Minds’s servers, Crossing Minds strives to keep your data secure. But security is a shared responsibility between Crossing Minds and you, the user. You need to apply all security best practices to avoid exposing your data and account.

These practices range from how you manipulate sensitive information to whom you give access to your Crossing Minds account and how. Make sure you go through all best practices and in-depth security guides to get a good grasp of what falls under your responsibility.

Securing your API Tokens

Crossing Minds provides short lived JWT token, once you provide your email (resp. service name), password and the ID of your database. Upon successful request, the API will return a JWT token and a refresh token. There are many limitations you can set on your accounts and credentials to ensure that users can only access what they’re supposed to and prevent the crawling of your data. Crossing Minds generates and stores these credentials securely, and encrypts the virtual ones. You’re responsible for how you use these credentials on your end.

For example, you should never have an account with a manager role in front-end code, or in a mobile application, because this source code runs on the end user’s device. You should also be careful when using such keys in your back-end code, and use environment variables to inject your keys or tokens rather than hard-coding them. That adds an extra layer of security in case your source code leaks.

Logins

Login and Specifying a Frontend User¶

If you plan to use the Crossing Minds API directly from your frontend application (e.g. web or mobile), you should use an account with the frontend role. This is to ensure that the credentials exposed in the frontend application do not grant permissions beyond what is necessary.

The steps to authenticate your frontend user are as follows:

• Your user enters your app, calling the authentication endpoint of your backend. If your user is logged-in the backend retrieves their user ID, if your user is anonymous the backend retrieves or generates an anonymous session ID.
• Your backend calls POST login/service/ on an account with frontend role, providing the frontend_user_id or frontend_session_id of the specific user. This returns a JWT and a refresh token that are valid only for resources belonging to this user or session.
• Your backend sends the JWT and the refresh token to your frontend application.
• Your frontend application can use the JWT to manipulate ratings and get recommendations, but cannot see other users’ ratings. The user_id or session_id parameters of the endpoints will be set by default using the value provided. In endpoints where the user or session ID is used as URL parameter, it is possible to replace it with the ~me keyword to use the value provided. For instance GET recommendation/users/~me/items/.
• When the JWT expires your frontend application can use the refresh token to get a new JWT, without having to expose your account password.
• If an anonymous session ends up logging-in, your backend should call POST login/service/ providing both the frontend_user_id and frontend_session_id at the same time. This way the Crossing Minds API will resolve the anonymous session to the user.

Login through Single Sign-On (SSO)

The API supports logging in via SSO through the Security Assertion Markup Language (SAML) standard, so the endpoint POST login/sso/saml/sp/ is available for that to start the authentication flow through OKTA as Identity Provider (see OKTA).

After a successful login, a refresh token will be created without any database selected. Select a database by renewing the JWT from the refresh token.

‍

‍