MibIdentityConfig

Introduction

This configuration is intended for the MibIdentityConfig class, which manages identity and token-related settings for the MIB Authorization Server.

Since MEDIAIBOX-11999 the Authorization Server runs on OpenIddict (it previously ran on IdentityServer4). This file is now the home for token lifetimes and the refresh-token model — the equivalent keys in MibAuthorizationServerConfig (accessTokenMinutes / refreshTokenHours / authorizationCodeSeconds) are deprecated and no longer read.

Keys that are inert under OpenIddict (kept for compatibility, but ignored):

SigningCredentialCacheInterval / ValidationKeysCacheInterval — the key provider reads key material on demand (no cache).

UpdateAccessTokenClaimsOnRefresh — not honored; the principal is reused on refresh rather than rebuilt.

Also note: under IdentityServer4 the sliding refresh token had an absolute cap; OpenIddict does not enforce that cap natively.

Correction (since MEDIAIBOX-12136): TokenCleanUpBatchSize was previously documented here as inert ("the prune job does not batch"). That was wrong — the prune runs DELETE TOP (@batchSize) in a loop until exhausted, so the value is honored. A non-positive value is clamped to the safe default 1000. See the Grant cleanup and AUTH_GRANTS growth section below.

Keys - Default Section

TokenCleanUpServiceEnabled -> false
AuthorizationCleanUpEnabled -> false
TokenCleanUpInterval -> TimeSpan.MaxValue
TokenCleanUpBatchSize -> 1000
SigningCredentialCacheInterval -> 00:01:00
ValidationKeysCacheInterval -> 00:01:00
AbsoluteRefreshTokenLifetime -> 2592000
SlidingRefreshTokenLifetime -> 1296000
UpdateAccessTokenClaimsOnRefresh -> false
ReuseRefreshToken -> false
SlidingRefreshTokenExpiration -> false
AccessTokenLifetime -> 3600

Properties

TokenCleanUpServiceEnabled (boolean)

Enables the background service that prunes expired tokens from AUTH_GRANTS. When false (default) nothing is pruned and the table grows unbounded.
Default: false

AuthorizationCleanUpEnabled (boolean)

Enables pruning of authorization rows ([Type] = 'openiddict-authorization') in the same background service, in addition to tokens. Gated by a separate flag because authorization pruning is more expensive and higher-risk than token pruning; enable token cleanup first and turn this on once validated. Has no effect unless TokenCleanUpServiceEnabled is also true. An authorization is never removed while it is still valid or while it still has a live token attached (that would revoke an active session).
Default: false

TokenCleanUpInterval (TimeSpan)

Interval between prune runs. The first run happens at startup (after a short random 0–60s jitter to avoid a thundering herd across pods), then every TokenCleanUpInterval. TimeSpan.MaxValue (default) disables the service even if TokenCleanUpServiceEnabled is true.
Default: TimeSpan.MaxValue

TokenCleanUpBatchSize (int)

Rows deleted per DELETE TOP (@batchSize) iteration; the prune loops until the table is exhausted. Smaller batches hold locks for shorter periods on a large AUTH_GRANTS (less blocking, more round-trips); larger batches finish faster but hold locks longer. A non-positive value is clamped to the safe default 1000.
Default: 1000

SigningCredentialCacheInterval (TimeSpan)

Interval for refreshing signing credentials from cache.
Default: 00:01:00

ValidationKeysCacheInterval (TimeSpan)

Interval for refreshing validation keys from cache.
Default: 00:01:00

AbsoluteRefreshTokenLifetime (int)

Lifetime in seconds for refresh tokens with absolute expiration.
Default: 2592000 (30 days)

SlidingRefreshTokenLifetime (int)

Lifetime in seconds for refresh tokens with sliding expiration.
Default: 1296000 (15 days)

UpdateAccessTokenClaimsOnRefresh (boolean)

Indicates if access token claims should be updated on refresh.
Default: false

RefreshTokenUsage (enum: MibTokenUsage)

Determines if refresh tokens are reused or one-time only.
Default: OneTimeOnly (ReuseRefreshToken=false)

RefreshTokenExpiration (enum: MibTokenExpiration)

Determines if refresh tokens use sliding or absolute expiration.
Default: Absolute (SlidingRefreshTokenExpiration=false)

AccessTokenLifetime (int)

Lifetime in seconds for access tokens.
Default: 3600 (1 hour)

Grant cleanup and AUTH_GRANTS growth

All grants — access tokens, refresh tokens, and authorizations — are persisted as rows in the AUTH_GRANTS table. Two things drive its size, and both are governed by the keys above.

