review V51.4.3

[elarlang]

From the initial OAuth we have requirement:

#	Description	L1	L2	L3
51.4.3	[ADDED] Verify that access tokens are restricted to certain resources and actions on resource servers or resources. Every Resource Server is obliged to verify, for every request, whether the access token sent with that request was meant to be used for that particular action on the particular resource. If not, the resource server must refuse to serve the respective request.	✓	✓	✓

Additionally to some formating improvements, we need to (re)validate the content, the need, the problem to solve and sections.

[TobiasAhnoff]

I suggest to simplify this a bit, like this

Verify that access tokens are restricted to certain resources and actions. Every Resource Server is obliged to verify, for every request, whether the access token sent with that request was meant to be used for that particular action on the particular resource. If not, the Resource Server must deny the request.

Note that this also includes 51.4.4 (see #2182) so a suggestion is to remove that.

Maybe this should rewritten, to not mention the OAuth term Resource Server and be moved from OAuth to V4-Authorization?

Verify that, when access tokens are used, they restricted to certain resources and actions. This means that the server, at the trusted service layer, for every client request, must verify that the access token sent with that request was meant to be used for that particular action on the particular resource. If not, the server must deny the request.

[elarlang]

Related comment: #2181 (comment)

It is not clear what is the unique security problem to solve. This requirement ask to use information from the access token and to be used for authorization decisions correctly.

ping @randomstuff

[randomstuff]

This requirement ask to use information from the access token and to be used for authorization decisions correctly.

Yes. The use case would be to obtain a access token for a (possibly low impact) scope such as "get_profile" from the authorization server and be able to it for a unrelated (and possibly high impact) endpoint such as "/download_private_albums".

Is is already covered somewhere else?

I find 51.4.3 too long and difficult to read (and contrast with 51.4.2), can we simplify it as:

Verify that access tokens are restricted to certain resources and actions and that Resource Servers denies the request if the access token sent with that request is not applicable to that particular action on that particular resource and action.

[TobiasAhnoff]

We could have this, or perhaps?

Verify that access tokens are restricted to certain resources and actions and that Resource Servers denies the request if the access token sent with that request is not valid for authorization to perform the particular action on the resource.

But I think this is covered by 4.1.1 (trusted service layer = resource server), 4.1.3 (function level = action) and 4.2.1 (object level = resource). So perhaps this could be removed?

Or should this be rewritten to more clearly also address fine grained RAR-scenarios, where an access token could be made valid for a single operation, e g "transfer 100 EUR from account A to account B", by validating the authorization_details parameter?

Verify that access tokens are restricted to specific actions on certain resources and that Resource Servers denies the request, if the access token sent with that request is not valid for authorization to perform the particular action on the resource. For example by validating the authorization_details claim.

This would be for L3

[randomstuff]

Can this be simplified as:

Verify that access tokens are restricted to certain resources and actions and that Resource Servers denies the request if the access token sent with that request is not valid for authorizing that particular action on the resource.

So perhaps this could be removed?

Yes, I don't know whether (and under which circumstances, if any) specific requirements about specific topics must be kept when they are already covered about very general requirements.

[elarlang]

Maybe having a strong link and mention in the OAuth chapter (or in the resource server section) text towards the authorization chapter is enough? To say that "Applying the content from access token is covered by requirements on the authorization paragraph"

[TobiasAhnoff]

To reference both V4 and have a requirement for verifying RAR (or other details and specific scope token data) we write this as:

Verify that, if the access token is restricted to specific actions on certain resources, the Resource Servers must deny the request if the access token is not valid for that particular action. For example, when using RAR, by validating the 'authorization_details' claim in addition to other related verifications in V4 and V13.

(if the Access-toen JWT section is moved to V13, see #1917 (comment))

[elarlang]

The intended action here is not denying access token. Also we don't use references to other sections and requirements in a requirement text.

I think we can cover it all by abstract requirement: "Verify that resources server following delegated authorization rules from resources claim when making authorization decisions."

[elarlang]

Round and ping vol n+1:

Verify that when the resource server makes authorization decisions based on access token it follows delegated privileges from related claims such as 'resources' and 'authorization_details'.

ping @TobiasAhnoff @randomstuff

[randomstuff]

from related claims such as 'resources'

There is no resources claim:

• there is a resource OAuth parameter (and an audience one as well);
• and a aud JWT claim.

Shouldn't scope be included here?

[elarlang]

Boah, I took it from the original proposal too literally.

aud is a bit different topic to solve (and it is covered by 51.4.2, update waiting in #2369)

scope can be included into this requirement, but I think it should be abstract enough to cover for example Keycloak realm_access, groups or whatever is used. The point is - those limitation must take into account. How it is enforced, is already V4 area.

update: ... but if there nothing OAuth specific anymore, we can just add this requirement to V4 as well. Just an option, not yet a recommendation, or looping back, maybe proposal in #2183 (comment) is enogh.

[randomstuff]

aud is a bit different topic to solve (and it is covered by 51.4.2, update waiting in #2369)

aud can specify a resource server but can as well specify a specific resource on the resource server (the two concepts are somewhat interchangeable in the OAuth specifications). Do we need to include this as well for this reason?

update: ... but if there nothing OAuth specific anymore, we can just add this requirement to V4 as well. Just an option, not yet a recommendation, or looping back, maybe proposal in #2183 (comment) is enogh.

Yes, it would probably be good.

Would it make sense to include some notes in the OAuth chapter hinting that some (important) subsections in other chapters are applicable? Something such as:

Note: for the processing of access token by resource servers, see as well the requirements in VX.Y.

[elarlang]

aud is a bit different topic to solve (and it is covered by 51.4.2, update waiting in #2369)

aud can specify a resource server but can as well specify a specific resource on the resource server (the two concepts are somewhat interchangeable in the OAuth specifications). Do we need to include this as well for this reason?

update: ... but if there nothing OAuth specific anymore, we can just add this requirement to V4 as well. Just an option, not yet a recommendation, or looping back, maybe proposal in #2183 (comment) is enogh.

Yes, it would probably be good.

My idea was just to highlight, that:

• access token is (just) an access delegation
• the information must be used for authorization decisions

But by nature it is covered by requirements in the authorization paragraph. So if we don't want to "duplicate it", we can just rely on the requirements in V4 and "hint" in the chapter text.

Would it make sense to include some notes in the OAuth chapter hinting that some (important) subsections in other chapters are applicable? Something such as:

Note: for the processing of access token by resource servers, see as well the requirements in VX.Y.

yes, #2183 (comment)

[elarlang]

So, to confirm and point out the expected actions:

• we remove current current requirement 51.4.3
• we add section text for OAuth Resource Server with the meaning (not a wording proposal):
  • Resource server is responsible to enforce access control decisions based on delegated accesses in the access token, for that, authorization requirements apply and that are not duplicated here.
  • We can also add the line for general token validation - although we have line or two about that in V51 chapter text
• we mention somehow delegated access rules in related section text in V4.1

[TobiasAhnoff]

I think it is good to point to e g V4.1 and only have OAuth specific things here. I´m not sure, but it think it might make sense to mention scope at some point and perhaps have something like this in a section text for 51.4

Resource server is responsible to enforce access control decisions based on delegated accesses in the access token, for that, authorization requirements apply and that are not duplicated here. If there are token properties that are part of user consent, e g 'scope', they shall be part of the decision.

[tghosth]

@TobiasAhnoff @randomstuff can we get proposed wording/changes here?

[randomstuff]

The nuance that you want to convey here is tricky get through …

What we want to say is (not a wording proposition): even if the resource server has received an access token for action X by user Y, it (usually) still need to check that user Y is allowed to do action X because the authorization server is (typically) not responsible for making this verification.

i.e. the access token represents the fact that the user has consented to allow the client to act on the user's behalf for this action (authorization delegation) but (usually) does not represent the fact that the user is allowed to do the action (authorization decision).

Question: is it "usually"? Is it legitimate to have an architecture where the AS is responsible for authorization decision? To formulate it another way: is it legit to have access tokens which represent an authorization decision (where the resource server would not have a need, or would not have a way to take this decision)?

I think we would have to find a more explicit formulation about this because it will be easy to read the wording the wrong way.

[TobiasAhnoff]

We could leave scope out, it is included in "enforce access control decisions based on delegated accesses in the access token", but at the same time, since 51.4.2 mentions 'aud' and 51.4.4 mentions 'sub', it feels somewhat incomplete not to mention 'scope' in this section in some way...perhaps this is better?

Resource server is responsible to enforce access control decisions based on delegated accesses in the access token, for that, authorization requirements apply and that are not duplicated here. When using OAuth, granted scopes would typically be part of this decision, e g for function level access control.

Or we can just have

Resource server is responsible to enforce access control decisions based on delegated accesses in the access token, for that, authorization requirements apply and that are not duplicated here.

[tghosth]

So is there a requirement change here as well?

If so, @randomstuff @TobiasAhnoff can you provide a suggestion?

If not, @randomstuff what do you think of Tobias's suggestion? #2183 (comment)

Never mind, Elar answered me, see my more accurate comment below: #2183 (comment)

[elarlang]

So is there a requirement change here as well?

Latest proposal is still valid I think: #2183 (comment)

[tghosth]

Ok so all we need is to delete 51.4.3 and then we need proposed section text for V51 and for V4.1.

@randomstuff @TobiasAhnoff do you have proposed text for V4.1

@randomstuff what do you think of Tobias's suggestion for V51? #2183 (comment)

[elarlang]

Lets decide this after some call or discussion, there are many ways how to handle it.

[tghosth]

Lets decide this after some call or discussion, there are many ways how to handle it.

You want to arrange a call with @TobiasAhnoff and @randomstuff ?

[elarlang]

We are going to update requirement V51.4.3 with the idea to list and highlight claims from access token that should be taken into account during authorization enforcement / decisions. Also mention custom claims.

Something like:

Verify that information from access token is used for enforcing access control decisions. For example, list of claims.

Related sections texts we going to handle separately.

[tghosth]

@elarlang who is taking this on? @TobiasAhnoff? @randomstuff?

[TobiasAhnoff]

@tghosth I will do a draft for chapter texts (in google doc), and V51.4.3 we will continue to work on here.

[TobiasAhnoff]

How about this?

Verify that access control decisions are based on delegated accesses in the access token. For example granted scopes and, if using RAR, 'authorization_details' should be part of the decision.

[randomstuff]

delegated accesses in the access token

I find that "delegated access" is not very clear/explicit. I'm struggling to find a better correct formulation however.

Some draft wording:

Verify than the authorizations granted at the resource server by the usage of the access token are restricted by the authorizations associated with the access token. For example, the 'scope' or 'authorization_details' claims of the access token should be part of the (delegated?) access control decision. In general, the resource server should still use the resource owner identity, roles or entitlements for access control decision.

[elarlang]

By content the requirement in a way duplicates V4 requirements and the main point I want to see this requirement as a separate requirement is to send the message "AS delegates the authorization ruleset and RS need to enforce it".

The rest of it should be list of possible claims what can be used for authorization decisions on the RS side.

In general, the resource server should still use the resource owner identity, roles or entitlements for access control decision.

should vs must

Do we want special highlight for this for some reason? I think it is covered by 4.2.5

V4.2.5 Verify that access to an object is based on the originating subject's (e.g. consumer's) permissions, not on the permissions of any intermediary or service acting on their behalf. For example, if a consumer calls a web service using a signed token for authentication, and the service then requests data from a different service, the second service should use the consumer's signed token, rather than a machine-to-machine token from the first service, to make permission decisions.

[elarlang]

A bit different proposal:

Verify that the resource server enforces authorization decisions based on delegated permissions and other related claims from the access token. For example, such claims are 'authorization_details' if rich authorization requests (RAR) is used, 'sub', 'scope', and claims that define delegated permissions or roles.

ping @TobiasAhnoff @randomstuff

[TobiasAhnoff]

Yet another suggestion (I think the examples makes it clear what kind of claims we are talking about and good to have RAR last since the main claims to use are scope and sub)

Verify that the resource server enforces authorization decisions based on claims from the access token that define the delegated authorization. For example, such claims are 'sub', 'scope', and, if rich authorization requests (RAR) is used, 'authorization_details' must be part of the decision.

or

Verify that the resource server enforces authorization decisions based on authorization related claims from the access token. Such claims are 'sub', 'scope', and, if rich authorization requests (RAR) is used, 'authorization_details' must be part of the decision.

[elarlang]

• I think we can skip " if rich authorization requests (RAR) is used" part - if the claim exists, it must be taken into account
• "Such claims are /list/ must be part of the decision" - first and last part does not match well

[TobiasAhnoff]

How about this?

Verify that the resource server enforces authorization decisions based on authorization related claims from the access token. If present, claims such as 'sub', 'scope', and 'authorization_details' should be part of the decision.

[elarlang]

Almost there

• should vs must
• from my previous proposal - and claims that define delegated permissions or roles. - why not to add this?

[TobiasAhnoff]

should vs must

In a way I would prefer "must", but authorization is hard! Just because sub or scope is present in the token doesn't mean that all resource servers must use them for authorization decisions in order to provide secure access to resources, the permission model is application specific and it might instead be based on just custom claims like 'role' or clientId etc. So that is why "should" was kept...

from my previous proposal - and claims that define delegated permissions or roles. - why not to add this?

Given previous comment #2183 (comment) on "delegated access" I just wanted to try something without delegation (and make it as short as possible), and also 'roles' might not be relevant for all applications. But, if delegation is ok, then this would also work (replaced "permissions and roles" with "authorization", better?)

Verify that the resource server enforces authorization decisions based on claims from the access token that define delegated authorization. If present, claims such as 'sub', 'scope', and 'authorization_details' should be part of the decision.