Re: [OAUTH-WG] updated Distributed OAuth ID

[David Waite <[e-mail]>]

> On Jul 20, 2018, at 2:33 AM, n-sakimura <[e-mail]> wrote:
> 
> I did not quite follow why CORS is relevant here. We are just talking about the client to server communication, and there are no embedded resources in the response. Could you kindly elaborate a little, please? 

Sure!  It is effectively an additional (complex) restriction on implementation/capabilities of CORS and the design of the resources.

There are five possible access results for a resource that come to mind:
1. Client does not have authorization but gets a (possibly limited) entity response
2. Client does not have authorization and is challenged
3. Client has authorization and gets a (possibly customized) entity response
4. Client has insufficient authorization and is challenged (e.g. for a new access token, possibly with more scopes)
5. Client has insufficient authorization and is refused access

The CORS policies returned for 1 and 3 may be different than 2 and 4, may be different for 5, and may come from different infrastructure (such as an authenticating reverse proxy “gateway”). Note also that cases 1 and 3 may have a WWW-Authenticate header on the response, indicating that providing authorization may return a different entity response.

One way to handle remote access for all of these cases with commonality would be to expose the WWW-Authenticate header via the CORS policy.

With the Link header used as well, you would need to also expose the Link header in all of these cases (or at least 1-4). However, the Link header can return many relations beyond this one authorization use case, and you would be exposing those all-or-nothing. 

You effectively lose the ability to regulate visibility of the Link header via CORS, and must resort to selective disclosure of headers as your mechanism of control (or serialize those links in another way such as within the content body, when an available option)

-DW

>  
> For the second point, since it was discussed in the WG meeting yesterday, I will defer to that discussion.
>  
> Best, 
>  
> Nat Sakimura
>  
>  
> From: OAuth [mailto:[e-mail]] On Behalf Of David Waite
> Sent: Thursday, July 19, 2018 4:55 PM
> To: Dick Hardt <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [OAUTH-WG] updated Distributed OAuth ID
>  
> Four comments.
>  
> First: What is the rationale for including the parameters as Link headers rather than part of the WWW-Authenticate challenge, e.g.:
>  
> WWW-Authenticate: Bearer realm="example_realm",
>                              scope="example_scope",
>                              error=“invalid_token",
>     resource_uri="https://api.example.com/resource <https://api.example.com/resource>",
>     oauth_server_metadata_uris="https://as.example.com/.well-known/oauth-authorization-server <https://as.example.com/.well-known/oauth-authorization-server> https://different-as.example.com/.well-known/oauth-authorization-server <https://different-as.example.com/.well-known/oauth-authorization-server>"
>  
> 
> My understanding is that the RFC6750 auth-params are extensible (but not currently part of any managed registry.)
>  
> One reason to go with this vs Link headers is CORS policy - exposing Link headers to a remote client must be done all or nothing as part of the CORS policy, and can’t be limited by the kind of link.
>  
> Second: (retaining link format) Is there a reason the metadata location is specified the way it is? It seems like
>  
> <https://as.example.com/.well-known/oauth-authorization-server <https://as.example.com/.well-known/oauth-authorization-server>>; rel=“oauth_server_metadata_uri"
>  
> should be
>  
> <https://as.example.com <https://as.example.com/>>; rel=“oauth_issuer"
>  
> OAuth defines the location of metadata under the .well-known endpoint as a MUST. An extension of OAuth may choose from at least three different methods for handling extensions beyond this:
> 1. Add additional keys to the oauth-authorization-server metadata
> 2. Add additional resources to .well-known for clients to supporting their extensions to attempt to resolve, treating ‘regular’ OAuth as a fallback.
> 3. Define their own parameter, such as rel=“specialauth_issuer”, potentially using a different mechanism for specifying metadata
>  
> Given all this, it seems appropriate to only support specifying of metadata-supplying issuers, not metadata uris.
>  
> Third: I have doubts of the usefulness of resource_uri in parallel to both the client requested URI and the Authorization “realm” parameter.
>  
> As currently defined, the client would be the one enforcing (or possibly ignoring) static policy around resource URIs - that a resource URI is arbitrary except in that it must match the host (and scheme/port?) of the requested URI. The information on the requested URI by the client is not shared between the client and AS for it to do its own policy verification. It would seem better to send the client origin to the AS for it to do (potential) policy verification, rather than relying on clients to implement it for them based on static spec policy.
>  
> The name “resource URI” is also confusing, as I would expect it to be the URI that was requested by the client. The purpose of this parameter is a bit confusing, as it is only defined as “An OAuth 2.0 Resource Endpoint specified in [RFC6750] section 3.2 - where the term doesn’t appear in 6750 and there does not appear to be a section 3.2 ;-)
>  
> It seems that:
> a. If the resource_uri is a direct match for the URI requested for the client, it is redundant and should be dropped
>     (If the resource URI is *not* a direct match with the URI of the resource requested by the client, it might need a better name).
> b. If the resource URI is meant to provide a certain arbitrary grouping for applying tokens within the origin of the resource server, what is its value over the preexisting “ realm” parameter?
> c. If the resource URI is meant to provide a way for an AS to allow resources to be independent, identified entities on a single origin - I’m unsure how a client would understand it is meant to treat these resource URIs as independent entities (e.g. be sure not to send bearer tokens minted for resource /entity1 to /entity2, or for that matter prevent /entity1 from requesting tokens for /entity2).
>  
> Admittedly based on not fully understanding the purpose of this parameter, it seems to me there exists a simpler flow which better leverages the existing Authentication mechanism of HTTP. 
>  
> A request would fail due to an invalid or missing token for the realm at the origin, and and the client would make a request to the issuer including the origin of the requested resource as a parameter. Any other included parameters specified by the WWW-Authenticate challenge understood by the client (such as “scope”) would also be applied to this request.
>  
> Normal authorization grant flow would then happen (as this is the only grant type supported by RFC6750). Once the access token is acquired by the client, the client associates that token with the “realm” parameter given in the initial challenge by the resource server origin. Likewise, the ‘aud’ of the token as returned by a token introspection process would be the origin of the resource server.
>  
> It seems any more complicated protected resource groupings on a resource server would need a client to understand the structure of the resource server, and thus fetch some sort of resource server metadata.
>  
> Fourth and finally: Is the intention to eventually recommend token binding here? Token binding as a requirement across clients, resources, and the authorization servers would isolate tokens to only being consumed within an origin. This would actually make redundant/supplemental the AS additions defined within this spec (resource/origin request parameter, ‘aud’ introspection response member)
>  
> -DW
> 
> 
> On Jun 12, 2018, at 1:28 PM, Dick Hardt <[e-mail] <mailto:[e-mail]>> wrote:
>  
> Hey OAuth WG
>  
> I have worked with Nat and Brian to merge our concepts and those are captured in the updated draft.
>  
> https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/ <https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/>
>  
> We are hopeful the WG will adopt this draft as a WG document.
>  
> Any comments and feedback are welcome!
>  
> /Dick
> _______________________________________________
> OAuth mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>