Is there a way for the server to indicate that the bearer token expiration is too long and to renegotiate the expiry date? The downside is:
It requires an additional logic step to be added to the server code or a proxy somewhere before it like an API gateway (so that you don't have different expiry logic spread all over the application space).
It may require the renewal of the bearer token for other apps that use the same token, since the most restrictive expiry policy would determine the expiry policy for all other apps using that token.
But that seems like what we want. You might get some increased traffic, to renew the tokens, but as long as the bearer token expiring has some reasonable minimum level (a few mins, maybe?) then that should be lost in the regular traffic noise.
The challenge is whether that use case is available via the bearer token protocol. If not, it's possible to implement it on the server-side with a proxy keeping track of tokens and their expiration and how long they have been used by the system. If a token has been used longer than your expiry policy then reject that token to force a re-issue. But just because you can doesn't mean it's easy or that you should. A proxy that does this expiry tracing has lots of potential for misconfiguration, complicated edge cases, and possibly abuse. It would be better if the protocol allowed for expiry-based policy negotiation as part of the token auth process, and leave the expiry check for the protocol.
Power management, mobile and firmware developer on Linux. Security developer at Aurora. Ex-biologist. mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer. Also on Mastodon.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
RE: Bearer tokens are just awful
Date: 2022-04-05 03:41 pm (UTC)Is there a way for the server to indicate that the bearer token expiration is too long and to renegotiate the expiry date? The downside is:
But that seems like what we want. You might get some increased traffic, to renew the tokens, but as long as the bearer token expiring has some reasonable minimum level (a few mins, maybe?) then that should be lost in the regular traffic noise.
The challenge is whether that use case is available via the bearer token protocol. If not, it's possible to implement it on the server-side with a proxy keeping track of tokens and their expiration and how long they have been used by the system. If a token has been used longer than your expiry policy then reject that token to force a re-issue. But just because you can doesn't mean it's easy or that you should. A proxy that does this expiry tracing has lots of potential for misconfiguration, complicated edge cases, and possibly abuse. It would be better if the protocol allowed for expiry-based policy negotiation as part of the token auth process, and leave the expiry check for the protocol.