V51 revokation for OAuth tokens

[elarlang]

Spin-off from #2040 (comment)

Verify that refresh tokens and reference access tokens can be revoked by an authorized user, using the AS user interface, or by a client using AS APIs for revocation. (L1, L2, L3)

There is feedback for the proposal in #2040 (comment) to take into account.

We have requirements:

#	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
3.5.7	[ADDED] Verify that all active stateless tokens, which are being relied upon for access control decisions, are revoked when admins change the entitlements or roles of the user.	✓	✓	✓	613

The requirement 3.5.1 is proposed to move to OAuth paragraph in #1917.

The requirement 3.5.7 is proposed to move to Access Control paragraph in #1917, also discussed in #2059

[TobiasAhnoff]

Sounds good to move 3.5.1 to the OAuth chapter. In #2040 @randomstuff suggests to have two requirements to address this:

Verify that the user can revoke their grants by using the AS user interface and that this revokes any refresh tokens and reference access tokens associated with that grant (L1, L2, L3).

Verify that refresh tokens and reference access tokens can be revoked by a client using AS APIs (revocation endpoint) for revocation. (L1, L2, L3).

I think this is good (perhaps change grant to consent?) and, if added, they replace 3.5.1.

[elarlang]

I don't think we can or need to require end-user access to the authorization server interface where they can revoke tokens.

The user must have functionality and possibility to revoke given permissions, how this is technically achieved is out of ASVS scope.

I used initial proposal and modified it a bit:

Verify that refresh tokens and reference access tokens can be revoked by an authorized user. It can be achieved by using the authorization server user interface, or by a client that is using authorization server APIs for revocation.

[randomstuff]

I don't think we can or need to require end-user access to the authorization server interface where they can revoke tokens.

it can by achieved [...] by a client that is using authorization server APIs for revocation.

If we want to allow the user to revoke access tokens, it probably should not only be through interaction with the resource server. This is because the user might want to revoke access tokens because the user thinks the access tokens are being abused by the resource server which might compromised/malicious. Or maybe a malicious actor obtained the access from the authorization server and the resource server never had this token and cannot therefore revoke it.

The user should probably have a way to revoke his access grants (maybe all of them) through interaction with the authorization server without going through the resource server. This might be achieved by revoking his credentials ("forgot my password") which could provide an option to revoke the user's grants.

[elarlang]

I think the current 3.5.1 is quite good with (not having) details saying how to achieve it, but just pointing out what must be done.

[elarlang]

The latest proposal:

Verify that refresh tokens and reference access tokens can be revoked by an authorized user. It can be achieved by using the authorization server user interface, or by a client that is using authorization server APIs for revocation.

This is a requirement that involves the client and the authorization server. For revoking the access token it probably should involve also the resource server, as it needs to check the revoke list. My first feeling is that it may make sense to have a separate requirement for access tokens, as this is the most widespread problem - access token is used as a replacement for the session key and those stay alive till token expiration although business logical "user session" is terminated (for example user logs out).

As those 2 requirements going to replace 3.5.1, then remove 3.5.1 with tag split to req1, req2.

[elarlang]

Goes in via #2140

#	Description	L1	L2	L3
51.2.14	[ADDED] Verify that refresh tokens and reference access tokens can be revoked by an authorized user. It can be achieved by using the authorization server user interface, or by a client that is using authorization server APIs for revocation.	✓	✓	✓

[elarlang]

Status: the requirement for refresh token and refresh reference access token is in, we need another requirement for revoking access tokens. This issue here is short enough to keep going here (without opening a new issue).

[TobiasAhnoff]

@elarlang did you mean

Status: the requirement for refresh token and reference access token is in, we need another requirement for revoking access tokens.

Common "self-contained" access tokens that are not reference tokens (like JWTs with an expiration) can´t be revoked, what kind of access tokens where you thinking of?

[elarlang]

Yes, I meant reference tokens and the "revoke" is incorrect term for access tokens.

Should we ask any blocklist of "stolen tokens" or similar, or short-lived access tokens is the solution here?

[randomstuff]

FWIW, the Oauth Status List draft is a "CRL for access token" and might be relevant.

[elarlang]

So, do/can we address access token anyhow at the moment or we are done here?

[TobiasAhnoff]

So, do/can we address access token anyhow at the moment or we are done here?

I think we are done, this was news to me Oauth Status List, but (in my opinion) but a bit early to have in ASVS