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
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
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
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
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.