there's: https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps that mentions handing OAuth through a backend component in: https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-02#section-6.2 There's an implementation of such a backend in a module for the Apache webserver see: https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-page-applications/
I agree that this model should be documented and spec-ed out but I also believe most people in this WG feel that it is relatively unrelated to OAuth 2.0 beyond what is in 6.2 of the doc above. Hans. On Wed, Dec 18, 2019 at 2:47 AM Evert Pot <m...@evertpot.com> wrote: > At our company we're developing REST apis. > > One of the things that are pretty important to us, is developers being > able to access the REST apis directly, via their browsers.Our systems > typically have a middleware that converts generated hal+JSON to a HTML > interface for easily browsable. > > When using something like Digest or Basic authentication for the API, > this is pretty easy. Browsers present a pop-up, allowing the developer > to log in. > > With OAuth2 this is less easy. Being able to log in via a browser means > that at least an Authorization header needs to be injected. > > Ideally, browsers would just support OAuth2, are able to discover the > the OAuth2 token authorization and possibly use the dynamic client > registration protocol, but alas... we don't live in that world, and I'm > not aware of any browser extension that does this. In fact, I don't > think it's possible today to write a browser extension that intercepts > HTTP requests and adds this header. At least not in Chrome. > > So I'm looking at alternatives. > > One idea we had was to modify the resource service to detect browsers, > send them through the authorization_code flow and set a session cookie. > Initially our idea was to just set the actual access_token in the > cookie. Another idea was to use a JWS token that encrypts both the > access token and refresh token. > > I also don't love the idea for a resource server to support > authentication via cookies. It feels risky, but I can't put my finger on > why exactly. > > My question to this list is, are there any recommendations for this? > It's a shame that many APIs can only be accessed by purpose-built > clients, the nice thing of hypermedia-style APIs is that humans can > actually browse them. > > Evert > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- hans.zandb...@zmartzone.eu ZmartZone IAM - www.zmartzone.eu
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
