Skip to content

Persisted Grants

The OAuth 2.0 specification is a flexible authorization framework that describes a number of grants (“methods”) for a client application to acquire an access token (which represents a user’s permission for the client to access their data) which can be used to authenticate a request to an API endpoint. There are different types of tokens that must be temporally stored in order to support the authentication flows in subsequent requests.

  • Authorization Code is required for hybrid flow when a user is being authenticated and has a lifetime of 300 seconds (by default) and only is used once per login process. Ideally it should be deleted when the login process is completed or it expires.
  • Refresh Token is generated once per login process and updated each time a user ask for a new Access Token and it has a sliding lifetime of 30 days (by default). It is removed when a user sign-out.

All those tokens (or grants) are persisted in the [authentication].[PersistedGrant] table.

How to manage persisted grants

Information stored at persisted grants are not configuration, it is runtime data. There are no needs for managing this information as this is internally done by security security. However, it could be required to perform some housekeeping tasks.

Housekeeping

In some scenarios is possible that persisted grant are not removed; this can cause this table keep growing affecting the performance of the application due to storing out of date grants. The housekeeping process handles the removal of expired grants. This process can be triggered:

Scheduled background job

Automatically triggered in a scheduled background job. The schedule job is hosted by Security Rest API, and works like a daemon trying to impact as less as possible to the system.

The housekeeping execution removes the oldest out of date grants in batches (batchSize), during a period of time (from fromUTC to toUTC), each execution occurs with an interval ot time (interval). It can be configured setting table in database customising below settings: * enabled: Enables the scheduled housekeeping job (false by default) * batchSize: Maximum number of rows affected in each execution (Default value: 1000). * fromUTC: When execution period starts (timespan format, by default 00:05) * toUTC: When execution period ends (timespan format, by default 05:00) * interval: Interval when each execution is performed (By default 15 minutes)

Samples of configurations:

  • "fromUTC and toUTC hours each interval minutes": ie from 00:05 to 03:00 each 15 minutes
  • "When fromUTC > toUTC, use toUTC = 01.XX:XX": ie from 22:05 to 01.00:05

API request

Manually sending a request to the PersistedGrants resources, at endpoint DELETE /Authentication/PersistedGrants.

For manually deletions we remove in batches as for automatic deletions, the response indicates if there was row deleted or not. So caller will know if there are more rows to delete or not.