11M/ OpenID Connect: Session Management vs Privacy
OpenID Connect: Session Management vs Privacy
Wednesday 11M
Convener: David Waite
Notes-taker(s): David Waite
Tags for the session - technology discussed/ideas considered:
OpenID Connect, Session Management, Logout, Privacy, Browser Policy
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Slide/Presentation Contents Provided by David Waite:
Contents
Session Management vs. Privacy
Strategy for OIDC synchronized sessions in a world without third-party cookies
IIW 32 - Session 11
What is a Session?
the period during which a user is logged in or connected.
Web sessions are made up of the local policy, corresponding business logic, and state around continued access.
For a relying party with existing session semantics, also respecting an OP session is challenging.
Applications track state in several ways:
Via cookies
Via a backend database
In browser memory
OpenID Connect thus has three defined systems for session management
Front-channel Logout
Back-channel Logout
(IFrame) Session Management
Front-channel Logout
Lets the OP redirect the user to the RP with an event that says “log the user out”
But:
The user must hit the OP in order for logout to begin.
No guarantee the message will get there
No guarantee the message will be actionable if it does
E.g. cookie loss, difference in logged-in-user on RP
No fraud/malicous party protection
those who steal cookies tend to not honor these messages
Back-channel Logout
Lets the OP say, “log this user out” via an event on an API call to the RP.
Even allows you to block access by multiple filters:
a single session identifier
a subject across all sessions ( administrative lockout )
But integration into many RP systems is difficult; there may not be a place
on the back-end that allows this sort of clean-up.
(IFrame) Session management
A session management system mostly made for single page apps, but can include appropriate logic (cookie/state deletion and window changes) to work for more static apps by injecting javascript.
RP opens two iframes; one for itself, one for the OP
The RP iframe sends a postMessage asking for session status
The OP iframe has custom logic for processing, and responds with a status - unchanged, changed, or error
On changed, the RP considers the id_token invalidated and does a passive authentication to fetch another one
On passive authentication failure, represent the user as ‘logged out’ until they initiate a manual reauthentication.
To recap:
Front-channel logout is simple
…but brittle and doesn’t give good security guarantees
Back-channel logout is robust
…but difficult to implement/support, can still miss signals
Session Management is useful for some apps
…but is broken in many browsers
On their own independent schedules, all browsers have either broken or have plans to break state sharing via cross-site iframes to limit user tracking - arguably making the Session Management approach unusable.
Distributed Token Validation API
Maybe we already proposed something useful here!
Like session management, it is based on polling for changes rather than pushed events, and the events dont indicate a user/administrative action (logout).
But differs in some key ways:
API-based rather than IFrame-based.
API call can be made by both front-end and back-end application components
Correlates a session solely via embedded sid/jti in JWT
rather than browser storage-based session_state value
Communicates about the validity of the identified token, not the status of an OP session.
It avoids the word session - which often implys a volume of business logic and assumptions about behavior to the parties involved.
Instead, tokens are merely invalid. Token can be invalidated for any reason, such as:
Attribute family_name changed due to HR processing a name change request
User added to ACL; OP wants to repeat authentication to reevaluate rules
User-requested logout action; OP requires explicit reauthentication
Anomaly signal from MDM system; OP requires passive authentication to check device compliance.
Detection of malicious action; OP is invalidating tokens and has no plan to reissue.
In all these scenarios:
The OP takes on the burden of implementing the business logic they require
The RP simply asks if they should still make trust decisions off of existing tokens
If the RP can no longer trust a token, it fetched a new one with escalating levels of user impact
The OP controls token changes/ user interaction based on needed level of excalation
Flow
Retrieve issuer iss and sid (or jti if no sid) from JWT
Resolve issuer + identifier to a HTTPS endpoint representing the session
GET endpoint to determine if token is still valid
If token is invalid, stop depending on it and fetch another one.
This works for all JWTs with issuers and identifiers (such as use for resource servers checking for revoked access tokens)
How to use
For id_token validity checks:
A confidential client can call its own privately hosted infrastructure to check
A public client (javascript app, mobile app) would need a public-facing API endpoint to call to perform the check
With public clients, checks would be user experience - security would be to revoked access to backend / revoked access tokens.
For JWT access token validity checks:
It is not likely clients would proactively check if tokens issued to them are still valid.
Rather,
A protected resource can perform a check for revocation as part of validating the JWT
A token introspection endpoint can perform the check before returning successful results
“But wait - I can’t make my infrastructure depend on the availability/latency of remote API calls!”
The API is designed to work in a decentralized manner*
You can have a local API endpoint providing a cache in the data rack/VPC/pod, and scale up to your performance requirements rather than relying on the performance/SLA of external infrastructure
You can use a forward proxy with HTTP caching to the OP server/endpoints.
You could also define a synchronization mechanism between parties to do more sophisticated updates - state checkpoints, push notifications, etc.
A system based on distributed consensus was defined - it is based on the Swirlds Hashgraph system (precursor to the public network Hedera Consensus Service)
This should map to other consensus systems like Hyperledger Fabric, albeit with some trade-offs
The reference implementation lets you disable use of consensus networks and operate purely locally/in memory.
Also imagined was a synchronization method via webhooks and shared signals/secevents, and a method that pulls deltas of revocations, CRL-style.
There are provisions for pushing information from the RP about the local agent’s usage of a token.
E.g. - “the user is actively performing actions on the RP site”.
The hashgraph implementation uses this to define a sliding inactivity window for automatic revocation.
Issues with Distributed App approach
All participants in the distributed system can see other participants’ update to distributed state.
tokens associated with a session can be correlated by time
partially defeats pseudonyms
wound up sharing sid values across RPs for windowing for efficiency with that in mind
state update by a provider infers OP/RP relationship, that a user is interacting
Even ignoring user privacy, this still leaked competitive information, e.g. “this enterprise seems to have a ton of seats for these SaaS products”
Other approaches like HTTP caching, secevents did not have these issues: communication was scoped between the OP and individual RPs.
