Re: [OAUTH-WG] Rich Authorization Requests feedbacks on implementation

[Nicolas Mora]

Hello,

Thank you for your feedback, I'll add some precision then

Le 2021-01-13 à 16 h 51, Justin Richer a écrit :


I think this is an interesting approach, but I’m not sure about a few things:

- What’s the utility of linking to a scope. Why require both structures to be 
interpreted together like that?


Linking a rar to a scope is not mandatory, i.e. if a rar type has no 
scope, then the type will be available for every request and every user.


That said, in Glewlwyd, the access level is the scopes. A user "has" a 
set of scopes which can be granted or not during authorization requests.
Therefore if the client requests scopes and some are not available for 
the user, the grant will be limited to the ones available.


The rar types are another type of access levels, therefore I assume that 
a rar type can be unavailable for a user, so I allow to bind a rar type 
to the scopes for that purpose. But that's a design choice.



- There will absolutely be implementations that do not limit which RAR types 
(or even values) the client is allowed to send, much like there are 
implementations today that don’t restrict scopes on a per-client basis.
- I don’t think that we can say the AS doesn’t verify “extra required 
properties”, since the AS can (and arguably should) know about the details of 
the “type” being used, and enforce internal consistency and structure.



I agree, but the specs doesn't mandate, allow, nor forbid anything about 
the extra properties.
Assuming that, I didn't want the admin to have to use a hardcoded rar 
structure, and because this implementation is a first shot, I didn't 
want to complicate the rar type configuration, which could be dangerous 
to implement.
Other part of the application are very customizable and were painful to 
implement.




It’s always up to the AS to determine what the granted access is, whether it’s 
for a new token, a limitation of existing grant (via refresh token), or a 
client asking for something “additional” for whatever purpose.

I don't allow a client to upgrade the grant access via the refresh 
token, only the same grant access. Therefore to be consistent, the 
client can't change the rar request during a refresh, and the new access 
token will have the same rar content as the one granted during the 
authorization.



Also, in the draft specification, the only mandatory element type in a rar is the 
"type" element. In my point of view, this means that the business logic is 
mostly defined by the RS, rather than the AS.


Just like “scope” in OAuth, it’s ultimately enforced by the RS, but the AS 
works in the process to interpret and potentially modify the meaning of the 
scope.

Yes, if we use a rar reduced only to what's required in the specs, then 
a rar type has no more information than a scope, so the advantage of rar 
lies beyond the mandatory parts of the specs.


But to have a usable rar, the triad client-AS-RS must previously agree 
to use rar types defined outside of the specs.


This is not necessary a disadvantage though.



Therefore, for a client implementation to be compliant with the specs, there's not much 
to do: add as a parameter a JSON array with objects containing at least one 
"type" string property in it.



Yup — and even more, most clients will be sending in static or templated values 
that the developers get from documentation, much like they do with scopes in 
APIs today. Keeping it simple for clients is definitely a goal!


Ack


3 - Extensions

I believe one way to mitigate these limitations is to allow extensions to be 
defined on top of the rar specifications. An extension can be declared like 
this:

"RAR Extension XYZ:
A rar whose type is XXX
- Actions available: YYY, ZZZ or AAA
- datatypes possibles: BBB, CCC, DDD or EEE
- additional elements mandatory: an array of FFF and an object of GGG to represent 
access to some"

Like this, if the AS, the RS and the client agree on using a rar extension, 
they can have at least a detailed pattern on what to expect in the rar type.


I like that structure, but not for “extensions” exactly; more properly, I think 
this can be some guidance on how to create a RAR “type” definition. This fits 
with the philosophy of “type” defining what’s allowed to go in the object, but 
it would allow for a more formal definition of what that connection is. Should 
this be normative, or just informative, though? I’m not sure yet — I will try 
to come up with some proposed text on that and propose a PR.

