Learn how to handle your session-token and pass it through your system.
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:
cbo_session_token
and Domain=www.example.com
Domain
matchescbo_session_token
and validates itDomain
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 itX-Session-Token
), we strongly recommend using the Authorization
header. This is the most secure way to pass the session-token.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 itX-Session-Token
), we strongly recommend using the Authorization
header. This is the most secure way to pass the session-token.