Menu
I'm trying to understand how to implement the logout feature in a Single Sign On architecture using Json Web Tokens.
Let's say we have :
example1.comexample2.comauthserver.comWhen the user has to authenticate on example1.com, he is redirected to authserver.com which validates the user credentials, creates a signed JWT token and redirects the user back to example1.com with this token. example1.com will then set a cookie (or a LocalStorage key) and the user will be authenticated on example1.com, for as long as the token is not expired. No more call to authserver.com is required to identify the user.
The user then goes to example2.com, which participates in the SSO architecture. The user needs to be authenticated there too, so example2.com also redirects the user to authserver.com which recognizes the user (using a cookie it has set the first time), creates a new JWT token and automatically redirects the user back to example2.com. example2.com will then set a cookie (or a LocalStorage key) and the user will be authenticated on example2.com, for as long as the token is not expired. No more call to authserver.com is required to identify the user.
Now, how can a "logout" feature be implemented?
If the user logs out on example1.com, the JWT token on example1.com is deleted and the user shouldn't be authenticated there anymore. But as soon as he tried to reach a protected area, example1.com will redirect him to authserver.com, the user will be recognized and automatically logged in again... Even if he just logged out!
Quetion 1) So I guess that when the user logs out on example1.com, a call to authserver.com must be done to remove the cookie set by authserver.com so the user won't be logged in automatically anymore?
Quetion 2) If so, what about example2.com? Should the user still be authenticated there? If not, what is the suggested flow so example2.com knows that the JWT token it has for the user isn't valid anymore?
697
The most common way to revoke access to resources protected by a JWT involves setting its duration to a short period of time and revoking the refresh token so that the user can't generate a new token.
Set a reasonable expiration time on tokens. Delete the stored token from client-side upon log out. Have DB of no longer active tokens that still have some time to live. Query provided token against The Blacklist on every authorized request.
Single Logout (SLO) is a feature in federated authentication where end users can sign out of both their Okta session and a configured application with a single action. Okta supports this sign out process only when initiated by a Service Provider (SP). The SP sends the SLO request to Okta to end the Okta session.
1) https://openid.net/specs/openid-connect-session-1_0.html#RPLogout is one spec (there are other specs for different strategies) to sign out of the authserver as well. It defines an end_session_endpoint that your example1.com would redirect to; note that the authserver signs the user out and can redirect back to the RP's post_logout_redirect_uri.
2) I think that depends on what you want it to do. You may not want to kill the example2.com session, in which case example2.com would carry on. The JWT for example2.com is still valid. If you want to logout of all your clients, it's a bit more complicated but possible. In my project, logging out of the one client and the authserver was what we wanted.
147
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
