sid (Session ID) Claim in a JWT
sid identifies one authentication session at the identity provider. Logout messages carry the same value, which is how a relying party knows which of its own sessions to end.
At a glance
- Claim
- sid (Session ID)
- Defined in
- OpenID Connect Front-Channel Logout 1.0, also used by Back-Channel Logout
- Value type
- String, unique within the issuer, compared as an opaque value
- Required
- Optional in an ID token. Required in a back-channel logout token unless that token identifies the session with sub instead.
- Sample value
- 08a5019c-17e1-4977-8f42-65a12843ea02
- In the decoder
- Shown under Custom claims with its raw value, alongside the logout token's other claims.
In detail
One person can hold several sessions at the same provider at once: a laptop browser, a phone, a private window. sub is the same in all of them, so sub cannot say which one just ended. sid names the individual session, which is the granularity logout actually needs. Correlating on sub instead signs the person out everywhere, which may not be what anyone asked for.
The relying party stores sid alongside its own session record when the ID token arrives. When the provider later sends a logout token, that token carries the same sid, and the application looks up the matching local session and destroys it. Without the stored association there is nothing to act on, so a deployment that ignores sid at login cannot support single logout later however correct the logout message is.
A logout token is itself a signed JWT and needs its own checks, not just a sid lookup. It has to carry an events claim marking it as a logout event, must not carry a nonce, and its issuer, audience and signature all have to be verified exactly as an ID token's would be. Acting on the sid inside an unverified logout token would let anyone end anyone else's session.
In the decoder sid appears under Custom claims with its value as encoded. That is genuinely useful when debugging single logout, because the common failure is a mismatch: the sid in the logout token does not match the one stored at login. Pasting both tokens in turn and comparing the two values is usually quicker than reading either application's logs.
Examples
// ID token, abbreviated
{
"iss": "https://auth.example.com",
"sub": "8f14e45fceea167a5a36dedd4bea2543",
"sid": "08a5019c-17e1-4977-8f42-65a12843ea02"
}
// Back-channel logout token, abbreviated
{
"iss": "https://auth.example.com",
"aud": "web-dashboard",
"sid": "08a5019c-17e1-4977-8f42-65a12843ea02",
"events": { "http://schemas.openid.net/event/backchannel-logout": {} }
}Things that catch people out
- Signing every device out because the logout token was matched on sub. sid exists so one session can be ended without touching the others.
- Acting on a logout token without verifying it. It needs the same issuer, audience and signature checks as an ID token, plus the events claim.
- Not storing sid at login. There is nothing to correlate against later, and single logout silently does nothing.
Try it: JWT Decoder
Paste a token to decode the header and payload, read the claims and expiry, and verify the signature in your browser. Nothing is uploaded.
JWT Decoder
LOCAL · Browser-OnlyDecode and inspect JSON Web Tokens without sending them to a server
Related JWT claims and algorithms
All jwt claims and algorithms →sub (Subject) Claim in a JWT
The sub claim says who the token is about. Why it is only unique within one issuer, what pairwise subjects change, and how the decoder shows it.
jti (JWT ID) Claim in a JWT
The jti claim gives a JWT a unique identifier. How it supports replay detection and denylists, what it costs to store, and how the decoder shows it.
typ (Type) Header Parameter in a JWT
The typ header declares the media type of a token. Why at+jwt exists, how typ prevents cross token confusion, and what the decoder flags.
scope Claim in a JWT Access Token
The scope claim carries the granted OAuth scopes inside an access token. Why it is one space delimited string, how to check it, and what the decoder shows.
client_id Claim in a JWT Access Token
The client_id claim names the OAuth client an access token was issued to. How it differs from sub and azp, where it is required, and decoder behaviour.
act (Actor) Claim in a JWT
The act claim names the party acting on behalf of the subject. How nesting records a delegation chain, and why the decoder shows it as raw JSON.
Tools for this
- JWT Decoder Free online JWT decoder - decode and inspect JSON Web Tokens without sending them to a server