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.