Learn how to handle your session-token and pass it through your system.
When a user logs in into your application, the UI component stores the session-token as a cookie. Since user authentication is determined by the session-token (see Protecting Routes), it must be accessible wherever you need to verify the user’s authentication status.
By default, the Domain
of the session-token cookie is set to the domain the UI component is integrated on (e.g. if the UI component is integrated on https://www.example.com/auth/ the Domain
will be www.example.com).
Thus, there will be different scenarios where the session-token cookie is available and where not:
This is the simplest scenario. The session-token cookie is available in both the frontend and the backend because they share the same cookie domain.
cbo_session_token
and Domain=www.example.com
Domain
matchescbo_session_token
and validates itIn this scenario, the session-token cookie is not available in the backend because the Domain
of the cookie does not match the backend domain (www.example.com
!= api.example.com
).
To make the session-token cookie available in the backend, you have to pass it as bearer token in the Authorization
header.
cbo_session_token
and Domain=www.example.com
Authorization
header (bearer) to the backend because the Domain
does not matchAuthorization
header (bearer) and validates itSince it is technically possible to pass the session-token using other methods like query parameters or other header fields (like X-Session-Token
), we strongly recommend using the Authorization
header. This is the most secure way to pass the session-token.
Scenario 3 is pretty similar to scenario 2. The only difference is that you have multiple backends (like it is common in microservice architectures).
cbo_session_token
and Domain=www.example.com
Authorization
header (bearer) to the backend because the Domain
does not matchAuthorization
header (bearer) and validates itAuthorization
header (bearer) to the backend because no Browser is involved and we have no cookie handlingAuthorization
header (bearer) and validates itSince it is technically possible to pass the session-token using other methods like query parameters or other header fields (like X-Session-Token
), we strongly recommend using the Authorization
header. This is the most secure way to pass the session-token.