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

From: Leo Tohill <[email-masked]>
Date: Sun, 21 Jul 2019 22:22:16 -0400

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

---

From: "Brock Allen" <[email-masked]>
Date: Mon, 22 Jul 2019 12:25:32 -0400

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 <[email-masked]> 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 [email-masked] https://www.ietf.org/mailman/listinfo/oauth

---

From: Hans Zandbelt <[email-masked]>
Date: Mon, 22 Jul 2019 19:08:52 +0200

+1, as discussed before

Hans.

On Mon, Jul 22, 2019, 18:25 Brock Allen <[email-masked]> 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
>
> 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
> 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
> [email-masked] https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Leo Tohill <[email-masked]>
Date: Tue, 23 Jul 2019 00:14:35 -0400

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

[email-masked] <[email-masked]>  has raised the same (or
similar?) objection in a parallel thread.  I suggest we continue the
conversation there.

- Leo

---

From: Justin Richer <[email-masked]>
Date: Wed, 24 Jul 2019 14:18:53 +0000

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 <[email-masked]<mailto:[email-masked]>> 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).

[email-masked]<mailto:[email-masked]>  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 <[email-masked]<mailto:[email-masked]>> wrote:
+1, as discussed before

Hans.

On Mon, Jul 22, 2019, 18:25 Brock Allen <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:leotohill@gmail..com>> wrote:

Leo

_______________________________________________ OAuth mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Aaron Parecki <[email-masked]>
Date: Wed, 24 Jul 2019 17:43:00 -0400

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 <[email-masked]> 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 <[email-masked]> wrote:
>
> 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).
>
>>> On 7/21/2019 10:22:38 PM, Leo Tohill <[email-masked]
>>> <leotohill@gmail..com>> wrote:
>>> The advice for the architectural pattern "JavaScript served from a
>>> common domain as the resource server"  reads:
>>>