Welcome to the Kinde community.
A
A
A
M
T
Two users are logged in to the app. userA has refreshTokenA, and userB has refreshTokenB.
When I make a POST request to /oauth2/token with grant_type: “refresh_token” and the refreshTokenA, the request succeeds.
If I now make a POST request to /oauth2/token with grant_type: “refresh_token” and the refreshTokenB, the request fails with 401: Client authentication failed (e.g., unknown client, no client authentication included, or unsupported authentication method)
Why is that?
The error you are encountering, "401: Client authentication failed," typically indicates an issue with the client authentication process. Here are a few potential reasons why the request with refreshTokenB might be failing: 1. *Invalid Client Credentials*: Ensure that the client credentials (client ID and client secret) used in the request are correct and match the ones associated with the application that issued refreshTokenB. 2. *Token Expiry or Invalidity*: RefreshTokenB might have expired or been invalidated. Refresh tokens can become invalid if they are used after their expiration time or if they have been rotated and the old token is no longer valid. 3. *Scope Issues*: The scope associated with refreshTokenB might not be valid or might not match the required scope for the token refresh request. 4. *Client Configuration*: The client application configuration might not support the refresh token grant type. Ensure that the client application is configured correctly to use the refresh token grant type. 5. *Network or Retry Issues*: There might be network issues or retry attempts that are causing the token to be considered invalid. Kinde allows a small overlap period when both a previous and new refresh token are valid to account for retries and bad network connections. To troubleshoot further, you can: • Verify the client credentials and ensure they are correct. • Check the validity and expiration of refreshTokenB. • Ensure the client application is configured to support the refresh token grant type. • Review the scopes associated with the refresh token. For more detailed information, you can refer to the documentation.
No, refreshTokenB does not get invalidated when you call `/oauth2/token` with refreshTokenA. Each refresh token is independent and specific to the user session it was issued for. Therefore, using refreshTokenA to obtain a new access token will not affect the validity of refreshTokenB. However, if you are encountering a "401: Client authentication failed" error when using refreshTokenB, it could be due to other reasons such as invalid client credentials, an expired or invalid refresh token, or issues with the client configuration. For more details on how refresh tokens work and potential issues, you can refer to the .
The issue you are encountering is likely due to the refresh token rotation mechanism implemented by Kinde. When you use refreshTokenA to obtain a new access token, Kinde also issues a new refresh token and invalidates the old one. This means that if you try to use refreshTokenB after using refreshTokenA, refreshTokenB might have been invalidated if it was issued before the refresh operation with refreshTokenA. Here are a few key points to consider: 1. *Refresh Token Rotation*: Kinde always rotates refresh tokens. When you use an existing refresh token to request a new access token, a new refresh token is generated and provided with your new access token. The old refresh token becomes immediately invalid. This is likely why refreshTokenB is failing after you use refreshTokenA. 2. *Overlap Period*: Kinde allows a small overlap period when both a previous and new refresh token are valid. This is to account for retries and bad network connections. However, this overlap period is short, and the old token will soon become invalid. 3. *Token Security*: Ensure that you are securely storing and managing refresh tokens. Using refresh token rotation and automatic reuse detection can help mitigate security risks. For more detailed information, you can refer to the .
When making a POST request to `/oauth2/token`, you can pass the following parameters: 1. *grant_type*: The type of grant being used. Common values include: • `authorization_code` • `refresh_token` • `client_credentials` • `password` 2. *client_id*: The unique ID of your application in Kinde. 3. *client_secret*: The client secret associated with your application. Note: Do not include this in frontend applications. 4. *code*: The authorization code received from the authorization server (used with `authorization_code` grant type). 5. *redirect_uri*: The URI to which the response will be sent. This must match the redirect URI used in the initial authorization request. 6. *refresh_token*: The refresh token issued to the client (used with `refresh_token` grant type). 7. *username*: The resource owner's username (used with `password` grant type). 8. *password*: The resource owner's password (used with `password` grant type). 9. *scope*: The scope of the access request. This can be a space-separated list of scopes. 10. *code_verifier*: A cryptographic random string used to correlate the authorization request to the token request (used with PKCE). 11. *audience*: The audience claim for the JWT. This can be used to protect your APIs and resource servers. For more detailed information, you can refer to the .
