MIME-Version: 1.0
From: Leo Tohill <leotohill@gmail.com>
Date: Sun, 21 Jul 2019 22:22:16 -0400
Message-ID: <CABw+Fcuv2banmDtqC_6A4j6Vw7OgTLEDFOf0mn4YSeMaNkUsrA@mail.gmail.com>
To: OAuth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002bd7f5058e3bbfab"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/-VQ1ktgNLVphS2BrOnUPm0e2NeI>
Subject: [OAUTH-WG] not using oauth for this architecture in oauth for
 browser based apps.
Precedence: list

--0000000000002bd7f5058e3bbfab
Content-Type: text/plain; charset="UTF-8"

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

--0000000000002bd7f5058e3bbfab
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>The advice for the architectural pattern &quot;JavaSc=
ript served from a common domain as the resource server&quot;=C2=A0 reads:<=
br></div><div><br></div><div>&quot;For simple system architectures, such as=
 when the JavaScript application is served<br>from a domain that can share =
cookies with the domain of the API (resource server), it<br>may be a better=
 decision to avoid using OAuth entirely, and instead use session<br>authent=
ication to communicate directly with the API.&quot;</div><div><br></div><di=
v>I can agree that session authentication could be best here, but how was t=
he user authenticated in order to create the trusted session?=C2=A0 Wouldn&=
#39;t that/shouldn&#39;t that still use an oauth flow to collect credential=
s?</div><div><br></div><div>We need to be clear on the distinction between =
browser based apps that hold the token(s) in the browser space, vs. those t=
hat don&#39;t.=C2=A0 I agree that with this <br>&quot;common domain&quot; a=
rchitecture, the tokens should not be held in the browser, but it doesn&#39=
;t follow that oauth should not be used at all. <br></div><div><br></div><d=
iv>Leo<br></div><div><br></div><div><br></div></div>

--0000000000002bd7f5058e3bbfab--