Single Sign-Out with Single Page Applications

[hendrikheil]

Hey there, I'm currently evaluating how to build a central identity platform for my organizations ecosystem transition.
I've read quite a bit of RFCs and discussions on this topic in general already, but I'd like to see if the community has some better ideas on how to solve this. 🔥

The context I am working with is as follows:
We have various, currently independent services, each with a different brand and different domain name.
Let's call them serviceA.com, serviceB.com and serviceC.com.
We are trying to achieve a Google-like experience for identity management and authentication. So we also have accounts.company.com as a relevant domain.

We are building everything as SPAs and APIs. APIs are pretty easy to deal with once we have an OIDC/OAuth2 Token, as we can just perform introspection on the API gateways. However, the user-experience on the client-end doesn't seem that great.
We'd like to not only support Single Sign-On, but also Single Sign-Out (Single Logout) so that our users don't get confused if they have two different, authenticated applications open at the same time.

We checked out kratos to see if it was possible without hydra at all, but that doesn't seem possible at the moment, as we are bound to different domains (See ory/kratos#662 for the state on that end).

As of the time of writing this, we have found two ways to achieve this goal reliably enough.

Using WebSockets and a PKCE flow.

The idea here would be to have the SPA hold the tokens in memory. On start-up the SPA would check if it has a valid token and if not, perform a typical PKCE-based OIDC flow to obtain a new, valid token. The OP would use WebSockets (or something like pusher or ably) to notify a currently open and running application of a state-change for a particular session. The SPA would react to the notification and act accordingly. However, this only works if the SPA is currently open and running in a tab. However if the tab is closed at the time of notification, the check on start-up would make this a non-issue.

The advantage would be a simple implementation which is easily achieved with a little bit of code. The downside is of course the storing of tokens in application memory, opening it up to XSS attacks.

Using a BFF with WebSockets

The second approach would be a little more involved but also more secure.
Instead of using the client application to store the tokens, you'd defer the process to a light-weight proxy. The client still checks for a valid session on start-up and still has to react to WebSocket notification in-case there is a state-change. But since there can be a Cookie based session between the proxy, you can store the tokens in session, proxy a request to the API and replace the session cookie with the proper tokens. There also wouldn't be the need for any modifications on the hydra end of things, as back-channel notifications are available with a stateful server-side application.

Maybe we've overlooked something here, but as far as we can tell, those two options are the only two ways to make it possible for a SPA to be notified of an invalidated session.

I'm super stoked to see what other options there might be!

[aeneasr]

Wouldn’t it be also acceptable for the user to sign in on both domains individually? So the user is not insta logged in everywhere but needs to sign in on both foo.com and bar.com?

Logout would still work across domains because we invalidate the session in the DB.

It could be a workaround until we have multi domain support available. And maybe it might make more sense to invest the time in the Ory Kratos feature versus a complex web socket set up :)

[vinckr]

Do you think you could just do a check if they have a valid session before they make the request?
So press submit -> checks /whoami if session active -> if yes make request -> if no display notice in ui and let them login again in a popup?

They would still need to login on each individual domain, but the logout would be across domains as pointed out above.

[hendrikheil]

We already have quite a big of abstraction available that makes it rather easy for us to handle websockets.
So yeah, it would be possible and honestly it's probably the easiest thing for most people.
For my case having a global websocket subscriber that can just show the notice is easier. It does mean we are going to use hydra and kratos together and it might not be the ideal solution technically speaking.

We'll probably use a consent-less hydra client for delegating authN to the SPA and then listen to websockets in case an invalidation event happens while other apps are active.

[aeneasr]

Since sessions, logout, and OAuth2 have now all been dropped, a mandatory notice we give out to all users to read before going down the rabbit hole of OAuth2 - which is for 95% of use cases not the right tool for the use case at hand: https://www.ory.sh/hydra/docs/concepts/before-oauth2/

[hendrikheil]

Not quire sure what you mean by "have now all been dropped"?
I'd love to avoid Hydra and OIDC. But I am not sure how I would be able to even integrate kratos in a way that my first-party SPAs are even able to access any API behind my gateway. What sort of authentication method would I use there? Session cookies probably won't work if the APIs are not on the same (sub-)domain as the SPA itself.

[aeneasr]

What I mean is that the use case you describe doesn’t sound as if you need a complex OIDC environment. It’s a first party scenario, you’re building a browser app, you want session management, and the one issue you have is that you need sessions on several domains. OIDC does actually not solve cross domain auth! You’d see the domains as different third party apps, which is I assume why the original question was posted :)

Cookies have no problems with sub domains. It’s only complicated if you have the SPA on tld 1 and API on tld2 but that will always be complicated (CORS, cross domain cookies, …) regardless of the auth method chosen. With OAuth2 you’d probably store the tokens in a httpOnly cookie too, to keep them secure! So it doesn’t address your initial question - you have the same problem!

I fear this is all I can help for now. I hope this helps and saves you a ton of time developing complex (simplicity is usually more secure) systems and flows. I really encourage you to stay away from OIDC for now and try the suggestion in the previous comment. Chances are you’ll be done in a week or two :) And if it doesn’t, you can still allocate 2 months to fully learn, adopt, and do OIDC.

If you do do OIDC, please follow standards and best practices around it (eg front channel logout). Do not develop your own system even if you have some infrastructure available. There is a lot of thought and consideration that goes into this, and you wouldn’t write your own RSA crypto library, or PostgreSQL.

Have fun exploring Ory! :)