This is probably a best practice, but we should be careful to not oversell the benefits. Unless you measure token lifetime in a small number of seconds, then it’s doubtful that any realistic attack will be stopped by this. It’s mostly useful at defending against opportunistic attacks - e.g. a token accidentally gets logged, but the logs aren’t examined very often. Sender-constrained/PoP tokens, avoiding passing tokens in URL parameters, and so on are better defences against this kind of thing.
There are two deployment scenarios when short-lived access token are essential though: 1. If you are employing the “self-contained RS” model (no introspection calls to the AS) and are using short-lived access tokens with a refresh token to force the client to check in with the AS periodically to allow token revocation. [1] 2. If you are using a blacklisting strategy to token revocation, in which case having a short token lifetime limits the amount of time you need to blacklist tokens for. On the other hand, is there ever a valid reason for having an access token be valid for 10 years or so? [1] https://www.ietf.org/mail-archive/web/oauth/current/msg06687.html — Neil > On 18 Dec 2018, at 08:55, Hannes Tschofenig <hannes.tschofe...@arm.com> wrote: > > Hi all, > > In a recent email conversation on the IETF ACE mailing list Ludwig Seitz > suggested that the expires_in claim in an access token should actually be > mandatory. > Intuitively it feels like access tokens shouldn't have an unrestricted > lifetime. I am curious whether recommendations would be useful here. > > RFC 6819 talks about the expires_in claim and says: > > 3.1.2. Limited Access Token Lifetime > > The protocol parameter "expires_in" allows an authorization server > (based on its policies or on behalf of the end user) to limit the > lifetime of an access token and to pass this information to the > client. This mechanism can be used to issue short-lived tokens to > OAuth clients that the authorization server deems less secure, or > where sending tokens over non-secure channels. > > draft-ietf-oauth-security-topics-10 only talks about refresh token expiry. > > In OpenID Connect the expires_in claim is also optional. > > Ciao > Hannes > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
