Table of Contents

Class DPoPOptions

Namespace
Fdyay.IdentityServer.Configuration
Assembly
Fdyay.IdentityServer.Core.dll

Options for DPoP proof validation (RFC 9449).

public class DPoPOptions
Inheritance
DPoPOptions
Inherited Members

Remarks

The other way to sender-constrain a token, and the one a client with no certificate can use. mTLS binds to something the transport already proved; DPoP binds to a key the client proves per request, which is why these options are almost entirely about time — a proof is only worth anything for as long as it cannot be replayed.

Properties

ClientClockSkew

How far a client's clock may run ahead of this server's. Defaults to five minutes.

public TimeSpan ClientClockSkew { get; set; }

Property Value

TimeSpan

Remarks

Separate from the validity window because they answer different questions: the window is how long a proof lives, this is how wrong the client's idea of "now" may be. Folding them together would mean tolerating a skewed clock by keeping every proof alive longer, for every client.

ProofTokenValidityDuration

How long a proof stays acceptable after the iat it carries. Defaults to one minute.

public TimeSpan ProofTokenValidityDuration { get; set; }

Property Value

TimeSpan

Remarks

The window in which a stolen proof still works, so it wants to be short. It is not the only thing stopping a replay — every jti is remembered for at least this long — but it is what bounds how much has to be remembered.

ServerClockSkew

How far the servers in a farm may disagree about the time when a DPoP nonce one of them issued is checked by another. Defaults to zero, as in Duende.

public TimeSpan ServerClockSkew { get; set; }

Property Value

TimeSpan

Remarks

A nonce is accepted for ProofTokenValidityDuration after it was issued, plus this.

SupportedSigningAlgorithms

The signing algorithms a proof may use.

public ICollection<string> SupportedSigningAlgorithms { get; }

Property Value

ICollection<string>

Remarks

Asymmetric only, and stated rather than inferred: a proof is a signature by a key the client embeds in the proof itself, so accepting a symmetric algorithm would accept a proof signed by a key the attacker chose. Discovery advertises exactly this list, so a client is never told about an algorithm this server would then refuse.