Episode 091: 3‐19‐2025 Powering Continuous Identity with OAuth and OpenID - GluuFederation/identerati-office-hours GitHub Wiki
Title: Powering Continuous Identity with OAuth and OpenID
- Host: Mike Schwartz, Founder/CEO Gluu
- Guest: Sean O'Dell, esteemed Identerati
Channels
Description
Continuous identity requires new enterprise infrastructure to publish events related to a login session and token lifecycle. One solution could be Shared Signals Transmitters (SSTs) based on the OpenID Shared Signals Framework (SSF) and the Continuous Access Evaluation Protocol (CAEP). Another solution could leverage recent OAuth drafts for global token revocation and OAuth Status List JWTs. Join us as we discuss why continuous identity is the future and if it fits into a token based access control model.
Homework
Takeaways
-
⚡ Security Event Token: a new token, without expiration, which is a record of a security event with schema based on an agreed profile.
-
⚡ SSF Transmitter is hard: you have to mint a signed SET token with the right info. SSF Receiver is easier -- validate the tokens, and use the contents as input to policy.
-
⚡ An SSF Receiver endpoint works for cloud, but it doesn't extend as easily to browser-based clients and mobile applications (although there are non-standard ways to push notifications to Apple and Google devices). However, mobile and browser-based applications can check in real time for JWT revocation via the OAuth Status List endpoint.
-
⚡ The ITDR needs to "Respond"--Verosint has a button to "Revoke All Sessions" and to "Suspend Account". Different IDPs might handle these events differently. Can Verosint just "transmit" a CAEP SET Token to the IDP, who in this case is the Receiver? The IDP kills the session, and then transmits to RPs? See Verosint screenshot below (from their public website).