Lack of a Clear Definition for Refresh Token Issuance and Renewal

[indeewari]

Describe the issue: Recently, we observed a change in the refresh token behaviour in IS 5.11.360 compared to IS 5.11.0. We needed to delve deeper into this matter due to conflicting ideas, varying competitor behaviours, and the lack of direct specification definitions.

The specific issue[1] arose when the access token is a JWT. WSO2 IS issues a new access token with the same refresh token for each authentication request at the authorization code grant. The customer was accustomed to a new refresh token for each authentication request, regardless of the refresh token's expiry.

We analyzed the issue by testing various IS versions. The following table shows how the token response populates the access token and the refresh token for the authorization code grant/password grant, given the access token type is JWT and opaque.

Please note that the following tests were conducted using the same client ID and set of scopes.

IS version	Opaque access token renewed per request	Refresh token renewed per request	JWT access token renewed per request	Refresh token renewed per request
IS 5.10.0	NO	NO	YES	YES
IS 5.11.0	NO	NO	YES	YES
IS 5.11.360	NO	NO	YES	NO
IS 7	NO	NO	YES	NO

The setup included the following server configurations:

renew_refresh_token = true extend_refresh_token_expiry_time_on_renewal = true renew_access_token_per_request = false

We also found this issue[2], which expected behaviour contrary to the current issue[1]. In other words, we observed two clients expecting two different default behaviours of the refresh token when the access token is JWT in the authorization code grant.

Due to these contradicting behaviours, we searched for relevant specifications, competitor practices, and insights from the OAuth community.

Specifications: There is no mandate for issuing a new refresh token for each authentication request for either JWT or opaque access tokens. The specifications highlight two main ways of handling refresh tokens:

• Short-lived access token and long-lived refresh token.
• Refresh token rotation.

Competitors: We checked with VendorA and VendorB for code grants.

VendorA: VendorA sends the refresh token only with the first token response, where user consent is requested in the code grant. After that, VendorA does not send a refresh token for the same authentication parameters. The issued refresh token can be used for the refresh grant until it expires, and the refresh grant issues only an access token, not a new refresh token.

VendorB: VendorB issues JWT access tokens by default. The code grant authentication issues a new access token and a new refresh token for each grant request. All access tokens are valid until they expire, and only the latest refresh token is valid until it expires or a new refresh token is issued.

OAuth Community: The OAuth community suggests that every code grant request should receive a new access token and a new refresh token (unrelated to any previous ones), regardless of whether the access token type is JWT or opaque.

Summary

Based on these external implementations and ideas, there are two ways of implementing refresh token issuance behaviours, regardless of the token type (JWT/opaque):

• Short-lived access token and long-lived refresh token based on the token expiration.
• New access token and new refresh token for each authentication request.

WSO2 IS defaults to "short-lived access token and long-lived refresh token based on the token expiration". The behaviour of issuing a new access token and a new refresh token for each authentication request can be achieved via the renew_access_token_per_request configuration in WSO2 IS.

[1] https://github.com/wso2/product-is/issues/20684 [2] https://github.com/wso2/product-is/issues/10684

How to reproduce: As mentioned in the table above

Expected behavior: WSO2IS should have a clear definition of refresh token issuance and renewal considering the oAuth community insights and customer requirements.

Environment information (Please complete the following information; remove any unnecessary fields) :

• Product Version: [e.g., IS 5.10.0, IS 5.9.0]
• OS: [e.g., Windows, Linux, Mac]
• Database: [e.g., MySQL, H2]
• Userstore: [e.g., LDAP, JDBC]

---

Optional Fields

Related issues:

• https://github.com/wso2/product-is/issues/20684
• https://github.com/wso2/product-is/issues/10684

Suggested labels: