Question: Is it a correct approach in terms of security to define a separate JWT policy for each method?

Answer: No. Due to its structure, JWT is an authentication method that is more accurate to apply to all methods at once. If authorization is required for methods, an approach as described on the Authorization page with scope definition would be used.


Question: What happens to old tokens?

Answer: A token never expires if the Token Never Expires option is checked. When it is not checked, a task running in the background periodically cleans up expired OAuth2 tokens. If expired JWT tokens are sent, a policy error occurs. Regardless of this, the log records of token requests are never deleted. 


Question: Can the last token continue to be used when the count specified with the Refresh Token Count parameter is reached? Or will this token become invalid if it is tried to be renewed again during its lifetime?

Answer: Refresh requests exceeding the number specified by the Refresh Token Count parameter will fail. Such a refresh request will not cause any change and the token will continue to live until the its expiration.

Each successful refresh generates a new token, invalidating the currently used OAuth2 token. Since the JWT token cannot be changed after it is created due to its nature, even if a new one is created, the old one continues to live for its lifetime.


Question: If a refresh request is made to an expired token, will the token be refreshed?

Answer: Refresh requests are independent of the token's lifetime. What matters is the lifetime of the Refresh Token. This period starts when the token is received. The user refreshes the token either as soon as the token is received or after the token dies (at a time before the Refresh Token expires).

  • Example 1: If a token that will work for a total of 60 seconds has been refreshed 3 times and has a life time of 60 seconds on each refresh, it is possible for this token to live for a total of 60 + (60 - 60) + (2 * 60) = 180 seconds. Because the first Refresh Token's lifetime starts from the moment the token is received, and in this example it can live as long as the token.
  • Example 2:  If a token that will work for a total of 60 seconds has been refreshed 3 times and has a life time of 180 seconds on each refresh, it is possible for this token to live for a total of 60 + (180 - 60) + (2 * 180) = 540 seconds. Because the lifetime of the first refresh token lifetime starts from the moment the token is received, and in this example it can live 120 seconds more.  


Question: Can I send a request to another API Proxy with the token received for an API Proxy?

Answer: No, a token can only be used for the API Proxy it was received for. However, as a special case, a token received with the API Proxy Group key can be used for all API Proxies within the group.


Question: I've reached the Refresh Token Count parameter's value. What happens if I try to refresh the token?

Answer: In the first refresh request that will exceed the Refresh Token Count, an error message is received stating that the refresh count was exceeded. In subsequent requests, an error message is received such as "token not found" as this token will be cleared. In this process, the token acquired in the last renewal can continue to be used as long as its lifetime is not expired.


Question: One more Refresh Token comes with each refresh request. Why?

Answer: The Refresh Token generated is unique for each token. In case of forgetting, it is re-displayed with the Refresh Token at each token refresh.


Question: Are there any cases that the token cannot be used even if the Token Never Expires option is checked?

Answer:  Yes. Token becomes invalid for the cases below:

If token management is done via API Proxy Management;

  • If the API Proxy that the token is received for is undeployed,
  • If the private key of the API Proxy that the token is received for is changed,
  • If the token is a JWT token and the JWT token authentication key of the Environment is changed.

If token management is done via Credential Management;

  • If the Crdential that the token is received for is undeployed,
  • If the private key of the Credential that the token is received for is changed,
  • If the token is a JWT token and the JWT token authentication key of the Environment is changed.