How is session cookie used to enable SSO?

I’m new to Okta and I’m trying to understand how SSO works after a session cookie is created.

The scenario is this:

1- From the user’s browser, user provides credentials to logs onto my client app A which does Okta authentication using Okta /authn
2- Client app A then creates a session cookie either by calling /sessions to create a session or using the /authorize endpoint
3- If I then attempt to access another SSO-enabled Okta app B from my browser, will I be automatically routed to the app B’s landing page as if I’m already authenticated?

Conversely, if a user already logged onto a SSO-enabled Okta app B attempts to log on to my client app A for the first time, how do I use the session cookie to bypass authentication?

Since you mentioned creating cookies, I assume app A & B both use the same server-side logic (perhaps middlewares since it’s a common practice) to make sure users are authenticated before they can access protected resources of your apps.

When your app uses middleware, there would be a cookie middleware on top of an authentication middleware. The cookie middleware processes the request first. When it sees a valid session cookie issued by your app before, authentication criterion is met, and the authentication middleware will be skipped. The protected resource will be served by your app.

When there is not a valid cooke, perhaps because the user uses app A for the first time, the authentication middleware will step in after the cookie middleware failed to detect a valid cookie. This middleware will generate an authentication request to Okta. At this point, if the user has never authenticated with Okta on this machine before, Okta will challenge the user for credential. After successful Okta authentication, Okta will also issue a cookie, which is tied to the specific domain for your Okta org. In addition to the cookie, which is save to the client’s browser, your application’s authentication middleware also gets the signal that the user is authenticated. At this point, your application issues its session cookie to the browser, and serves the protected resource. Any subsequent request to app A will carry the session cookie, which will let app A’s cookie middleware to green-light the request.

The key point is two cookies are stored by the browser now, one for your app (app A) and one for Okta.

Assume app B is also connected to the same Okta org (meaning same Okta domain), then the prior Okta cookie will apply to app B as well. Now when the user access a protected resource in app B for the first time, app B’s authentication middleware will step in after its cookie middleware failed to detect a valid session cookie for app B. But when the authentication request is sent to Okta, Okta sees a valid cookie of its own and will NOT challenge the user for credential. The authentication middleware silently passed, cookie for app B is then issued, and the protected resource is served.

Hope that helps.

2 Likes

I didn’t know there was an update to my question till yesterday. Thank you for your detailed reply. It helps me understand better how this all works.