There are two primary aspects of OAuth that are undesirable in this situation:
1) Using a redirect-based OAuth flow to obtain an access token adds unnecessary attack vectors to the application (see all the redirect-based attacks in the Security BCP) 2) Storing the access token somewhere accessible to JavaScript is unnecessary since the JS doesn't need access to it if it can share a cookie domain with the API (RS) These are the main points I am trying to get across in this section, so I've expanded that section to mention these points more explicitly. I've rephrased the whole section, added a reference to potentially using the "SPA with backend" option in the following section, but there is still the lingering case of: If your JavaScript application has no backend, but still shares a domain > with the resource server, then it may be best to avoid using OAuth entirely. Is it worth pursuing this to try to find an OAuth-based solution for this particular architecture? (The app, AS and RS share a common domain, and there is no backend other than the RS.) Something like a cookie-based OAuth flow? ---- Aaron Parecki aaronparecki.com @aaronpk ---- Aaron Parecki aaronparecki.com @aaronpk <http://twitter.com/aaronpk> On Wed, Jul 24, 2019 at 10:19 AM Justin Richer <jric...@mit.edu> wrote: > It would perhaps be better to phrase it as “don’t use OAuth in the > JavaScript application directly” instead of “not entirely”. > > — Justin > > On Jul 23, 2019, at 12:14 AM, Leo Tohill <leotoh...@gmail.com> wrote: > > I didn't see the earlier discussion (do you have a date or title?) so > apologies if I'm bringing up something that's been resolved. But I still > think that it's really confusing to say "it > may be a better decision to avoid using OAuth entirely" if the > application will still be using Oauth/OIDC (which will, of course, involve > a browser flow). > > ors...@lodderstedt.net <tors...@lodderstedt.net> has raised the same (or > similar?) objection in a parallel thread. I suggest we continue the > conversation there. > > - Leo > > > On Mon, Jul 22, 2019 at 1:09 PM Hans Zandbelt <hans.zandb...@zmartzone.eu> > wrote: > >> +1, as discussed before >> >> Hans. >> >> On Mon, Jul 22, 2019, 18:25 Brock Allen <brockal...@gmail.com> wrote: >> >>> I think the implication is that the server-side would use something like >>> OIDC to the token server in order to establish the identity of the user.. >>> The difference is that this would be driven from the server-side piece of >>> the application, as any other normal server-side client would. The result >>> would then simply be a cookie-based authentication session in the client, >>> and any JS code would leverage the http only, same-site cookie for Ajax >>> calls. >>> >>> -Brock >>> >>> On 7/21/2019 10:22:38 PM, Leo Tohill <leotoh...@gmail.com >>> <leotoh...@gmail..com>> wrote: >>> The advice for the architectural pattern "JavaScript served from a >>> common domain as the resource server" reads: >>> >>> "For simple system architectures, such as when the JavaScript >>> application is served >>> from a domain that can share cookies with the domain of the API >>> (resource server), it >>> may be a better decision to avoid using OAuth entirely, and instead use >>> session >>> authentication to communicate directly with the API." >>> >>> I can agree that session authentication could be best here, but how was >>> the user authenticated in order to create the trusted session? Wouldn't >>> that/shouldn't that still use an oauth flow to collect credentials? >>> >>> We need to be clear on the distinction between browser based apps that >>> hold the token(s) in the browser space, vs. those that don't. I agree that >>> with this >>> "common domain" architecture, the tokens should not be held in the >>> browser, but it doesn't follow that oauth should not be used at all. >>> >>> Leo >>> >>> >>> _______________________________________________ OAuth mailing list >>> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
