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

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

orsten@lodderstedt.net <torsten@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.zandbelt@zmartzone.eu>
wrote:

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