Is there a reason why the Auth plugin doesn't chec...

# ktor

[sindrenm]

Is there a reason why the Auth plugin doesn't check if Bearer tokens have expired before making a request, and instead relies on a 401 response to trigger the refresh? https://datatracker.ietf.org/doc/html/rfc6749#section-1.5 reads as follows:

(C)  The client makes a protected resource request to the resource
     server by presenting the access token.

(D)  The resource server validates the access token, and if valid,
     serves the request.

(E)  Steps (C) and (D) repeat until the access token expires.  If the
     client knows the access token expired, it skips to step (G);
     otherwise, it makes another protected resource request.

(F)  Since the access token is invalid, the resource server returns
     an invalid token error.

(G)  The client requests a new access token by authenticating with
     the authorization server and presenting the refresh token.  The
     client authentication requirements are based on the client type
     and on the authorization server policies.

Specifically the “If the client knows the access token expired, it skips to step (G), […]” part of (E) seems to be missing from the plugin, AFAICT.

[e5l]

@Rustam Siniukov could you please check?

[Rustam Siniukov]

Tokens are transparent for Ktor, and Ktor doesn’t know the specific format of the tokens users have in their apps. Maybe we can add a callback in the plugin for this. Can you create a feature request, please?

[sindrenm]

Given such a callback, I would just provide a way for the plugin to check if the tokens have expired, and if so, it could perform the refreshing pre-request? That seems like it would work fine for me, at least. I'll make a feature request! 👍

[sindrenm]

https://youtrack.jetbrains.com/issue/KTOR-6419/Feature-Request-Auth-Plugin-A-callback-to-tell-plugin-if-tokens-are-expired

[Fidelity Chauke]

Hi @e5l, I see that Rustam is no longer part of the chat. Do you know if the feature request will be picked up?

[Fidelity Chauke]

This question attended to by @Aleksei Tirman [JB] is in a similar vain 😅

[Kaira Diagne]

It would be greatly appreciated to have this feature added to the auth plugin. I’m coming from an iOS background and am still fairly new to Kotlin and KMP. On iOS, I’ve either implemented this myself or used Alamofire’s AuthenticationInterceptor, which defines an interface for credentials that allows the interceptor to check before adding the Authorization header whether a credential requires a refresh. The actual refresh logic is implemented by the application.

If a refresh is needed, the interceptor queues the requests that need to be adapted with the Authorization header, performs the refresh, and upon success, starts all queued requests. This avoids making requests with known-expired tokens which improves performance as it prevents making unneeded requests.

It could be valuable to support this as an optional behavior in the plugin, preserving backward compatibility. Since the logic is implemented by the plugin consumer, it would be flexible enough to accommodate different application setups—for example, some apps use JWTs with expiry claims in the token itself, while others rely on the authorization server returning a separate expires_in field.

Thanks for considering this!