在 WSO2 API-Manager 中创建一个新的访问令牌而不撤销前一个访问令牌

Question

Based on our gateway roles, applications have to authenticate them selves through following Curl

curl --location --request POST 'https://localhost:9443/oauth2/token' \
--header 'Authorization: Basic BASIC-TOKEN' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Cookie: cookiesession1=678B2889RTUVWXYZABCDEFGHIJKLE170' \
--data-urlencode 'grant_type=password' \
--data-urlencode 'username=USERNAME' \
--data-urlencode 'password=PASSWORD'

The problem is, each time that I call https://localhost:9443/oauth2/token the system provides a new access-token. Also the previous access token would be expired.

Even if I Call https://localhost:9443/oauth2/token with REFRESH-TOKEN grand-type, the system provides me new access-token again.

I cannot understand differences between REFRESH-TOKEN and PASSWORD grand-type. Why both procedure expired the available access-token and generate a new one?

How can I call https://localhost:9443/oauth2/token and get the available access-token rather than generating a new access-token?

Answer 1

This is the default behavior of the JWT access tokens. With JWT token, keymanager does not persist a complete JWT access token in the database but only the JTI value of the JWT token. Therefore there is no way to get the same access token from the /token call even if the token is not expired. That's why every request generates a new token.

In both password and refresh token grant types, you are renewing the previous access token. With the password grant type, you use the username and password combination while with the refresh grant type, you use the refresh token from a previous token call. Both follow the same approach where a new token will be issued with each token call while revoking the previous one[1]. This is the default behavior and you can't change it unless you customize the token issuer. Please find the article [2] which explains how to customize the token generation flow.

If you use opaque tokens, you can achieve your requirement[3], however, dev portal applications do not support opaque tokens and you have to manually create the Service provider for each application with the token issuer as default instead of JWT.

[1] - https://github.com/arunans23/identity-inbound-auth-oauth-1/blob/master/components/org.wso2.carbon.identity.oauth/src/main/java/org/wso2/carbon/identity/oauth2/token/handlers/grant/AbstractAuthorizationGrantHandler.java#L337
[2] - https://wso2.com/blogs/thesource/generate-customized-tokens-in-wso2-api-manager/
[3] - https://apim.docs.wso2.com/en/latest/design/api-security/oauth2/token-persistence/#token-persistence

Answer 2

Just to add more context from the product architecture/ design perspective this was done to reduce the number of call between key manager and gateway. This is by design and not a bug.