This guide describes OAuth2 token persistence and the possible approaches you can follow for token persistence in a production environment. The OAuth2 component in WSO2 Identity Server has two implementations that can be used to handle token persistence in the database (synchronous and asynchronous token persistence).
...
.
The following sections guide you through the difference between these two approaches and how to configure them.
...
Asynchronous token persistence
| Warning |
|---|
Previously, WSO2 recommended asynchronous token persistence for certain scenarios. However, we have empirically found out that synchronous token persistence has a better overall performance in general. Hence, we recommend the use of synchronous token persistence over asynchronous token persistence throughout. |
The flow of asynchronous token persistence is as follows:
...
| Property | Description | Sample value |
|---|---|---|
| Enable | To enable token persistence, this should be 'true'. | true |
| PoolSize | The value here determines the number of threads in the thread pool that are used to consume the token persisting queue. Having PoolSize 0 indicates it is 'synchronous' while greater than 0 indicates it is 'asynchronous'. | 100 |
| RetryCount | This indicates how many times to retry when storing the access token in an event of a con_app_key violation. | 5 |
| Info |
|---|
The main difference between synchronous and asynchronous token persistence is that the OAuth2 component in the synchronous token persistence implementation waits for the access token to be persisted in the database before returning it to the client. |
...
For a given set of consumer key, user, and scope values, there can be only one ACTIVE access token. The CON_APP_KEY constraint in the IDN_OAUTH2_ACCESS_TOKEN table enforces this by allowing only one active access token for a given set of consumer key, user, and scope values. This constraint may be violated in a scenario where two or more identical token requests come from the same application.
...