proposal/discussion: OAuth: requirement for refresh_token lifetime
elarlang opened this issue · comments
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).