Re: [OAUTH-WG] not using oauth for this architecture in oauth for browser based apps.

+1, as discussed before

Hans.

On Mon, Jul 22, 2019, 18:25 Brock Allen <brockallen@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 <leotohill@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
>