Table of Contents

Enum DapperStores

Namespace
Fdyay.IdentityServer.Dapper.Configuration
Assembly
Fdyay.IdentityServer.Dapper.dll

Selects which stores AddDapperStores backs with the database.

[Flags]
public enum DapperStores

Fields

None = 0

No store is backed by the database.

Configuration = 1

Clients, identity resources, API scopes and API resources.

PersistedGrants = 2

Authorization codes, refresh tokens, reference tokens and consent.

SigningKeys = 4

The automatically managed token signing keys.

PushedAuthorizationRequests = 8

Authorization requests pushed to the PAR endpoint.

DeviceFlowCodes = 16

Pending device authorizations, waiting for a user to approve them.

ServerSideSessions = 32

Signed-in browser sessions held server-side rather than only in the cookie.

Included in All deliberately, even though the feature itself is opt-in through AddServerSideSessions(). The store registration is what decides whether sessions survive a restart, and a host that asked for full database persistence and then silently got the in-memory store would find out in production, when the load balancer moved a user and signed them out. The cost of the other direction is an empty table on a host that never turns sessions on.

BackChannelAuthentication = 64

Pending CIBA requests, waiting for a user to answer them.

Wanted more than the device flow's equivalent, not less. A device authorization is answered within minutes by somebody holding the device; a backchannel request arrives with nobody in front of it and is answered whenever that person next reaches an approval surface — so the window in which the request has to be visible to every instance is the whole of its lifetime rather than the length of one sitting.

All = Configuration | PersistedGrants | SigningKeys | PushedAuthorizationRequests | DeviceFlowCodes | ServerSideSessions | BackChannelAuthentication

Everything. The default, so a host that says nothing gets full persistence.

Remarks

Configuration and operational state have different owners in most deployments. A host commonly curates its clients, scopes and resources in code — reviewed, diffed and deployed with the application — while grants and signing keys are runtime state that has to be shared across instances and therefore has to live in a database. Backing everything with Dapper would replace that in-code catalog with whatever rows happen to be in the Clients table, so the two are selectable separately.