RevokedSessionValidator Class
Refuses a grant whose authentication session a revocation cutoff has caught.
public class RevokedSessionValidator : Abblix.Oidc.Server.Endpoints.Token.Validation.ITokenContextValidatorInheritance System.Object → RevokedSessionValidator
Implements ITokenContextValidator
Remarks
The third place a revocation has to be read, and the only one that sees this case. The token side compares issue times, and every token minted at redemption is new, so it passes. The authorization endpoint judged this session when the grant was created and does not see it again. What is left is the interval between authorizing and redeeming - a minute for an authorization code by default, far longer for a device code or a back-channel request - and a grant redeemed inside it founds a refresh family that stays past the cutoff for its whole life, because rotation carries the first issue time forward.
A validator rather than a step in the processor, because the processor runs downstream of an irreversible spend: AuthorizationCodeReusePreventingDecorator removes the authorization code before delegating, so a refusal there would burn a code the request never earned. Validation happens first.
It asks only about grants that carry a session from an earlier request. The remaining grant types build
their session during this one - a client credentials, jwt-bearer or token exchange request stamps
AuthenticationTime from the current clock and generates the session identifier on the spot - so no
cutoff can predate it, and asking would be two store reads that cannot answer yes. It would also put a
subject from somebody else's namespace against our cutoffs: under client credentials the subject is the
client identifier, and under the assertion grants it belongs to a federated issuer.
Constructors
RevokedSessionValidator(IRevocationCutoffChecker) Constructor
Refuses a grant whose authentication session a revocation cutoff has caught.
public RevokedSessionValidator(Abblix.Oidc.Server.Features.Tokens.Revocation.IRevocationCutoffChecker cutoffChecker);Parameters
cutoffChecker IRevocationCutoffChecker
Decides whether a cutoff refuses the session behind the grant.
Remarks
The third place a revocation has to be read, and the only one that sees this case. The token side compares issue times, and every token minted at redemption is new, so it passes. The authorization endpoint judged this session when the grant was created and does not see it again. What is left is the interval between authorizing and redeeming - a minute for an authorization code by default, far longer for a device code or a back-channel request - and a grant redeemed inside it founds a refresh family that stays past the cutoff for its whole life, because rotation carries the first issue time forward.
A validator rather than a step in the processor, because the processor runs downstream of an irreversible spend: AuthorizationCodeReusePreventingDecorator removes the authorization code before delegating, so a refusal there would burn a code the request never earned. Validation happens first.
It asks only about grants that carry a session from an earlier request. The remaining grant types build
their session during this one - a client credentials, jwt-bearer or token exchange request stamps
AuthenticationTime from the current clock and generates the session identifier on the spot - so no
cutoff can predate it, and asking would be two store reads that cannot answer yes. It would also put a
subject from somebody else's namespace against our cutoffs: under client credentials the subject is the
client identifier, and under the assertion grants it belongs to a federated issuer.
Methods
RevokedSessionValidator.ValidateAsync(TokenValidationContext, CancellationToken) Method
Asynchronously validates the token request within the provided context, checking for compliance with the necessary validation rules such as client authentication, scope validation, grant validation, etc.
public System.Threading.Tasks.Task<Abblix.Oidc.Server.Common.OidcError?> ValidateAsync(Abblix.Oidc.Server.Endpoints.Token.Validation.TokenValidationContext context, System.Threading.CancellationToken cancellationToken);Parameters
context TokenValidationContext
The context containing the token request and related information that needs to be validated.
cancellationToken System.Threading.CancellationToken
Implements ValidateAsync(TokenValidationContext, CancellationToken)
Returns
System.Threading.Tasks.Task<OidcError>
A OidcError containing error details if the validation fails;
otherwise, returns null indicating that the validation was successful.