Why the table grows. The Authorization Server issues reference access tokens (server.UseReferenceAccessTokens()), so every access token issued is one row in AUTH_GRANTS. Reference tokens are kept deliberately: they are revocable server-side (a logout or a revoke takes effect immediately), which a CMS requires. The trade-off is volume — high-frequency machine-to-machine clients (ROPC) can create rows very quickly. Refresh-token rotation (ReuseRefreshToken=false) adds a new row per refresh, and authorization rows accumulate per grant.

Why it must be pruned. Nothing removes these rows unless the cleanup service is enabled and configured. If it is off (or TokenCleanUpInterval is left at TimeSpan.MaxValue), AUTH_GRANTS grows without bound; a very large table degrades every lookup and, in the extreme, times out POST /oauth/token. The service prunes expired tokens (always, when enabled) and, when AuthorizationCleanUpEnabled=true, stale authorizations (older than the run threshold and either not valid, or ad-hoc with no live token attached — never one still backing an active session).

Configuration trade-offs

Operators choose these values per environment. The table below maps each choice to its consequence so the trade-off is explicit — there is no single "correct" value.

Key / choice	Option	Consequence
Access-token model	Reference (current)	Revocable server-side (logout/revoke is immediate) — required for a CMS. Cost: one `AUTH_GRANTS` row per access token issued → growth.
	JWT (self-contained)	No per-token row (no growth from access tokens). Cost: not revocable until it expires — a security regression for an admin CMS. Not used; documented as the trade-off.
`TokenCleanUpServiceEnabled`	`false` (default)	No pruning → table grows unbounded. Fine only for short-lived/dev environments.
	`true`	Expired tokens are pruned each run. Recommended in production.
`AuthorizationCleanUpEnabled`	`false` (default)	Authorization rows are never pruned and accumulate. Enable token cleanup first; turn this on once validated.
	`true`	Authorization rows are pruned too. Higher cost (a JSON-correlated delete) but keeps the table bounded. Never removes a `valid` authorization or one with a live token.
`TokenCleanUpInterval`	Short (e.g. `00:10:00`)	Smaller backlog, table stays lean; more frequent delete overhead.
	Long (e.g. `24:00:00`)	Less overhead; larger backlog between runs. Note: the first prune runs at startup, so a long interval no longer means "never prunes" on short-lived pods.
`TokenCleanUpBatchSize`	Small	Shorter lock duration per iteration (less blocking on a big table); more round-trips.
	Large	Fewer round-trips; longer locks. Non-positive → clamped to `1000`.
`AccessTokenLifetime`	Short	More `/oauth/token` round-trips → more reference-token rows issued.
	Long	Fewer rows issued; larger exposure window per token.
`AbsoluteRefreshTokenLifetime` / `SlidingRefreshTokenLifetime`	Long	Refresh rows stay prunable-only for longer → more live rows at any time.
`ReuseRefreshToken`	`false` (default, one-time)	Each refresh rotates → new row per refresh (more volume, better security).
	`true` (reuse)	Fewer rows, less rotation.

Deployment note. Enabling cleanup on an AUTH_GRANTS that has already grown large is a size-of-data operation: the first prune (and the supporting index migrations from MEDIAIBOX-12136) hold locks. Schedule a maintenance window and/or build indexes ONLINE, and consider a one-time purge of the expired-grant backlog before turning the service on.

Example

Environment-variable form uses the MIBIDENTITYCONFIG_DEFAULT_ prefix (<PREFIX>_<SECTION>_<KEY>, section default).

MIBIDENTITYCONFIG_DEFAULT_TOKENCLEANUPSERVICEENABLED=true 
MIBIDENTITYCONFIG_DEFAULT_AUTHORIZATIONCLEANUPENABLED=true 
MIBIDENTITYCONFIG_DEFAULT_TOKENCLEANUPINTERVAL=01:00:00 
MIBIDENTITYCONFIG_DEFAULT_ABSOLUTEREFRESHTOKENLIFETIME=604800 
MIBIDENTITYCONFIG_DEFAULT_SLIDINGREFRESHTOKENLIFETIME=259200 
MIBIDENTITYCONFIG_DEFAULT_REUSEREFRESHTOKEN=true 
MIBIDENTITYCONFIG_DEFAULT_SLIDINGREFRESHTOKENEXPIRATION=true 
MIBIDENTITYCONFIG_DEFAULT_ACCESSTOKENLIFETIME=7200

Who uses this configuration?

MibAuthorizationServer
Identity-related services in the MIB platform

Table of Contents