Re: [OAUTH-WG] draft-hardt-oauth-distributed suggestions

[Brian Campbell]

Nearly a month later (sorry) replies to some of the comments/questions are
inline below.

On Fri, Sep 28, 2018 at 9:11 PM Evert Pot  wrote:

> I read the Distributed OAuth draft, and I have a few comments and
> questions:
>
> The draft defines 2 new link relations. "resource_uri" and
> "oauth_server_metadata_uri". However, the underscore is actually
> invalid[1].
>

Well that's definitely a problem that needs to be fixed. Doh. Thanks for
pointing that out!



> On the IANA Links Relations registry[2], most existing link relations
> use dashes, or occasionally camel-case as a separator. I would suggest
> using dashes. I also don't think that the _uri postfix is needed, as the
> implication of any link is that it points to a uri.
>
> A second question I have is related to the resource_uri. The way I
> expect this specification to be used, is that a client will attempt to
> access a resource. When accessing it will be met with a 401
> Unauthenticated along with meta-data that will help the client
> authenticate.
>
> To me the implication of this is that the resource_uri is the uri that
> the client tried to access. A more appropriate existing link relation
> might therefore be the 'self'. However, why would a resource server ever
> need to communicate what it's own url is? The explanation I can think of
> is that this is a mechanism for a resource to suggest a different
> resource to authenticate for.
>
> I'm curious what the use-case for this is. Regardless, I feel that the
> "resource_uri" name is going to be rejected on the basis that 'Resource
> Uri' is a generic concept on the web, but this draft assigns a very
> specific oauth2 meaning to it.
>

The idea or use-case behind the "resource_uri" link relation (and this
likely needs to be explained better in the document and clearly the name
needs to change) is that it is likely to be a more general URI than the
specific request was made to. Like a base URL for the whole application,
API, or set of protected resources. So, for example, both a request to
https://api.example.com/someapp/stuff/abc123 and
https://api.example.com/someapp/stuff/xyz789 might get a 401 with
resource_uri link relation value of ;. Or
a requests to https://resources.example.com/some/deeper/path/here and
https://resources.example.com/things might both get a 401 with resource_uri
link relation value of ;. So 'self' isn't
quite right for it.



>
> I also have a question:
>
> One thing I've missed from using OAuth2-powered services over HTTP Basic
> / Digest, is the ability for a browser to handle login. The idea that a
> browser can potentially do all the steps required, means that a user
> could potentially hit a resource server directly and browse it
> interactively without requiring a non-browser client. I think this
> concept is really powerful, and Distributed OAuth is a good step in that
> direction.
>
> The piece that's missing though is that using the current OAuth2
> framework, a generic client would still need to have a client_id.
>
> I don't fully understand the security implications of this, but could
> this specification potentially be expanded so that the WWW-Autenticate
> challenge can optionally also include a client_id?
>
> The way I see this work is that a browser could grab it and attempt
> using it with the implicit flow.
>
> I did some experimentation with this, and I believe that this feature
> could actually be built as a web extension, but it will only work in
> Firefox as Chrome does not give web extensions access to the
> Authorization header.
>
> If there is interest in this idea, I'm happy to help edit the current
> draft.
>
>
I do suspect there'd need to be a serious look at the security implications
of something like that. And my sense is that it is beyond the scope of the
distributed oauth document.



Evert
>
> [1]: https://tools.ietf.org/html/rfc8288#section-3.3
> [2]: https://www.iana.org/assignments/link-relations/link-relations.xhtml
> [3]:
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-hardt-oauth-distributed suggestions

[David Waite]

> On Sep 28, 2018, at 9:10 PM, Evert Pot  wrote:
> 

> 
> One thing I've missed from using OAuth2-powered services over HTTP Basic
> / Digest, is the ability for a browser to handle login. The idea that a
> browser can potentially do all the steps required, means that a user
> could potentially hit a resource server directly and browse it
> interactively without requiring a non-browser client. I think this
> concept is really powerful, and Distributed OAuth is a good step in that
> direction.
> 
> The piece that's missing though is that using the current OAuth2
> framework, a generic client would still need to have a client_id.
> 
> I don't fully understand the security implications of this, but could
> this specification potentially be expanded so that the WWW-Autenticate
> challenge can optionally also include a client_id?

I assume this is the WWW-Authenticate Bearer challenge at the resource.

I lean toward reducing the coupling between the resources and the AS to 
understanding the access token - how to directly verify it or introspect it, 
the meaning of data contained within such as scopes, and so on. This sort of 
dynamic specification expands that to needing to state the issuer (hopefully 
not raw metadata url) of the issuers it wishes to receive authorization from - 
a pretty minimal (and logical) expansion on the requirements of the resource 
server for what is being attempted.

Having the resource server also maintain metadata on how anonymous clients 
should work seems like an unnecessary expansion on resource server 
responsibilities. I would say instead:
- Expand Dynamic Client Registration (7591) as necessary to meet new 
requirements.
- Give an anonymous client identifier as part of the AS server metadata (8414)

Having a unique client identifier (or token) per browser may help with managing 
security constraints the AS may want to place on anonymous clients, such as SSO 
or persistent consent.

> The way I see this work is that a browser could grab it and attempt
> using it with the implicit flow.

For a built-in browser support (especially for a static client_id) it isn’t 
clear what a recommendation for the redirect uri would be. Reducing the 
requirements placed upon a resource server, I’d prefer this not be a ‘dummy 
resource’ for the browser to consume rather than routing through.

> I did some experimentation with this, and I believe that this feature
> could actually be built as a web extension, but it will only work in
> Firefox as Chrome does not give web extensions access to the
> Authorization header.

The other approach I’ve played with for this is using service workers, although 
I haven’t gotten far enough to figure out the UX for user authentication and 
consent. Is there any feasibility to having an extension inject a service 
worker? I suppose this could conflict with CSP.

-DW___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth