Table of Contents

Class PersistentGrantOptions

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

What this server does with the grants it persists.

public sealed class PersistentGrantOptions
Inheritance
PersistentGrantOptions
Inherited Members

Properties

ConsumedRefreshTokenGracePeriod

How long after a OneTimeOnly refresh token is consumed it is still accepted if presented again. Zero — no grace, as in Duende's — by default. Ours: Duende's has no option, only the AcceptConsumedTokenAsync hook this sets.

public TimeSpan ConsumedRefreshTokenGracePeriod { get; set; }

Property Value

TimeSpan

Remarks

It widens the replay window by exactly this much. A consumed token presented within it is redeemed again — a fresh access token and a fresh refresh token, forking the lineage — and is not seen as a replay, so a copied handle used within it goes unnoticed. Measured from the first consumption, so presenting the token again does not extend it; after it a consumed token is a replay as before, refused, and its whole lineage revoked, forks included. Everything else is checked as for an unconsumed token. It is for a client that races itself — two instances of a BFF refreshing with one token, or a request carrying the old one just after a refresh landed — and is kept as short as that race. Has no effect with DeleteOneTimeOnlyRefreshTokensOnUse, which leaves nothing to accept. Negative is a configuration error: UseIdentityServer refuses it.

DataProtectData

Whether a persisted grant's Data is protected with the host's data protection ring before it is stored. On by default.

public bool DataProtectData { get; set; }

Property Value

bool

Remarks

What is in that column is why the default is on. A grant's Data is the serialized thing itself: for a refresh token or an authorization code, the whole claim set the subject was issued — every claim a profile service added included. Until 0.64.0 four stores wrote it as plaintext JSON, so the grant table held, in the clear, the full identity of everybody with a live session. The signing keys in that same database have been protected since key management shipped.

Turning it off does not make old rows unreadable, and neither does turning it on. This option governs writes only. A read always tries to unprotect and falls back to treating the value as plaintext, so a store holding both shapes at once — the ordinary state during an upgrade — reads correctly either way.

Off is a real choice, not a legacy setting. A host that keeps its grant store encrypted at rest by other means, or one that needs to read the column with a query rather than through this server, is not getting less protection by turning this off — it is getting the protection somewhere else. What it must not do is assume the column is unreadable while this is off.

DeleteOneTimeOnlyRefreshTokensOnUse

Whether a OneTimeOnly refresh token is deleted when it is used, rather than kept as consumed. Off by default. Duende's, whose default is on.

public bool DeleteOneTimeOnlyRefreshTokensOnUse { get; set; }

Property Value

bool

Remarks

On gives up replay detection. A consumed token presented again is the one sign that a handle was copied, and this server revokes the lineage when it sees one (RFC 9700 §4.14.2); a deleted token presented again is only unknown, refused without revoking anything, so the copy's successor lives on. Hence off here, where Duende's is on. On is for a host whose grant store must not keep used tokens until they expire.