Versions Compared

Old Version 3

changes.mady.by.user Former user

Saved on

compared with

New Version 4

changes.mady.by.user Former user

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

Asynchronous and synchronous behavior is governed by the <PoolSize> property found under the <SessionDataPersist> element in the <IS_HOME>/repository/conf/identity/identity.xml file. For more information about the properties related to persistence, see Authentication Session Persistence.

...

Tip
titleEnabling asynchronous token persistence

To enable asynchronous token persistence, open the <IS_HOME>/repository/conf/identity/identity.xml file and do the following changes under 'configs related to OAuth2 token persistence':

Code Block
languagexml
<TokenPersistence>
   <Enable>true</Enable>
   <PoolSize>100</PoolSize>
   <RetryCount>5</RetryCount>
</TokenPersistence>

The

...

following table describes what each of the above attributes means:

AttributeDescriptionValue
EnableTo enable token persistencetrue
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
RetryCountThis 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.

...