proposal/discussion: OAuth: requirement for refresh_token lifetime

[elarlang]

spin-off from #1925 "proposal 7", from @TobiasAhnoff

7 Verify that refresh-tokens expires according to threat model and business requirements

Proppoal from Elar:

The refresh_token topic requires more attention. But there is more than one point of view.

It is different attitude, is the OAuth used as first-party or 3rd party solution. For the first-party and "session management replacement" (which should be disallowed or not recommended) I would say we can apply V3.3 Session Timeout and V3.8 Session Termination requirements.

#	Description	L1	L2	L3	CWE	NIST §
3.3.2	[MODIFIED, SPLIT TO 3.3.5] Verify that there is an absolute maximum session lifetime such that re-authentication is required at least every 30 days for L1 applications or every 12 hours for L2 and L3 applications.	✓	✓	✓	613	7.2

For 3rd party solution, we have a requirement currently located in 3.5.1 (it is subject to change via #1917 (comment))

#	Description	L1	L2	L3	CWE	NIST §
3.5.1	[GRAMMAR] Verify that the application allows users to revoke OAuth tokens that form trust relationships with linked applications.		✓	✓	290	7.1.2

I think we need to be really precise, about what architecture and solution we address with the requirement.

One extra issue to cover with the refresh_token topic expiration is that with new refresh_token the AS must keep the exp value like it was before (and not extend it).

[elarlang]

I move discussion from #2040 (comment) to this issue. The latest proposal:

Verify that refresh tokens have an absolute expiration. Even if sliding refresh token expiration is applied, user re-authentication should be forced at some point in time. Note that how often depends on the application in scope, from e g hours to months. (L1, L2, L3)

[elarlang]

Proposed update:

Verify that refresh tokens have an absolute expiration. Even if sliding refresh token expiration is applied, user re-authentication must be forced after a defined absolute lifetime.

[randomstuff]

We are in OAuth, so we are talking about authorization but …

Even if sliding refresh token expiration is applied, user re-authentication should be forced at some point in time.

Do we need to talk about re-authentication here or about re-authorization? Would it be considered bad practice to re-authorize without going through all the OAuth flow dance?

Would it be OK if the authorization server was sending you a notification saying "authorization XXX which was granted for application YYYY is about to expire" and then you could expand its lifetime from the authorization server instead? One downside of this approach is that there might be a higher chance that a rogue application/instance would impersonate a legitimate one.

[TobiasAhnoff]

Verify that refresh tokens have an absolute expiration. Even if sliding refresh token expiration is applied, user re-authentication must be forced after a defined absolute lifetime.

I believe this is correct, at some point the user should re-authenticate doing the full "OAuth dance" to prove that the user is in control of the users credentials (in example MFA), not allowing "forever sliding" refresh tokens (or sessions).

But as @randomstuff noted, the way this was written it is unclear (or if it also forbids) the use of re-authorization, which was not intended...perhaps this will make it clearer?

Verify that refresh tokens have an absolute expiration. Even if sliding refresh token expiration is applied, user re-authentication must be forced after a defined absolute lifetime. Note that before the absolute expiration point in time, sliding expiration might be applied allowing the user to re-authorize presenting a valid refresh token. (L1,L2,L3)

[elarlang]

Note that before the absolute expiration point in time, sliding expiration might be applied allowing ...

Even in this case sliding can not go over refresh token expiration time.

Verify that refresh tokens have an absolute expiration. Even if sliding refresh token expiration is applied, user re-authentication must be forced after a defined absolute lifetime. Before the absolute expiration point, the application should allow the user to re-authorize by presenting a valid refresh token.

At the same time I'm not convinced we should cover to extension in the same requirement, Maybe the focus should be only on the expiration time.

[jmanico]

I do not think refresh-refresh or expiration is enough of a control for refresh tokens in L 2/3 apps. FAPI mandates sender-constrained tokens using Mutual TLS (MTLS), Proof of Possession (PoP) or similar - to avoid any kind of token theft reuse - which is still possible even with refresh-refresh or tight expiration windows. I think is a very wise constraint from FAPI that we should emulate.

[randomstuff]

But as @randomstuff noted, the way this was written it is unclear (or if it also forbids) the use of re-authorization, which was not intended...perhaps this will make it clearer?

@TobiasAhnoff, This is actually not what I meant, sorry :)

[randomstuff]

I do not think refresh-refresh or expiration is enough of a control for refresh tokens in L 2/3 apps.

FAPI mandates sender-constrained tokens using Mutual TLS (MTLS), Proof of Possession (PoP) or similar

@jmanico, I don't think anyone was saying that refresh token expiration was in any way an alternative to sender-constrained tokens. The idea here is that is that all grants should eventually expire after a given duration even if it tokens are being refreshed periodically.

The proposal from #2040 (comment) was “user re-authentication should be forced at some point in time» i.e. OAuth 2.0 code flow should be done again after this duration.

My argument was that the authorization server might accept other methods for extending the duration of the grant through user interaction involving verification of the user consent.