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