Distributed Token Validity – A Different Approach To Local Govt

From IIW

Distributed Token Validity API: How do we solve SSO true logout issues?

Wednesday 5G

Convener: David Waite

Notes-taker: Danielle Johnson

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Detailed information can be found at the following links:





Additional notes:

No single spec for logout currently works.

Frontend: redirect, iframe, cookies

  • Possibility of not actually logging out, especially with multiple redirects

Admin logout

  • Sessions can still exist if token life continues.
  • There is no update check for a user who was fired and they may still have access



SSO not typically integrated into each app, typically it is just a cookie used to try and tell them to logout

Logout typically refers to all applications access for SSO, not just you logging out of the current application

What does logout actually mean?

  • What is the expectation when someone logs out?
  • Trying to tell browser or app they need to be reauthenticated at the next access

OIDC session management spec

SSO/SAML focuses on logging in, but logout wasn’t thought through

  • Destroying the cookie
  • Logout of browser
  • Undoing all the work it just did to login

Login uses tokens

  • So if logout instead removes validity of token, all access is removed and true logout exists by removal of accesses

Using tokens to update information

OIDC session management

  • Html 5, POST message, javascript, etc
  • Load page on IdP domain ( PULL, web socket, etc), sends message on your app saying token is good or bad, if bad get a new token

Ex: Google will periodically require login credentials and will go across all tabs, but an API being used with that same Google account won’t be effected by the “logout”

Single interface for users initiating logout or admin logging you out

This suggests using:

Frontend RESTful API

  • Deployed individually by user still actively using the app or by a single IdP


How is data synchronized?

Cross domain liveness check; is the user still actively using the app

Main focus is how to main overall experience more dynamic

  • If a token is good for a week and someone is fired on day 4, how do you make token invalid?
    • Session change requires new token no matter what the token lifetime is

Changes or updates to policy, causing untrusted previously approved token to no longer appear valid

Blockchain idea can be used to require new token (through checking again previous data)

Hashgraph said IdP can actually create

Actual tokens aren’t tracked; it leverages the Sessionid