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).
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?