Shared Signals Framework: Bringing Standards to Continuous Session Protection

Identity Doesn’t End at Login: The Case for In-Session Management

An interactive view of implemented SSF flows is available at ProtocolSoup SSF Sandbox

Identity has pioneered security for how users prove who they are and what they have access to. SAML, OAuth, OIDC - authentication, authorization, scopes and claims can only make it so far, and that limit is the active session.

Once a user proves who (or what) they are, the onus goes back to the provider to identify the target account, scope the permission and issue an active session.

Authentication is the bouncer at the door. Once you have been let in, who is in charge of keeping you safe?

The Static Session Problem

Traditional identity flows are designed to follow the same general pattern:

1. User authenticates
2. IdP issues a session or access token
3. Trust is established through the access token and maintained from a refresh token
4. Session ends

Between steps 3 and 4, the application has a blind spot. Traditional mechanisms of session risk are alert-based - impossible travel, suspicious IP, protected actions are dependent on session generation or inherently 'risky' behaviours.

This creates problems that authentication fundamentally cannot solve.

Traditional identity operates on an alert-based model. A risk is detected (credential compromise, suspicious login, compliance violation) and it generates an alert. That alert lands in a SIEM, a SOC or a workflow, an alert is raised, and there is latency for a person or process to ingest this. In the meantime, the affected sessions continue as if nothing happened.

A user authenticates cleanly at 9am. Their password appears in a breach dump at 10am. The application won't know until the session expires or the user re-authenticates.

This is the everyday reality of a model where risk is detected in one place and enforcement is stuck somewhere else, separated by time and manual process. The session sits in between, unaware.

Alert-Based vs Signal-Based: A Shift in How Risk Travels

This alert-based model treats identity events as things humans respond to. While heuristics attempt to quantify anomalies, the great consistency of people is that they are unpredictable by nature. Every day is a new one for us.

The response needs to be systemic. If the IdP knows a credential is compromised, every application relying on that credential should know too - immediately, automatically, without a human in the loop.

This is the shift from alert-based contextual risk to signal-based progressive risk. Instead of detecting risk and creating an alert for someone to triage, the system emits a signal that propagates across every relying party in real time. The response is not a ticket, it's an automatic policy re-evaluation at every application that can reach into any active session.

The difference is an architectural paradigm shift. Alert-based systems have a detection layer and a disconnected enforcement layer. Signal-based systems unify them. The signal carries enough context for every receiver to independently decide what to do.

SSF: The Protocol That Makes Sessions Dynamic

The Shared Signals Framework (SSF) is the OpenID specification that enables the unification of risk signal generation, transmission, ingestion and automated action. It defines how identity providers and relying parties share security events in real time using Security Event Tokens (SETs). These are signed JWTs that carry structured event data correlating to a specific signal.

SSF operates through two profiles:
CAEP (Continuous Access Evaluation Profile) handles in-session events. Actions, events, indicators that change the security context of an active session.
CAEP solves for the session revocation, credential change, token claims update, device compliance, assurance level downgrade. These are the signals that transform sessions from static to dynamic.

RISC (Risk Incident Sharing and Coordination) handles account-level events. Credential compromise, account disabled, identifier changed. These are broader signals about the user's overall security posture and account standing rather than a specific session.

Together, they cover the full lifecycle: CAEP manages what happens during a session, RISC manages what happens to the account underneath it.

Going back to the bouncer… we might have gotten past with an ID that says “Alice” and looks close enough, but now there is a roaming guard that can raise a signal and boot me out if I start responding to only “Bob” instead.

How it works mechanically

An SSF deployment has two roles: a Transmitter (usually the IdP or some source of truth) and one or more Receivers (relying parties / applications).

The Transmitter detects a security-relevant event such as an admin revoking a user's session. This action is represented as a Security Event Token (SET):

{
  "iss": "https://idp.example.com",
  "aud": ["https://app.example.com"],
  "iat": 1707400000,
  "jti": "event-unique-id",
  "sub_id": {
    "format": "email",
    "email": "alice@example.com"
  },
  "events": {
    "https://schemas.openid.net/secevent/caep/event-type/session-revoked": {
      "event_timestamp": 1707400000,
      "initiating_entity": "admin",
      "reason_admin": {
        "en": "Security policy violation detected"
      }
    }
  }
}

This SET is signed and delivered to every subscribed Receiver. It is transmitted through either a push delivery (RFC 8935) or polled by the Receiver (RFC 8936). The Receiver validates the signature against the Transmitter's JWKS, parses the event, and acts based on the event. These events are configurable by the receiver and can include actions including terminate sessions, revoke tokens, force re-authentication, trigger step-up auth…

The whole cycle from detection to enforcement happens without human intervention. Alerts are raised, communicated and actioned between services and machines, no Human-In-The-Loop is required.

Now that bouncer becomes a personal bodyguard, with a live intel feed transmitting any risk signals, and receiving them for immediate action. The catch is you are never completely trusted, one bad signal means you have to prove who you are once again.

SSF and the Attacker Mindset

Attackers are incredibly successful. Tiny holes in an attack surface, actively exploited zero-day vulnerabilities, undetected advanced persistent threats all pose detrimental impacts that often leave practitioners feeling as though there is forever one extra control and one extra point of friction that needs to be addressed.

While this may be true, it is important to consider the success of these black-hat and APT groups, and that success often comes down to sharing and collaboration.

This is what Shared Signals brings: the attacker mindset of sharing compromise, except this time for good.

Shared Signals open up theoretical branches of security not previously exposed in such a standard. Federated identities, external identities, cross-system identities can all be configured to share intel, to share signals in a framework that enables each platform to take the actions that fit their purpose.
A memo is put out from a transmitter saying "this credential has been compromised." Some receivers may elect to issue communications to the impacted users. Others may quietly issue a credential reset. Some may decide to enforce MFA as a result.

It is this democratised action that enables a view of shared security. The source system issues standardised risk signals and any trusted downstream receiver takes the actions which fit that persona.

Spec references: OpenID SSF 1.0, CAEP, RISC, RFC 8417 - Security Event Token, RFC 8935 - Push Delivery, RFC 8936 - Poll Delivery