SSO Tokens storage and passing | Community
Skip to main content
N
nsvsrk
Level 8
July 26, 2025

SSO Tokens storage and passing

  • July 26, 2025
  • 1 reply
  • 538 views

Hi all,

 

Let us say my site is integrated with SSO IDP Okta.

 

When use logs in, IDP's login page appears and IDP collects user id and password.

IDP authenticates and sends only token to AEM.

1. From then for each of the requests from that client how the token is utilized?

2. Where is the token stored or passed?

3. How is the token mapped to the user?

 

For that user AEM/IDP should not ask for user name and password.

 

Appreciate all your responses,

 

Thanks,

RK.

1 reply

BrianKasingli
Community Advisor and Adobe Champion
BrianKasingliCommunity Advisor and Adobe Champion
Community Advisor and Adobe Champion
July 30, 2025

Hi RK,


Once Okta authenticates the user, AEM only uses the token during that initial handshake. After that, AEM creates its own session and sets a secure login-token cookie in the browser.

That cookie is sent with every request, so AEM knows the user is logged in — no need to go back to Okta each time.

The SAML/OIDC token from Okta usually carries attributes like username or groups, which AEM maps to a local user (created on the fly if needed).

So in short:

  1. Okta handles the login once.
  2. AEM uses its own session cookie afterward.
  3. User mapping comes from the attributes in the token.
    N
    nsvsrkAuthor
    Level 8
    July 30, 2025

    Thanks @briankasingli 

     

    This reply is really helpful.

    What if the user blocks cookies?

     

    Of course this query is valid for normal AEM Authentication also (without an IDP).

    Here also I guess AEM session is cookie based.

     

    Thanks,

    RK.

    BrianKasingli
    Community Advisor and Adobe Champion
    BrianKasingliCommunity Advisor and Adobe Champion
    Community Advisor and Adobe Champion
    July 30, 2025

    Hey RK,

    AEM relies on a cookie (login-token) to keep a user logged in, whether the login comes through Okta SSO or directly with AEM credentials. If a user blocks cookies, AEM can still process the initial login, but every new request will look like a fresh session because there’s no cookie to prove the user is authenticated. That means the user will be asked to log in again and again.

    AEM authentication is cookie‑based, and blocking cookies prevents a persistent login session. This applies both with an IDP like Okta and with AEM’s native login.

      Terms & ConditionsAccessibility statement

      Loading footer...