> On Dec 3, 2018, at 1:25 AM, Torsten Lodderstedt <tors...@lodderstedt.net> > wrote: > > I think the BCP needs to point out there are solutions beyond an app directly > interacting with AS and RSs from the browser. Otherwise people get the wrong > impression this is the only way to go. To the contrary and as I pointed out, > there are a lot of SPAs working as UI of a larger application.
My feeling is different - these applications all _could_ be expressed/implemented in terms of OAuth 2/OpenID Connect. Instead of authorization being done via opaque access tokens, the non-OAuth application has authorization tracked via opaque cookies. I think we can state this, and that many of the rules given could be used > > Any multi user app needs a database. Will this database be directly exposed > to the frontend? I don’t think so. There will be a backend, exposing relevant > capabilities to the SPA. Sure, but this doesn’t change the interface being exposed around the database as being a protected resource - just one protected by a token acquired via a different non-OAuth manner > And if this app also uses external services, where do you want to store the > respective refresh tokens? In the browser’s local storage? I don’t believe > so. They will go into the same backend & database. > And there are other reasons: No one will ever be able to implement a PSD2 TPP > as a stand-alone SPA, obviously because it requires a confidential client but > there are more aspects. You could have your AS also be responsible for fetching/maintaining remote tokens, and issue local environment tokens. It could expose either local protected resources which use these remote resources, or provide a reverse proxy that translates the calls directly, including applying the remote access token. This also looks very similar whether you are talking about the javascript being OAuth or using a proprietary cookie-based system. > Moreover, some security objectives can only be achieved if a backend is used. > That’s how the discussion started (token binding and the like). Cookies have browser-level support, so they can have browser-level protections asked for (SameSite, HttpOnly, Secure, separate path/domain limiting). IMHO, the other differences are apples-to-oranges comparing different protected resources, not access-vs-other-tokens. Is there value in defining “official” recommendations around access tokens within cookies? > IMHO omitting this option significantly reduces the relevance of the BCP. > I’m not saying we shall describe the interaction between frontend and backend > in detail. I advocate for pointing out this option and its benefits. That’s > it. Again, I think a significant portion of recommendations would have value for non-oauth-client javascript. But I think we should focus on defining solely in terms of OAuth clients. I agree we should point out the option in the sense that it will help people understand that it doesn’t significantly affect the security requirements. The rest seem points around protected resources and cases for a local AS to house business logic. A lot of the above might be recommendations around protected resources and multi-level authorization (for example: having clients interact with a local environment which may behind-the-scenes be using OAuth itself with remote services). I’m unsure how you would rein in scope on something like this, though. -DW _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
