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).
...
| Tip | |||||
|---|---|---|---|---|---|
| |||||
To enable synchronous token persistence, open the
|
...
| Property | Description | Sample value |
|---|---|---|
| Enable | To enable token persistence | 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 means Synchronous and greater than 0 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.
...