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 = 0No store is backed by the database.
Configuration = 1Clients, identity resources, API scopes and API resources.
PersistedGrants = 2Authorization codes, refresh tokens, reference tokens and consent.
SigningKeys = 4The automatically managed token signing keys.
PushedAuthorizationRequests = 8Authorization requests pushed to the PAR endpoint.
DeviceFlowCodes = 16Pending device authorizations, waiting for a user to approve them.
ServerSideSessions = 32Signed-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 = 64Pending 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 | BackChannelAuthenticationEverything. 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.