DEV Community: Mason Parle

Shared Signals Framework: Bringing Standards to Continuous Session Protection

Mason Parle — Wed, 11 Feb 2026 12:09:45 +0000

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:

User authenticates
IdP issues a session or access token
Trust is established through the access token and maintained from a refresh token
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

Why Your OAuth Flow Needs PKCE (And How It Actually Works)

Mason Parle — Mon, 02 Feb 2026 22:13:40 +0000

OAuth has moved well past the one-size-fits-all standard it was initially set to be. Human and non-human identity rely on it for all sorts of critical auth requirements, but as OAuth has expanded beyond the constraints of server-side apps, a gap has emerged: how do public clients prove their identity without a stored secret?

That's where Proof Key for Code Exchange (PKCE, like 'pixie') comes in. PKCE is an extension to the authorization code flow where users authenticate via browser redirect.

The Coat Check Problem

Imagine you're at a conference and check your laptop bag. The standard procedure is you are given a claim ticket, you show the ticket and you get your bag.

What if someone is looking over your shoulder and sees the ticket number? This opens the opportunity to abuse this 'shared secret' and recite "ticket 47" to retrieve your laptop.

Now imagine a smarter system:

When you check your bag, you make up a secret phrase "purple elephant dancing"
You whisper a scrambled version of that phrase to the attendant (they can't reverse the scramble)
They write down the scrambled version next to your bag
Later, you come back and say the original phrase
They scramble it themselves and check if it matches what they wrote down

Someone who overheard the scrambled version can't readily reverse-engineer "purple elephant dancing."

In a nutshell, that is PKCE. The secret phrase is your code_verifier. The scrambled version is the code_challenge. The attendant is the authorization server. The claim ticket is the authorization code. This is PKCE ensuring that even if someone intercepts your code, they can't use it.

Do You Need PKCE?

Short answer: yes, if you're using the authorization code flow.

Client type	Classification	PKCE
Single-page app (SPA)	Public	Required - can't store secrets in browser
Mobile app	Public	Required - URL schemes can be hijacked, binaries decompiled
Desktop app	Public	Required - binaries can be decompiled
CLI tool	Public	Required - runs on user's machine
Server-side app	Confidential	Recommended - defense in depth against code injection

It doesn't apply to:

Client credentials - machine-to-machine, no authorization code
Refresh token grants - no authorization code involved
Implicit flow - deprecated, tokens returned directly without a code
Device authorization - different mechanism, no redirect to intercept

If your flow has an authorization code, PKCE should protect it.
The OAuth 2.0 Security Best Current Practice now recommends PKCE for all OAuth clients, not just public ones. It adds defense in depth meaning even if you have a client secret, PKCE protects against authorization code injection attacks.

The Problem PKCE Solves

Traditional OAuth with a client secret was designed with server-side apps in mind, given the secret stays on your server, it isn't openly exposed during the authentication traffic.

The challenge comes when considering SPAs and mobile applications, an emergent modern trend. There's no secure place to store a secret when the code runs on an external device and anyone who intercepts the authorization code can then exchange it for tokens.

Proof Key for Code Exchange (PKCE) solves this by binding the token request to the original authorization request without requiring a stored secret.

The Core Mechanism

Going back to the coat check: instead of proving identity with a secret you store (the number 47 ticket), prove it by demonstrating you initiated the original request (purple elephant dancing).

Pre-auth request: Generate a random string (the code_verifier) and keep it in memory
In-auth request: Send a hash of that string (the code_challenge)
In-token request: Send the original code_verifier
Server verification: Hash the verifier, compare to the stored challenge

An attacker who intercepts the authorization code doesn't have the original verifier and can't complete the token exchange.

The Actual Implementation

Step 1: Generate the Code Verifier

The verifier is a cryptographically random string, 43-128 characters, using only [A-Za-z0-9-._~]:

function generateCodeVerifier() {
  const array = new Uint8Array(32);
  crypto.getRandomValues(array);
  return base64UrlEncode(array);
}

function base64UrlEncode(buffer) {
  return btoa(String.fromCharCode(...buffer))
    .replace(/\+/g, '-')
    .replace(/\//g, '_')
    .replace(/=/g, '');
}

Step 2: Derive the Code Challenge

The challenge is a SHA-256 hash of the verifier, base64url-encoded:

async function generateCodeChallenge(verifier) {
  const encoder = new TextEncoder();
  const data = encoder.encode(verifier);
  const hash = await crypto.subtle.digest('SHA-256', data);
  return base64UrlEncode(new Uint8Array(hash));
}

An interesting note. Given SHA-256 always outputs 32 bytes, base64url of 32 bytes (256/6 = 42.67).
The challenge will always be 43 characters

Step 3: Authorization Request

Include the challenge (not the verifier) in your auth request:

GET /authorize?
  response_type=code&
  client_id=your-app&
  redirect_uri=https://yourapp.com/callback&
  code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM&
  code_challenge_method=S256&
  state=xyz123&
  scope=openid profile

The authorization server stores the challenge alongside your authorization session.

Step 4: Token Exchange

After the user authenticates and you receive the code, exchange it with the original verifier:

const response = await fetch('/token', {
  method: 'POST',
  headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
  body: new URLSearchParams({
    grant_type: 'authorization_code',
    code: authorizationCode,
    redirect_uri: 'https://yourapp.com/callback',
    client_id: 'your-app',
    code_verifier: storedCodeVerifier  // The original, not the hash
  })
});

The server hashes the verifier you send and compares it to the stored challenge.
Match = tokens issued. No match = request rejected.

Common Misconfigurations

Using plain instead of S256: The spec technically allows sending the verifier unhashed as the challenge (code_challenge_method=plain). Don't. It exists only for clients that can't do SHA-256, which is essentially nothing modern.
Always use S256. If you can't, there are bigger problems.

Storing the verifier insecurely: The verifier should live in memory only. Don't put it in localStorage, sessionStorage, or cookies.
For SPAs, keep it in a JavaScript variable. For mobile, use secure memory.

Verifier too short: Must be 43-128 characters. Under 43 and the server should reject it.

Wrong base64url encoding: Standard base64 uses + and /. Base64url uses - and _. Mixing them up breaks everything. Also strip the = padding.

Seeing It In Action

Now reading about PKCE is one thing, but watching the actual challenge/verifier exchange happen is thrilling.

Run the full PKCE flow in ProtocolSoup's Looking Glass

Protocol Soup was built specifically for this - bring tactility and interactivity to authentication protocols and identity in general. Run the real flow against a real authorization server and inspect every parameter at each step.
The Looking Glass shows you the exact code_challenge sent in the auth request, then the code_verifier in the token request, so you can verify the cryptographic relationship yourself and compare against a traditional authorization code flow.

When PKCE Isn't Enough

Identity is an ever-growing frontier and PKCE was designed to protect the authorization code exchange.
It doesn't protect against:

Token theft after issuance: Once you have tokens, PKCE's job is done. Store and transmit them securely.
Compromised redirect URI: If an attacker controls the redirect URI, they get the code and can observe your token request. PKCE can't help here.
XSS in your app: If attackers can run JavaScript in your app, they can steal the verifier from memory before you use it.

PKCE can be boiled down to one principle: prove you started what you're trying to finish.

For the authoritative source, see RFC 7636.
For current OAuth 2.0 Best Practice, see RFC 9700