TypHeaderStep Class

Requires the "typ" header to name a SET. A JWT accepted as a SET, or the reverse, is the token confusion class RFC 8417 Section 4 is about, and the explicit type is its most direct wall (Section 4.3).

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

Inheritance System.Object → TypHeaderStep

Implements ISecurityCriticalValidator, ISecurityEventTokenValidator

Remarks

RFC 8417 Section 2.3 makes the header conditional - it "MUST be included if the SET could be used in an application context in which it could be confused with other kinds of JWTs" - and this profile takes the condition as met: a receiver cannot know every context its issuers' JWTs live in, so it assumes the confusable one. The comparison accepts every spelling RFC 7515 Section 4.1.9 makes equivalent, "application/secevent+jwt" included. A profile whose tokens are typed differently - Back-Channel Logout's "logout+jwt", say - replaces this step with its own rather than removing typing altogether.

Methods

TypHeaderStep.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);