Inconsistency around the rotating refresh tokens

Problem statement

When creating clients with refresh tokens using the Management API, we notice different behaviour depending on the value of the field called “token_endpoint_auth_method”. When the token_endpoint_auth_method is set to “none” and we specify the token_lifetime of the refresh token, then the token_lifetime is set as the absolute expiration, which is the expected behaviour. In this case inactivity expiration is also set without us specifying an idle_token_lifetime.

Whereas if the token_endpoint_auth_method is set to “client_secret_post”, an Inactivity expiration is set and not the absolute expiration. In this case, we specify a token lifetime and not an idle token lifetime. Therefore, the expected behaviour would be to set the absolute expiration.
By default the token_endpoint_auth_method seems to be set to “none” for native clients and “client_secret_post” for the regular web apps. Therefore when we create web apps, no absolute expiration is set for refresh tokens.

This seems like an incorrect behaviour, could you let us know if this is expected? If so, why does the token_endpoint_auth_method affect the refresh token expiration?

Solution

This is a correct and expected behavior. Sending "token_endpoint_auth_method": "client_secret_post" implicitly assumes this is a confidential application which has a higher default value for token_lifetime (1 year) whereas "token_endpoint_auth_method": "none" assumes a public client with a shorter lifetime (30 days)