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.

@Rustam Siniukov could you please check?

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?

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! 👍