Identity Tokens, Sessions, and OAuth Grant Detection

A grant, token, and session are different security objects

An authorization grant represents approved authority used to obtain a token. An access token carries authority to a resource server for a limited scope and lifetime. A refresh token can obtain new access tokens. A session is continuity maintained by an application or identity provider.

These objects overlap but are not interchangeable. Revoking a session may not invalidate every access token immediately; stealing a refresh token can create new access without another interactive login.

Build detections around transitions and relationships: who or what received authority, which client requested it, which issuer granted it, which audience accepted it, and which resource action followed.

Claims describe context but must be validated

A token may carry claims such as issuer, subject, audience, scope, issue time, expiry, client, or authentication context. A claim is an assertion from the issuer; its meaning depends on the token type and the receiver’s validation.

Do not log raw bearer tokens. They are credentials. Prefer safe identifiers, hashes designed for correlation, token family or session identifiers, claim summaries, and validation outcomes under a governed retention policy.

Detection should notice impossible issuer-audience pairs, unexpected clients, unusual scope, lifetime anomalies, and use from incompatible contexts. It must also know when claims were unavailable rather than treating missing values as safe defaults.

Replay defenses create valuable relationships

RFC 9700, the OAuth 2.0 Security Best Current Practice published in 2025, recommends sender-constrained access tokens where feasible and requires public-client refresh tokens to be sender-constrained or rotated. Sender constraint binds use to proof held by a client. Rotation replaces a refresh token and retains family relationships.

Reuse of an invalidated rotated token can indicate that both a legitimate client and another party possess the token family. That is strong evidence, but race conditions, retries, and implementation behavior still need context.

Preserve family, client, subject, device, issuer, and outcome relationships so the alert explains why reuse is inconsistent with the expected lifecycle.

Behavior after issuance can reveal stolen authority

A valid token used within scope can still be stolen. Look for changes in client, device, network, geography, audience, resource pattern, request rate, or time relative to issuance and prior use. Compare only contexts that are expected to remain stable.

Workload identities and automation behave differently from people. A service principal changing source infrastructure may be meaningful, while a mobile user’s network may change normally. Baselines should follow identity type and application architecture.

Correlate issuance and resource access using governed identity entity resolution. A join on display name or recycled account identifier can transfer suspicion to the wrong subject.

Revocation and response have propagation limits

Revoking a grant, refresh token, session, or client credential affects different parts of the authority chain. Access tokens may remain valid until expiry unless resource servers support timely revocation or introspection. Response plans must state which object is acted on and how recovery is verified.

Facts include issuance, validation, use, rotation, and revocation records. The assessment might be likely replay or unexpected delegated access. Uncertainty includes unobserved resource servers, clock differences, token caching, and incomplete session linkage.

An investigation-ready alert should reconstruct the chain without exposing credentials, identify affected audiences and scopes, and distinguish containment already achieved from authority that may still work.