Add access token requirement for intented scope

[TobiasAhnoff]

Add access token requirement to mitigate the risk of accepting tokens that was not intended to be valid for a particular service (API).

This is part of "cleaning up 3.5" see #1917 (comment)

Verify that the access token is intended for the service (API). For JWTs this can be achieved by validating the claims 'aud' and 'typ'. If audience is present, it must be validated to match against an allow list for the given API. If the typ claim is present, it should be equal to 'at-jwt'.

[elarlang]

If this requirement will be added as general requirement for tokens, we need to recheck OAuth-specific requirement:

V51.4.2 Verify that the resource server validates the access token to be made for that resource server (audience), for example by checking the 'aud' claim from the access token to be an expected value.

[elarlang]

To have an general requirement, we should not limit it to access tokens. It is required to check the aud for other tokens as well, at the moment the proposal seems unnecessary limitation. I think the outcome is part of spliting 3.5.6 to requirements "per task" #1967 (comment).

[elarlang]

Are the title and proposal in conflict? scope vs audience?

[TobiasAhnoff]

Yes, a better title would be "Add requirement to mitigate the risk of accepting tokens that was not intended to be valid for a particular service" and rewrite in a more general way, maybe like this

Verify that the token is intended for the service. For JWTs this can be achieved by validating the claims 'aud' and 'typ'. If audience is present, it must be validated to match against an allow list for the given API. If the typ claim is present and it is an access token, it should be equal to 'at-jwt'.

[elarlang]

I think the typ goes to the "intended usage" field and it is a separate topic than intended audience/service.