+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
