Skip to content

IRevocationCutoffChecker Interface

Decides whether a subject- or session-level revocation cutoff refuses a token.

C#
public interface IRevocationCutoffChecker

Derived
RevocationCutoffChecker

Remarks

Separate from the validator that consults it because the two answer different questions from different stores. The validator asks what is recorded about this one token; a cutoff is a fact about the principal, and answering it means naming the issuer, opening a pairwise pseudonym and allowing for the clock of whichever instance recorded the revocation. Keeping that here also lets it be exercised on its own, without a token registry and an inner validator standing in the way of every case.

Methods

IRevocationCutoffChecker.CheckAsync(JsonWebTokenPayload) Method

The refusal a cutoff calls for on this token, or null when no cutoff reaches it.

C#
System.Threading.Tasks.Task<Abblix.Jwt.JwtValidationError?> CheckAsync(Abblix.Jwt.JsonWebTokenPayload payload);

Parameters

payload JsonWebTokenPayload

The payload of a token that has already passed signature and lifetime checks.

Returns

System.Threading.Tasks.Task<JwtValidationError>
A validation error when the token is refused, otherwise null.

IRevocationCutoffChecker.IsSessionRefusedAsync(AuthSession) Method

Whether a cutoff refuses this authentication session, so nothing may mint against it.

C#
System.Threading.Tasks.Task<bool> IsSessionRefusedAsync(Abblix.Oidc.Server.Features.UserAuthentication.AuthSession session);

Parameters

session AuthSession

A session about to be used: one the authorization endpoint is considering reusing, or the one a grant presented at the token endpoint was authorized from.

Returns

System.Threading.Tasks.Task<System.Boolean>
true when the session must not be used.

Remarks

Without this the token side alone is half a control. A cutoff refuses tokens already issued, and iat is stamped afresh by every new authorization, so a browser session the revocation never touched can mint a replacement that clears the cutoff on the first try - and keeps doing so.

Measured against AuthenticationTime, not against a flag. A sign-in after the suspension is lifted produces a later authentication time and passes, which is the same property that lets a revoked subject sign in again with nothing to clean up. A boolean would refuse the fresh session too, and since the host's new session carries the same subject the request would loop back here for as long as the record is kept.