I used the name extension because the first example I had in mind is the 
extensions and protocols describe in the websocket specs, but I don't 
mind the name that should be used.


Describing the rar types normalization structure is what I think could 
be improved, at least specifying how it should be normalized and for 
what purpose.


/Nicolas


OpenPGP_0xFE82139440BD22B9.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___

Re: [OAUTH-WG] Rich Authorization Requests feedbacks on implementation

[Justin Richer]

Hi Nicolas,

> On Jan 10, 2021, at 8:36 PM, Nicolas Mora 
>  wrote:
> 
> Hello,
> 
> I've implemented Rich Authorization Requests defined in 
> draft-ietf-oauth-rar-03 for Glewlwyd soon-to-be-released 2.5 [1], and I 
> humbly wanted to write my feedback about this implementation to share my 
> experience.
> 

> For starters, this implementation and my following feedbacks are based on the 
> prism of Glewlwyd's implementation and philosophy, and my limited experience 
> on OAuth2, so I appologize in advance if I write non-sense or big mistakes.
> 

Thanks for reaching out! Implementation experience is incredibly valued here in 
the IETF, especially when someone’s coming to the spec from “outside” the 
community. :)

> 1 - Design
> 
> The way I saw it, there are 2 different approaches to implement oauth2 rar: 
> either to get a token with a more detailed scope, or to get a one-time token 
> with extra grants.
> 
> Both are not exclusive, but a big difference I see between those 2 approaches 
> is the grant access from the user part. The second approach would require the 
> user to know what extra grant is asked by the client every time the client 
> asks for it, i.e. when the client redirects the user to the /authorization 
> endpoint.
> 
> To be more consistent with Glewlwyd's philosophy, I chose the first approach, 
> with those rules.
> The AS administrator declares what rar types are allowed [2]
>  - a rar type has a defined set of locations, actions, datatypes and enriched 
> authorization details that the client can ask for
>  - the client must be explicitly allowed to add a rar type in the 
> authorization request
>  - a rar type can be linked to one or more scope. In that case, the 
> authorization request must include at least one of the linked scope, and the 
> scope must be available for the user and the scope must be granted to the 
> client
>  - the client can add as many properties as required in the rar type, those 
> extra properties are not verified by the AS, on access granted, the extra 
> properties will be present in the "authorization_details" result.
> 

I think this is an interesting approach, but I’m not sure about a few things:

- What’s the utility of linking to a scope. Why require both structures to be 
interpreted together like that?
- There will absolutely be implementations that do not limit which RAR types 
(or even values) the client is allowed to send, much like there are 
implementations today that don’t restrict scopes on a per-client basis.
- I don’t think that we can say the AS doesn’t verify “extra required 
properties”, since the AS can (and arguably should) know about the details of 
the “type” being used, and enforce internal consistency and structure.

> On first use of a rar type by a client for a user, the user must grant to the 
> client the rar access [3]. That's why the grant message will show to the user 
> ALL access possible via this rar type
> Once this access is granted or not, the user will not be asked again on 
> another authorization request by the client (but is can be changed at any 
> time, as a scope grant).
> 

It’s always up to the AS to determine what the granted access is, whether it’s 
for a new token, a limitation of existing grant (via refresh token), or a 
client asking for something “additional” for whatever purpose. 

> 2 - Limitations
> 
> In this design, the AS has a limited control over the authorization_details 
> content, and the trust between the AS and the client must be high enough so 
> if a rar type can gain access to sensitive actions or information, the user 
> should know about it.

The AS has full control to interpret the authorization_details content, and 
apply it to access token granting policies, which include whether to ask the 
user to grant anything. 

> 
> Also, in the draft specification, the only mandatory element type in a rar is 
> the "type" element. In my point of view, this means that the business logic 
> is mostly defined by the RS, rather than the AS.

Just like “scope” in OAuth, it’s ultimately enforced by the RS, but the AS 
works in the process to interpret and potentially modify the meaning of the 
scope. 

