Distributed Token Validity – A Different Approach To Local Govt
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:
https://www.pingidentity.com/en/company/blog/2017/06/22/introducing_distributed_token_validity.html
https://github.com/pingidentity/dtva-reference
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
Backend
- REST APIs
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
Hashgraph
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
