Versions Compared

Old Version 1

changes.mady.by.user Former user

Saved on

compared with

New Version Current

changes.mady.by.user Former user

Saved on

Key

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

Users need access tokens to invoke APIs subscribed under an application. Access tokens are passed in the HTTP header when invoking APIs. The API Manager provides a Token API that you can use to generate and renew user and application access tokens. The response of the Token API is a JSON message. You extract the token from the JSON and pass it with an HTTP Authorization header to access the API.

...

Localtabgroup
Localtab
activetrue
idoption2-format
titleFormat
Code Block
curl -k -v -d "token=<REFRESH_TOKEN_TO_BE_REVOKED>&token_type_hint=<access_token_or_refresh_token>" -H "Authorization: Basic <base64 encoded (clientId:clientSecret)>" -H "Content-Type: application/x-www-form-urlencoded" https://localhost:8243/revoke
Localtab
idoption2-example
titleExample
Code Block
curl -k -v -d "token=1d18ec65-6151-3499-9352-68afe64299c3&token_type_hint=access_token" -H "Authorization: Basic OVRRNVJLZWFhVGZGeUpRSkRzam9aZmp4UkhjYTpDZnJ3ZXRual9ZOTdSSzFTZWlWQWx1aXdVVmth" -H "Content-Type: application/x-www-form-urlencoded" https://localhost:8243/revoke

...

Table of Content Zone
maxLevel5
minLevel5
locationtop
CON_APP_KEY constraint

CONSTRAINT CON_APP_KEY UNIQUE (CONSUMER_KEY, AUTHZ_USER,USER_TYPE,TOKEN_STATE,TOKEN_STATE_ID,TOKEN_SCOPE)

As seen in the code snippet above 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.

Info

The above scenario is unlikely, because in practice an application is usually designed to handle this situation using scopes, or in the case of a multi-threaded client, there is usually a separate thread to acquire access tokens so that other threads can retrieve from it.

Asynchronous token persistence

Flow

For instance, if the violation mentioned above occurs with two nodes of a cluster receiving identical access token requests, the flow of the asynchronous token persistence is as follows:

  1. The client sends an access token request. 

  2. The OAuth2 component in both nodes of WSO2 API-M checks for an existing active access token for the given client/user/scope. Both nodes first check the cache and if an active token is not found, the it checks the database. 

  3. If an existing active access token is found, the token is returned to the client. 
  4. Alternatively, if an existing access token is not found, the OAuth2 component in both nodes creates a new access token and adds it to the persisting queue. 
  5. After adding it to the queue, the access token is returned to the client.
  6. However, the background threads that consume the persisting queue in both servers (nodes) attempt to persist the token to the database. One of the servers succeed and successfully persist the access token to the database, and the other server receives an error due to violation of the CON_APP_KEY constraint. The violation is due to the fact that the same access token was already persisted by the first server in the cluster and is currently active. 

Recovery flow

To handle this situation, WSO2 API Manager has a recovery flow for token persistence that does the following:

  • As both access tokens were returned to the client, there must be a database entry for both tokens. 
  • As the access token that the second node is attempting to persist is not allowed due to the violation, the recovery flow takes the latest entry in the database, which is the active access token persisted by the first node, and marks it as INACTIVE. 
  • The access token that is received from the second node is now saved as an ACTIVE access token in the database. Therefore, one of the access tokens returned to the client is an INACTIVE token. 
Tip

Tip: If the client application is not designed to handle the CONN_APP_KEY constraint violation using scopes, you can avoid the situation described above and avoid any invalid tokens by using synchronous token persistence. To do this, set the <PoolSize> property in the <API-M_HOME>/repository/conf/identity/identity.xml file to 0.

Synchronous token persistence 

Flow

The flow of the synchronous token persistence when receiving two identical access token requests is as follows:

  1. The client sends an access token request. 

  2. The OAuth2 component in both nodes of WSO2 API-M checks for an existing active access token for the given client/user/scope. Both nodes first check the cache and if an active token is not found, the database is checked. 

  3. If an existing active access token is found, the token is returned to the client. 
  4. Alternatively, if an existing access token is not found, the OAuth2 component in both nodes creates a new access token and persists the access token to the database using the same thread. 
  5. Either one of the nodes persist the token successfully and returns it to the client, but the other node receives an error due to violation of the CON_APP_KEY constraint.

Recovery flow

The process flow now moves on to the recovery flow described above in order to handle the CON_APP_KEY constraint violation and is executed as follows:

  • As the same thread is being used, the OAuth2 component in the second node checks the database again for an ACTIVE access token. 
  • As there is now an ACTIVE token, which was persisted by the first node, the second node now returns the access token persisted by the first node to the client. 
  • Both access token requests receive the same access token.