You send not mail please Loose mail only Please send not mail 2021년 1월 12일 (화) 오전 5:02, <[email protected]>님이 작성:
> Send OAuth mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > > Today's Topics: > > 1. Rich Authorization Requests feedbacks on implementation > (Nicolas Mora) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 10 Jan 2021 20:36:36 -0500 > From: Nicolas Mora <[email protected]> > To: oauth <[email protected]> > Subject: [OAUTH-WG] Rich Authorization Requests feedbacks on > implementation > Message-ID: <[email protected]> > Content-Type: text/plain; charset=utf-8; format=flowed > > 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 > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 147, Issue 3 > ************************************* >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
