> On Sep 28, 2018, at 9:10 PM, Evert Pot <m...@evertpot.com> 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
