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> 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
