Learn · Overview
How Shared Signals works
Single sign-on solved getting in. It did nothing about what happens next. Once an app has accepted a login, it typically keeps trusting that session for hours, even if the user’s password was reset, their laptop was stolen, or their account was disabled five minutes later at the identity provider.
The OpenID Shared Signals Framework (SSF) closes that gap. It defines a standard way for one system to tell another, as it happens, that something security-relevant changed about a user, device, session, or tenant they both care about.
The cast
Transmitter — the system that observes something and sends an event. An identity provider revoking a session, an MDM noticing a device is out of compliance, an EDR detecting malware.
Receiver — the system that receives events and decides what to do. A SaaS app that logs the user out, a gateway that steps up authentication, an IdP that raises the user’s risk score.
Most real deployments are both: an IdP receives device-compliance events from an MDM and transmits session-revoked events to its apps.
The moving parts
| Concept | What it is | Read more |
|---|---|---|
| Stream | A configured, long-lived channel from one Transmitter to one Receiver: which events, how delivered, for which subjects. | Streams |
| SET | A Security Event Token (RFC 8417): a signed JWT carrying one event. | SETs |
| Subject | Who or what the event is about — identified by email, opaque id, issuer + subject, or a complex combination like user + device + tenant. | Subjects |
| Delivery | SETs are pushed to the Receiver over HTTP (RFC 8935) or polled from the Transmitter (RFC 8936). | Delivery |
| Discovery | The Transmitter publishes its capabilities at /.well-known/ssf-configuration. | Discovery |
The lifecycle, end to end
- Discover. The Receiver fetches the Transmitter’s
/.well-known/ssf-configurationto learn its issuer, signing keys, supported delivery methods and management endpoints. - Authorize. The Receiver obtains credentials for the management API — usually an OAuth access
token, as advertised in
authorization_schemes. - Create a stream.
POSTto theconfiguration_endpointwith the events it wants and how they should be delivered. - Add subjects (if the Transmitter doesn’t default to all of them).
- Verify. Ask the Transmitter to send a verification event, proving the pipe works end to end.
- Receive events. Validate each SET’s signature,
iss,audandtyp, then act on it. - Manage. Pause, resume, reconfigure or delete the stream as needs change.
Where CAEP and RISC fit
SSF is the framework. The events that flow over it are defined by profiles:
- CAEP — Continuous Access Evaluation Profile. Events about sessions and the conditions of access while someone is signed in: session revoked, credential changed, device compliance changed, risk level changed.
- RISC — Risk Incident Sharing and Coordination. Events about the account itself: disabled, purged, credential compromised, identifier recycled.
Both are used in the same streams; a Receiver asks for whichever event types it can act on. See the full event catalogue.
SSF is not a policy engine. A SET says what happened. What the Receiver does about it — log out, step up, notify, ignore — is entirely the Receiver's decision.