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

[Aaron Parecki <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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).
>
> [e-mail] <[e-mail]>  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 <[e-mail]>
> wrote:
>
>> +1, as discussed before
>>
>> Hans.
>>
>> On Mon, Jul 22, 2019, 18:25 Brock Allen <[e-mail]> 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 <[e-mail]
>>> <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
>>> [e-mail] https://www.ietf.org/mailman/listinfo/oauth
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>