The OpenID Shared Signals Framework

A New Chapter for Immediate, Cross-Organizational Security

In today’s hyper-connected society, personal accounts rarely remain confined to a single platform. Individuals often access multiple applications and resources—ranging from an organization’s internal systems and cloud-based apps to consumer-facing services such as media platforms or financial portals. Unfortunately, those who engage in malicious activities are quick to notice any lack of coordination between these different environments. Too often, organizations operate within isolated silos, and fail to share timely information about compromised accounts, session shutdowns, or suspicious user behavior.

Now consider a standard that enables organizations to exchange critical security-related notifications across these previously isolated systems. Picture a scenario where detecting an account takeover attempt or indicator of compromise in one environment instantly prompts preemptive measures in all other connected services. The OpenID Shared Signals Framework (SSF) moves this vision closer to reality.

This post will clarify what SSF is, describe its approach, explain the roles of the Continuous Access Evaluation Protocol (CAEP) and Risk Incident Sharing and Coordination (RISC), and outline the ways in which it encourages organizations to work together for stronger protection.

Introducing the Shared Signals Framework

The OpenID Shared Signals Framework defines a standardized way for one organization (the sender) to inform another (the receiver) about significant security events in near real-time. Rather than each participant making decisions in isolation, SSF ensures everyone involved can react promptly to developments.

If one organization identifies that a user’s credentials might be compromised, it can send out a security signal to its partners. Those partners, in turn, can immediately enact protective steps like forcing a password reset, re-verifying the user’s identity, or disabling current sessions. This method dramatically shortens the window of risk by ensuring that relevant updates reach everyone who might depend on that user’s account data.

How does the Shared Signals Framework work?

When an organization needs to revoke a user’s session—whether due to suspicious activity, a password reset, compromised credentials, or an account being disabled—the SSF allows systems to communicate and act in real-time. The process begins when the Identity Provider (IdP) (like Okta) or another system capable of identifying security threats detects an issue that requires action. For example, if a user’s account shows signs of compromise, or if their password has been reset, the IdP generates a Security Event Token (SET). This token is essentially a secure message that describes what happened, such as ”session revoked” or ”account disabled,” and contains details about the affected user.

The IdP then digitally signs the token and sends it to all connected services, known as Relying Parties (these could be apps or cloud services). Once an RP receives the token, it first verifies the signature to ensure the message is authentic before correlating it to an account and taking action based on the event in the token, such as logging users out of active sessions, removing access rights, or requiring reauthentication.

Throughout this process, both the IdP and RP should log the event for auditing purposes by recording key details (the time of the event, the user ID, and the reason for revocation). The beauty of SSF is its ability to ensure that security signals propagate immediately and consistently across all connected systems. If one platform detects a problem, every linked service can respond, reducing the risk of unauthorized access and keeping user accounts secure across the ecosystem.

These are participants of the Shared Signals Framework, indicating their role as signal transmitters, receivers, or both.

Why This Approach Matters

Traditional security efforts often rely on an inward focus. Without external cues, a service may trust a user session that appears normal locally, even if another party has just flagged that account as compromised. This delay can prove costly. Attackers exploit these gaps, taking advantage of the time it takes for organizations to manually exchange information or for periodic checks to catch up to new developments.

SSF addresses this shortfall by establishing continuous, event-driven communication channels. Whenever key events occur, partner services are informed. The result is fewer missed signals and a greatly reduced exposure window. Instead of waiting hours, days, or even longer for an incident to come to light, an affected party can learn about it within seconds or minutes, and respond accordingly.

The Two Core Protocols: CAEP and RISC

SSF’s core functionality is carried out by two protocols, each covering different types of events:

1. Continuous Access Evaluation Protocol (CAEP): 
CAEP handles events related to active sessions. These signals involve updates that call for immediate responses. For example, if an organization decides to terminate a session due to questionable activity, or if the user’s profile claims (such as assigned roles or privileges) change mid-session, CAEP ensures partners know about it right away.

Examples of CAEP events:

• Session Revocation: If a login session appears compromised, the provider can send a signal to others so they too can suspend or reevaluate that user’s access.
• Changed Token Claims: When a user’s privileges or attributes shift, CAEP broadcasts the update immediately, prompting services to adjust permissions on the spot.

2. Risk Incident Sharing and Coordination (RISC): 
RISC focuses on events concerning the broader account rather than the immediate session. These events might be less frequent but often have substantial impact. For example, if credentials are found in a breach, or if an account is disabled altogether, RISC allows this information to propagate quickly to dependent services.

Examples of RISC events:

• Credential Updates or Resets: If the user’s password is discovered in a breach or found to be guessable and must be changed, RISC notifies all affiliated systems.
• Account State Changes: When an account is disabled, purged, or needs re-verification, partners are immediately informed, ensuring nobody relies on stale assumptions.

A Practical Use Case

Imagine a user holding accounts across multiple related services. One platform detects that this user’s password is presented in a newly published breach dataset. Without SSF, the other services would remain unaware. Meanwhile, an attacker, now armed with that user’s compromised password, might continue accessing accounts elsewhere.

With SSF, as soon as the first platform identifies the compromised password, it issues a RISC event. Other connected services receive the alert and can instantly push the user to reset their password, end suspicious sessions, or request additional authentication. The system as a whole moves from reactive and piecemeal to immediate and coordinated.

A Connected Security Future

As various online services rely on each other’s data and identity assertions, protecting user accounts requires shared communication channels. The OpenID Shared Signals Framework brings organizations closer, making it possible to coordinate security measures in near real-time. In essence, SSF fosters a well-connected security community. Instead of leaving each organization to fend for itself, it encourages cooperative vigilance that helps mitigate risk before it spreads.

AUTHOR

Josh Parsons

Josh is the Product Manager at Enzoic, where he leads the development and execution of strategies to bring innovative threat intelligence solutions to market. Outside of work, he can be found at the nearest bookstore or exploring the city’s local coffee scene.

*** This is a Security Bloggers Network syndicated blog from Blog | Enzoic authored by Enzoic. Read the original post at: https://www.enzoic.com/blog/the-openid-shared-signals-framework/