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

[David Waite <[e-mail]>]

> On Sep 28, 2018, at 9:10 PM, Evert Pot <[e-mail]> wrote:
> 
<parts answered by Brian>
> 
> 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