Access token lifetime

[Joseph Heenan]

It was discussed on today’s WG call (in the context of https://bitbucket.org/openid/fapi/issues/526/decide-on-b-access-token-injection-with-id#comment-64002944 ) that there currently doesn’t seem to be anything said about the lifetime of access tokens.

There seemed to be a consensus to possibly saying something on the subject.

A possible initial suggestion:

‌

Authorization servers issuing long-lived grants (e.g. months) should issue short lived access tokens combined with refresh tokens. This allows clients to rotate the sender-constraining keys without loss of grants, either because of compromise of the key or as part of good security hygiene.

‌

[Dima Postnikov]

(e.g. days, months or years) may be?

[Nat Sakimura]

Need a consensus this week.

[Daniel Fett]

In the context of PSD2, 90 days is a “magic number” after which, re-authentication (now re-authorization) of the user’s access is required. The (e.g. months) part leaves open if we consider 90 days a long time. Maybe it would be better to suggest (e.g. some weeks).

[Nat Sakimura]

As a user, it gets quite annoying. I have so many accounts, and it amounts to like every couple of days. Before it was turned into APIs with a timeout, it was pretty smooth, but the UX now sucks. I am not sure if such a timeout actually adds to security. If it is for reminding the users, I feel that it should be a part of grant management and not the lifetime of access token or refresh token.

[Joseph Heenan]

PR: https://bitbucket.org/openid/fapi/pull-requests/374/fapi2sp-add-clause-about-access-token

[Joseph Heenan]

I’m not sure I follow your comment Nat, or at least I don’t see the relevance to the suggested text (which won’t affect UX).

For what it’s worth, the UK has already extended the 90 day requirements for the user to reauthorise access, and I believe the EU is moving (more slowly) in the same direction.

[Dave Tonge]

I’ve merged the PR, however there is this comment from Dima:

There is a usability trade off for the clients too. If time to live is too short they might be forced to refresh at before they could complete what they needs to do…

‌

[Joseph Heenan]

The PR added the text:

There is a performance and resiliency trade off, setting the access token life time too short can increase the load on and dependency on the authorization server.

My response to Dima was:

I thought perhaps “performance” captures that. (With perhaps the addition that I think any client developer that makes a bet by not writing the code to support refreshing an rejected access token is making a bad bet.)

i.e. even if an operation normally completes before an access token expires, it’s a bad idea to skip implementing refresh tokens in your client, and FAPI2 already requires clients to support refresh tokens.

I’m not sure how to further clarify the text. @Dima Postnikov if you have any suggestions for wording please let us know.

[Nat Sakimura]

Waiting for Dima’s response to close re: PR for this ticket.

[Dima Postnikov]

can close it now

[Dima Postnikov]

resolved. pr merged