OpenID Connect: How to maintain a single sign-on experience between multiple web clients of the same umbrella application?

Question

I'm considering how to take a fairly complex tiered application with multiple web apps that delegate back to the same application server, and migrate it to use OIDC authentication with auth code flow. I am anticipating using identity server 4.

My question is: what would be accepted best practice in terms of maintaining a single-sign-on experience between these different web client applications (i.e. user signs into one, she's signed into them all until she signs out).

https://auth0.com/docs/api-auth/why-use-access-tokens-to-secure-apis suggests:

Note that the audience (aud claim) of the [id token] is set to the client's identifier, which means that only this specific client should consume this token.

This suggests that I should consider my backend application server to be my single 'client', and have my web apps share that same client ID. I can imagine doing this by storing the id token browser-side in a secure cookie.

https://connect2id.com/learn/openid-connect seems to validate this idea:

Put into a browser cookie the ID token can be used to implement lightweight stateless sessions.

But I wonder if it's security best practice to keep an id_token in a cookie.

I wonder if there are any other approaches - like:

• Considering each web application a separate 'client'
• When the user logs on to a second web application, have them direct back to the OIDC provider, which would automatically create a client token for the new client based on some notion that they are still basically 'logged-on' to the OP.

It seems like this must be a solved problem. What is accepted best practice here?

Answer 1

You essentially get SSO out of the box with IdSrv4. Once you're logged in to IdSrv, your browser will send the IdSrv cookie together with each request to IdSrv. So when your first web app sends an auth request, you'll be asked to authenticate at level of IdSrv - at that time, that auth cookie is created and (depending on the flow you're using) a code and/or tokens are returned to your client app. When your second web app sends an auth request to IdSrv the browser sends over the auth cookie together with that request, so you will still be authenticated at level of IdSrv (assuming the cookie hasn't expired) - code and/or tokens will automatically be returned to your second client without the user having to provide his/her credentials again.

I would advise against reusing the same client ID (and thus client secret) across various web apps: in case the client secret is exposed for one web app, it's exposed for all, and that's something to avoid.

The identity token is typically very short-lived - the only reason to hang on to it (after using it to authenticate at level of your client app) is to pass it to the endsession endpoint as an id_token_hint when you're logging out.

Hope this helps :)