> 
> Therefore, for a client implementation to be compliant with the specs, 
> there's not much to do: add as a parameter a JSON array with objects 
> containing at least one "type" string property in it.
> 

Yup — and even more, most clients will be sending in static or templated values 
that the developers get from documentation, much like they do with scopes in 
APIs today. Keeping it simple for clients is definitely a goal!

> 3 - Extensions
> 
> I believe one way to mitigate these limitations is to allow extensions to be 
> defined on top of the rar specifications. An extension can be declared like 
> this:
> 
> "RAR Extension XYZ:
> A rar whose type is XXX
> - Actions available: YYY, ZZZ or AAA
> - datatypes possibles: BBB, CCC, DDD or EEE
> - additional elements mandatory: an array of FFF and

Re: [OAUTH-WG] Tenancy in OAuth

[Jaap Francke]

Thanks Justin and Vladimir for your guidance!

The resource indicator approach seems to have the best fit for my use case.
It addresses my coarse/mid-grained use case, without bringing the complexity of 
the fine-grained RAR approach.
Encoding the tenant into scope values remains an option as well.
Ensuring the token validation is implemented properly is indeed a point of 
attention.

Meanwhile I've been looking into OAuth/OIDC specs for client registration. 
It may also be useful to extend the client's metadata with 'resource' to bind 
the specific client to a specific tenant(s).
Would that make sense to you as well?

Great feedback, kind regards, 
Jaap


On 12/01/2021, 23:10, "OAuth on behalf of oauth-requ...@ietf.org" 
 wrote:

Send OAuth mailing list submissions to
oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zNVyuy2avEEWtIJ3eXZGEV9S0KLyYj27KiG2yOPtW9Q%3D&reserved=0
or, via email, send a message with subject or body 'help' to
oauth-requ...@ietf.org

You can reach the person managing the list at
oauth-ow...@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."


Today's Topics:

   1. Re: Tenancy in OAuth (Justin Richer)
   2. Re: Tenancy in OAuth (Vladimir Dzhuvinov)


--

Message: 1
Date: Tue, 12 Jan 2021 16:13:26 -0500
From: Justin Richer 
To: Jaap Francke 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Tenancy in OAuth
Message-ID: 
Content-Type: text/plain; charset="utf-8"

Hi Jaap,

There have been a number of efforts to address this kind of thing in the 
OAuth world. You can definitely use a special scope to encode this value, which 
has the benefit of fitting into the implementation limitations of nearly all 
OAuth systems out there. The ?resource? parameter can also be used for the kind 
of thing, and it gives you a bucket that?s separate from ?scope? so that you 
can keep the latter available for describing the API itself:


https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8707&data=04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5clKn%2B8%2FCEiQindejfHncA670FWVoy%2BHDQ49JtOORjE%3D&reserved=0
 


There?s also the Rich Authorization Request (RAR) draft that this group is 
currently working on, which provides a multi-dimensional way to describe 
access. It?s more complex than scopes, but it boils down to having JSON objects 
describe the elements needed. In this case you might put the API bits into the 
?actions? and ?datatypes? fields, and put the tenant information into the 
?locations? field. I believe there are people using it in exactly this way 
today:


https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-rar-03&data=04%7C01%7Cjaap.francke%40mendix.com%7C93707202bd484789530008d8b746e1f4%7Cb4e3c78d8e3b46d8bc565540da23ba4d%7C0%7C0%7C637460862383168168%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hxn2gFdUhhmWrf0ATaqUUUB9C62yh%2FY27aNOvR1hWbM%3D&reserved=0
 


There are also some historical efforts to address this, including an 
?audience? and a (completely separate) ?aud" parameter, but AFAIK neither of 
these have been raised to standard or even to common practice, and so I 
wouldn?t recommend it. I currently have a project to migrate a system that?s 
currently using one of these onto RAR.

 ? Justin

>