V51 OAuth: Add resource server verifications (modify 51.4.1)

[TobiasAhnoff]

It is suggested to modify 51.3.1 and split in two verifications, one for all levels and one for L3 only, since sender-constrained access tokens are only a requirement in security profiles like FAPI and it is uncommon for L2 application to implement this.

V51.4 Resource Server

Verify that if that if the client sends an sender-constrained access token, using Mutual TLS for OAuth 2 or OAuth 2 DPoP, then the Resource Server must verify accordingly (proof-of-possession). (L1, L2, L3)

Verify that all Resource Servers requests requires sender-constrained access token validation using Mutual TLS for OAuth 2 or OAuth 2 DPoP. (L3)

[elarlang]

What is the security risk to solve or attack to take down with those requirements? By current wording, those are resource server functionality testing.

[TobiasAhnoff]

The sender-constrained access tokens mitigates the risk with "token theft", where an attacker is able to get a valid token, perhaps from logs or leaked in some way to other services (where the attacker have access), see e g https://www.rfc-editor.org/rfc/rfc8705.html#name-introduction

Binding an access token to the client's certificate prevents the use of stolen access tokens or replay of access tokens by unauthorized parties.

Maybe it is better to use that, something like this, perhaps a bit long?

Verify that the Resource Server prevents the use of stolen access tokens or replay of access tokens (from unauthorized parties) by requiring sender-constrained access tokens, given that client resource requests are made using either Mutual TLS for OAuth 2 or OAuth 2 DPoP. Note that for L3 sender-constrained tokens should be required, while L1 and L2 can support only Bearer tokens.

[elarlang]

It covers both initially proposed requirements?

I think the last "Note" part is not necessary, if the requirement is made for "Level 3", it gives that meaning anyway.

[TobiasAhnoff]

Yes, this could be for L3 only, then it could be written as:

Verify that the Resource Server prevents the use of stolen access tokens or replay of access tokens (from unauthorized parties) by requiring sender-constrained access tokens, either Mutual TLS for OAuth 2 or OAuth 2 DPoP.

[elarlang]

Currently, we have 51.4.1 as a Level 1 requirement.

V51.4.1 Verify that resource servers implement sender-constrained access token mechanisms to mitigate token replay risks. This is achieved by mandating Mutual TLS for OAuth 2.0 or OAuth Demonstration of Proof of Possession (DPoP), using the client secret provided at client registration.

The initial proposal was to split it, but the latest proposal is to replace it with one level 3 requirement:

Verify that the Resource Server prevents the use of stolen access tokens or replay of access tokens (from unauthorized parties) by requiring sender-constrained access tokens, either Mutual TLS for OAuth 2 or OAuth 2 DPoP.

@TobiasAhnoff - do I understand it correctly?

ping @randomstuff for opinions and feedback

[TobiasAhnoff]

do I understand it correctly?

Yes!

[elarlang]

Is is updated now via #2135

#	Description	L1	L2	L3
51.4.1	[ADDED] Verify that the resource server prevents the use of stolen access tokens or replay of access tokens (from unauthorized parties) by requiring sender-constrained access tokens, either Mutual TLS for OAuth 2 or OAuth 2 Demonstration of Proof of Possession (DPoP).			✓