How to Combine Single Sign Off and Stateless Authentication

Question

I'm trying to add a SAML based Single Sign On / Single Sign Off solution to allow a mixed ecosystem of web based applications that give the impression to the end user that they are interacting with a single application.

The standard approach to this appears to be to have an IdP manage the user authentication (which establishes an IdP session) then as needed have it issue signed SAML sign on requests to establish a session in each component application.

Sign Off can be handled by using SAML Single Sign Off where, on sign off, the IdP issues a back channel call to each service provider to invalidate the session.

This works fine for traditional stateful session based applications, but I'm trying to work out how we integrate applications that are using a stateless JWT token in place of a server side session.

The sign on piece works equivalently, we just issue a JWT in response to the SAML sign on instead of establish a traditional session. Logging out of a single service is practical by simply removing the cookie.

But is there any way to achieve the Single Sign Out flow? The only approach that I can see is:

• Host all stateless applications on the same domain (or at lest sub-domains)
• On Sign-out, remove all stateless authentication cookies for that domain, not just the one for the individual application
• After clearing those cookies, trigger the SAML Single Sign Out flow to deal with the statefull applications.

Is there a more standard approach to this or is this always hand rolled?

In my research, I've come across lots of use of stateless tokens for single sign-on and logs of use of single sign out of state-full applications using either home grown or standards like SAML Sign Off. But I can't find anything simpler or more standard that what I've described for combining the two in a mixed environment.

References:

• Single sign off using OAuth 2 - while abusing OAuth, is a similar situation to what I'm describing but is solved by establishing server side state to validate OAuth tokens to achieve the sign off
• Transparent user session over several sites (single sign-on + single sign-off) & How to do stateless (session-less) & cookie-less authentication? do a good job of describing the kind of stateless authentication flow I'm keen to enable, but seem to rely on either a shared server side store of tokens or just rely on timeout rather than explicit sign off

Answer 1

1 - How does the identity provider let target applications know that they should not allow the user to sign in

In SAML this is achieved via Single LogOut (SLO) which is formalized in a protocol. The IdP can send a SLO message to the target app and the target app can then take action. This brings us to

2 - How does the target application prevent the user from signing in when presented with a 'valid' JWT token

When the application generates the JWT token, it needs to do so in such a way so that it can revoke this token later. Practically this means keeping track of issued tokens via some unique identifier such as JWT ID (jti). If the application generates tokens by contacting a 3rd party responsible for managing these tokens, then you hope / insist that the 3rd party token issuer provides a way to revoke the token.

If the application (or 3rd party issuer) can't revoke a token, then you can still kinda sorta achieve this by having the tokens expire. That is your poor man's token invalidation solution.