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.
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.
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).
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.
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.
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.
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.
Any thoughts?
/Nicolas
[1] https://github.com/babelouest/glewlwyd
[2]
https://raw.githubusercontent.com/babelouest/glewlwyd/master/docs/screenshots/plugin-oidc-rar.png
[3]
https://raw.githubusercontent.com/babelouest/glewlwyd/master/docs/screenshots/login-rar-grant.png
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
