LogoutTokenTypeStep Class

Accepts a Logout Token that carries no typ, and refuses one typed as something else.

public sealed class LogoutTokenTypeStep : Abblix.SecurityEvents.Validation.ISecurityCriticalValidator, Abblix.SecurityEvents.Validation.ISecurityEventTokenValidator

Inheritance System.Object → LogoutTokenTypeStep

Implements ISecurityCriticalValidator, ISecurityEventTokenValidator

Remarks

The step it replaces pins the SET's own type, and dropping that pin without putting one back would leave the profile with no answer to cross-JWT confusion at the header at all. What it may not do is demand the logout type. OpenID Connect Back-Channel Logout 1.0 Section 4.1 offers explicit typing and rules out requiring it in the same breath: "Including an explicit type in issued Logout Tokens is a best practice. Note however, that requiring explicitly typed Logout Tokens will break most existing deployments, as existing OPs and RPs are already commonly using untyped Logout Tokens." A receiver that required it would refuse conformant providers, so the rule here is one-sided: an absent type is accepted, a foreign one is not.

Security-critical, because it stands where the profile's confusion wall at the header stands. The wall it can build is lower than the SET's by the specification's own instruction, and the claims the profile demands below - a logout event, no nonce, a subject or a session - are what carry the rest of the weight.

Methods

LogoutTokenTypeStep.ValidateAsync(SecurityEventTokenValidationContext, CancellationToken) Method

Checks the token in flight.

public System.Threading.Tasks.ValueTask<Abblix.SecurityEvents.Validation.SecurityEventTokenValidationError?> ValidateAsync(Abblix.SecurityEvents.Validation.SecurityEventTokenValidationContext context, System.Threading.CancellationToken cancellationToken);