#### [Abblix\.SecurityEvents](https://www.abblix.com/en/docs/api/abblix-securityevents 'index')
### [Abblix\.SecurityEvents\.BackChannelLogout\.Steps](https://www.abblix.com/en/docs/api/abblix-securityevents/Abblix.SecurityEvents.BackChannelLogout.Steps 'Abblix\.SecurityEvents\.BackChannelLogout\.Steps')

## LogoutTokenExpiryStep Class

Requires `exp` to be present and still in the future, inverting the rule of the step it
replaces\.

```csharp
public sealed class LogoutTokenExpiryStep : Abblix.SecurityEvents.Validation.ISecurityCriticalValidator, Abblix.SecurityEvents.Validation.ISecurityEventTokenValidator
```

Inheritance [System\.Object](https://learn.microsoft.com/en-us/dotnet/api/system.object 'System\.Object') → LogoutTokenExpiryStep

Implements [ISecurityCriticalValidator](https://www.abblix.com/en/docs/api/abblix-securityevents/Abblix.SecurityEvents.Validation.ISecurityCriticalValidator 'Abblix\.SecurityEvents\.Validation\.ISecurityCriticalValidator'), [ISecurityEventTokenValidator](https://www.abblix.com/en/docs/api/abblix-securityevents/Abblix.SecurityEvents.Validation.ISecurityEventTokenValidator 'Abblix\.SecurityEvents\.Validation\.ISecurityEventTokenValidator')

### Remarks
OpenID Connect Back\-Channel Logout 1\.0 Section 2\.6 step 4 asks that the "iss, aud, iat, and exp
Claims" be validated "in the same way they are validated in ID Tokens", where OpenID Connect
Core 1\.0 Section 2 makes `exp` REQUIRED\. A SET forbids the same claim, which is why this
replacement exists rather than an addition: the two rules cannot both hold, and a profile
carrying both would refuse every token either way\.

The expiry is what bounds how long a captured Logout Token stays usable, which Section 4 asks
providers to keep short - "preferably at most two minutes in the future, to prevent captured
Logout Tokens from being replayable". The replay guard covers that window; this step is what
makes the window finite, so the guard has something to forget.

The same tolerance the profile allows an issue time is allowed here, for the reason RFC 8417
Section 5.3 gives about timestamps across distributed systems: the receiver's clock is not the
issuer's.
Security\-critical, because it replaces a critical step and polices the same claim with the
opposite sign\. It deliberately does not establish the state that step establishes: that flag
says the claim is ABSENT, which is the answer this profile gives the other way round, and a
later step asking for it would be asking a question this profile answers differently\.
### Constructors

## LogoutTokenExpiryStep\(TimeProvider\) Constructor {#Abblix.SecurityEvents.BackChannelLogout.Steps.LogoutTokenExpiryStep.LogoutTokenExpiryStep(System.TimeProvider)}

Requires `exp` to be present and still in the future, inverting the rule of the step it
replaces\.

```csharp
public LogoutTokenExpiryStep(System.TimeProvider clock);
```
#### Parameters

###### `clock` [System\.TimeProvider](https://learn.microsoft.com/en-us/dotnet/api/system.timeprovider 'System\.TimeProvider') {#Abblix.SecurityEvents.BackChannelLogout.Steps.LogoutTokenExpiryStep.LogoutTokenExpiryStep(System.TimeProvider).clock}

The receiver's clock; a test hands in a fake to pin the window\.

### Remarks
OpenID Connect Back\-Channel Logout 1\.0 Section 2\.6 step 4 asks that the "iss, aud, iat, and exp
Claims" be validated "in the same way they are validated in ID Tokens", where OpenID Connect
Core 1\.0 Section 2 makes `exp` REQUIRED\. A SET forbids the same claim, which is why this
replacement exists rather than an addition: the two rules cannot both hold, and a profile
carrying both would refuse every token either way\.

The expiry is what bounds how long a captured Logout Token stays usable, which Section 4 asks
providers to keep short - "preferably at most two minutes in the future, to prevent captured
Logout Tokens from being replayable". The replay guard covers that window; this step is what
makes the window finite, so the guard has something to forget.

The same tolerance the profile allows an issue time is allowed here, for the reason RFC 8417
Section 5.3 gives about timestamps across distributed systems: the receiver's clock is not the
issuer's.
Security\-critical, because it replaces a critical step and polices the same claim with the
opposite sign\. It deliberately does not establish the state that step establishes: that flag
says the claim is ABSENT, which is the answer this profile gives the other way round, and a
later step asking for it would be asking a question this profile answers differently\.
### Methods

## LogoutTokenExpiryStep\.ValidateAsync\(SecurityEventTokenValidationContext, CancellationToken\) Method {#Abblix.SecurityEvents.BackChannelLogout.Steps.LogoutTokenExpiryStep.ValidateAsync(Abblix.SecurityEvents.Validation.SecurityEventTokenValidationContext,System.Threading.CancellationToken)}

Checks the token in flight\.

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

###### `context` [SecurityEventTokenValidationContext](https://www.abblix.com/en/docs/api/abblix-securityevents/Abblix.SecurityEvents.Validation.SecurityEventTokenValidationContext 'Abblix\.SecurityEvents\.Validation\.SecurityEventTokenValidationContext') {#Abblix.SecurityEvents.BackChannelLogout.Steps.LogoutTokenExpiryStep.ValidateAsync(Abblix.SecurityEvents.Validation.SecurityEventTokenValidationContext,System.Threading.CancellationToken).context}

The state accumulated by earlier steps\.

###### `cancellationToken` [System\.Threading\.CancellationToken](https://learn.microsoft.com/en-us/dotnet/api/system.threading.cancellationtoken 'System\.Threading\.CancellationToken') {#Abblix.SecurityEvents.BackChannelLogout.Steps.LogoutTokenExpiryStep.ValidateAsync(Abblix.SecurityEvents.Validation.SecurityEventTokenValidationContext,System.Threading.CancellationToken).cancellationToken}

Cancels I/O the step performs, such as key retrieval\.

Implements [ValidateAsync\(SecurityEventTokenValidationContext, CancellationToken\)](https://www.abblix.com/en/docs/api/abblix-securityevents/Abblix.SecurityEvents.Validation.ISecurityEventTokenValidator#Abblix.SecurityEvents.Validation.ISecurityEventTokenValidator.ValidateAsync(Abblix.SecurityEvents.Validation.SecurityEventTokenValidationContext,System.Threading.CancellationToken) 'Abblix\.SecurityEvents\.Validation\.ISecurityEventTokenValidator\.ValidateAsync\(Abblix\.SecurityEvents\.Validation\.SecurityEventTokenValidationContext, System\.Threading\.CancellationToken\)')

#### Returns
[System\.Threading\.Tasks\.ValueTask&lt;](https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.valuetask-1 'System\.Threading\.Tasks\.ValueTask\`1')[SecurityEventTokenValidationError](https://www.abblix.com/en/docs/api/abblix-securityevents/Abblix.SecurityEvents.Validation.SecurityEventTokenValidationError 'Abblix\.SecurityEvents\.Validation\.SecurityEventTokenValidationError')[&gt;](https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.valuetask-1 'System\.Threading\.Tasks\.ValueTask\`1')  
Null to pass the token on; an error to stop the pipeline with that verdict\.