Subject: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

From: Aaron Parecki <[email-masked]>
Date: Mon, 8 Jul 2019 16:03:10 -0700

Hi all,

I've just uploaded a new version of oauth-browser-based-apps in preparation
for the meeting in Montreal.

https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-02

This draft incorporates much of the feedback I've received over the last
couple months, as well as what we discussed at the last meeting in Prague.

The primary change is a significant rewrite and addition of Section 6 to
highlight the two common deployment patterns, a SPA with and without a
dynamic backend.

Please have a look and let me know what you think. I have a slot in the
agenda for Montreal to present on this as well.

Thanks!

----
Aaron Parecki
aaronparecki.com

---

From: Leo Tohill <[email-masked]>
Date: Mon, 8 Jul 2019 20:44:31 -0400

regarding 6.1. Apps Served from a Common Domain as the Resource Server

Isn't this recommendation neglecting some benefits  or use cases of Oauth?

* An application that doesn't collect user credentials is an app that
doesn't need to be audited for problems such as password leakage into log
files.
* Applications that offload authentication to a identity server can
delegate to that server the complexities of MFA, password recovery,and the
like.  Of course these CAN be done in the app, but isn't it sometimes
better to centralize those features in a identity server?  Especially if
the organization has multiple apps that require these features.

I would soften " it is likely a better decision"  to "it may be a better
decision".

Leo

On Mon, Jul 8, 2019 at 7:05 PM Aaron Parecki <[email-masked]> wrote:

> Hi all,
>
> I've just uploaded a new version of oauth-browser-based-apps in
> preparation for the meeting in Montreal.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Leo Tohill <[email-masked]>
Date: Mon, 8 Jul 2019 21:08:53 -0400

(should I start a new thread instead of making multiple replies to this
message?)

Re: Sec
Typo/grammar in:
"First- party apps are applications where by the same organization that
provides the API being accessed by the application."

Suggested rewrite:
"First- party apps are applications where the same organization provides
both the api and the application."

---

From: Leo Tohill <[email-masked]>
Date: Mon, 8 Jul 2019 21:12:48 -0400

I see now that my arguments for softening the 6.1 language are backed and
expanded on by the last paragraph of section 5, starting with " By
redirecting to the authorization server,..."

---

From: Janak Amarasena <[email-masked]>
Date: Wed, 10 Jul 2019 01:37:56 +0530

Hi,

A few rewording suggestions;

*section-6.2*
Original:
The Application Server SHOULD use the OAuth 2.0 authorization code grant to
initiate a request *request *for an access token...

Suggestion:
The Application Server SHOULD use the OAuth 2.0 authorization code grant to
initiate a request for an access token.

*section-7*
Original:
Public browser-based apps needing user authorization create an
authorization request URI with the authorization code grant type per
Section 4.1 of OAuth 2.0 [RFC6749], using a redirect URI capable of being
received by the app.

Suggestion:
Public browser-based apps needing user authorization *should *create an
authorization request URI with the authorization code grant type *as *per
Section 4.1 of OAuth 2.0 [RFC6749], using a redirect URI capable of being
received by the app.

*section-8*
Original:
... can potentially continue using the stoken refresh token to obtain new
access without being detectable by the authorization server.

Suggestion:
can potentially continue using the *stolen *refresh token to obtain new
access *tokens *without being detectable by the authorization server.

Also in *section-9.6,* it is a bit hard to understand what is meant by the
below statement.
*If POSTs in particular from unsupported single-page applications* are to
be rejected as errors per authorization server security policy...

Best Regards,
Janak Amarasena

---

From: Aaron Parecki <[email-masked]>
Date: Wed, 10 Jul 2019 16:27:47 -0700

> Isn't this recommendation neglecting some benefits  or use cases of

This recommendation doesn't say you can't still centralize your account
management in a dedicated component. If that component shares a domain with
the application, you don't need OAuth to hop back and forth, you can just
have the centralized account system set a cookie on the same domain. That
said, I also agree that it reads better as "it may be a better decision"
anyway.

Also in section-9.6, it is a bit hard to understand what is meant by the
> below statement.
> If POSTs in particular from unsupported single-page applications are to be
> rejected as errors per authorization server security policy...

I agree, it's confusingly worded and I'm not sure it actually adds anything
to the section, so I'm removing it.

Suggestion:
> authorization request...

I see the intent here, but I don't want to confuse this with normative
wording like "SHOULD". I've rephrased this paragraph to better lead into
the next two sections instead.

Leo and Janak, thanks for the other typo fixes too.

These edits are currently in my source file on GitHub,
https://github.com/aaronpk/oauth-browser-based-apps as I believe it's no
longer possible to publish an updated version to ietf until after the
meeting.

----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>

On Tue, Jul 9, 2019 at 1:08 PM Janak Amarasena <[email-masked]>
wrote:

> The Application Server SHOULD use the OAuth 2.0 authorization code grant
> to initiate a request *request *for an access token...
>
> Suggestion:
> The Application Server SHOULD use the OAuth 2.0 authorization code grant
> to initiate a request for an access token.
>
> *section-7*
> Original:
> Also in *section-9.6,* it is a bit hard to understand what is meant by
> the below statement.
>>>> This draft incorporates much of the feedback I've received over the
>>>> last couple months, as well as what we discussed at the last meeting in
>>>> Prague.
>>>>
>>>> The primary change is a significant rewrite and addition of Section 6
>>>> to highlight the two common deployment patterns, a SPA with and without a
>>>> dynamic backend.
>>>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 22 Jul 2019 15:30:41 +0200

Hi Aaron, 

thanks for your continued work on the topic. 

Here are some general remarks on the current revision: 

1) This BCP should not be limited to public clients. Your BCP itself already describes an architecture where the OAuth client is a backend that may be a confidential client (see section 6.2 for an example). The text of the BCP generally seems to be inconsistent regarding oauth client types.

I suggest to remove the second part of the first paragraph of the abstract (“and should not be issued a client secret when registered.") and other statements limiting the BCP to public clients. 

2) Regarding architectures: I think this BCP should focus on recommendations for securely implementing OAuth in the different potential architecture. I don’t think we should get into the business of recommending and assessing other solutions (e.g. section 6.1.). Just to give you an example: Section 6.1. states 

"OAuth and OpenID Connect provide very little benefit in this deployment scenario, so it is recommended to reconsider whether you need OAuth or OpenID Connect at all in this case.”

Really? What experiences is this statement based on? In my experience, sharing the same domain == host name tells you nothing about the overall architecture of a certain deployment. There may be several reasons why OAuth could be good choice in such a scenario, e.g. security considerations (since your common domain is just a proxy server encapsulating a whole universe of systems) or even modularity as an architecture principle. 

I suggest to remove section 6.1. and to rephrase the second paragraph of the abstract.

3) The naming in section 6 focus on the ways the JS could be served. I personally think the more important aspect is the architecture of the overall application. 

I suggest the following changes: 
- 6.2. Apps Served from a Dynamic Application Server -> SPA with backend
- 6.3. Apps Served from a Static Web Server -> SPA without backend 

Note: even an SPA with a backend could use a static web server to serve the JS code.

4) I don’t understand why your BCP distinguishes 1st and 3rd party apps. Neither the Native apps BCP nor security BCP do so and need to.

5) Section 9.8 seems to duplicate portions of the Security BCP (while not giving the complete threat model) - what is the benefit of duplicating this text?

6) I think the BCP would benefit from a refactoring. One idea would be to first state the problem with implicit and give general recommendations (PKCE and so on). The latter part could get into details of access and refresh token protection in the context of different SPA architectures (mTLS, CORS for CSRF prevention, …).

kind regards,
Torsten. 

> On 9. Jul 2019, at 01:03, Aaron Parecki <[email-masked]> wrote:
> 
> Hi all,
> 
> I've just uploaded a new version of oauth-browser-based-apps in preparation for the meeting in Montreal. 
> 
> This draft incorporates much of the feedback I've received over the last couple months, as well as what we discussed at the last meeting in Prague.
> 
> The primary change is a significant rewrite and addition of Section 6 to highlight the two common deployment patterns, a SPA with and without a dynamic backend. 
> 
> Please have a look and let me know what you think. I have a slot in the agenda for Montreal to present on this as well.
> 
> Thanks!
> 
> ----
> Aaron Parecki
> aaronparecki.com
>

---

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

I agree that there's a problem regarding the scope of this BCP .   Or at
least, I'm confused.

Is this BCP supposed to be all about the architecture where the browser
holds the token(s)?
If so, then

a) let's just put that out front and center: that's the context of this
BCP. That's what's meant by "browser-based application."
b) It really IS limited to public clients.
c) 6.2 simply doesn't belong: it is describing a different architecture.

If, on the other hand, 6.2 is to be retained, it needs to be rephrased from
saying the OAuth is not the right solution. Oauth can/will still be used,
but the token(s) will be used server side, not client/browser side.

- Leo

On Mon, Jul 22, 2019 at 9:31 AM Torsten Lodderstedt <[email-masked]>
wrote:

> 1) This BCP should not be limited to public clients. Your BCP itself
> already describes an architecture where the OAuth client is a backend that
> may be a confidential client (see section 6.2 for an example). The text of
> the BCP generally seems to be inconsistent regarding oauth client types.
>
> I suggest to remove the second part of the first paragraph of the abstract
> (“and should not be issued a client secret when registered.") and other
> statements limiting the BCP to public clients.
>
> 2) Regarding architectures: I think this BCP should focus on
> recommendations for securely implementing OAuth in the different potential
> architecture. I don’t think we should get into the business of recommending
> and assessing other solutions (e.g. section 6.1.). Just to give you an
> example: Section 6.1. states
>
> "OAuth and OpenID Connect provide very little benefit in this deployment
> scenario, so it is recommended to reconsider whether you need OAuth or
> OpenID Connect at all in this case.”
>
> Really? What experiences is this statement based on? In my experience,
> sharing the same domain == host name tells you nothing about the overall
> architecture of a certain deployment. There may be several reasons why
> OAuth could be good choice in such a scenario, e.g. security considerations
> (since your common domain is just a proxy server encapsulating a whole
> universe of systems) or even modularity as an architecture principle.
>
> 3) The naming in section 6 focus on the ways the JS could be served. I
> personally think the more important aspect is the architecture of the
> overall application.
>
> 4) I don’t understand why your BCP distinguishes 1st and 3rd party apps.
> Neither the Native apps BCP nor security BCP do so and need to.
>
> 5) Section 9.8 seems to duplicate portions of the Security BCP (while not
> giving the complete threat model) - what is the benefit of duplicating this
> text?
>
> 6) I think the BCP would benefit from a refactoring. One idea would be to
> first state the problem with implicit and give general recommendations
> (PKCE and so on). The latter part could get into details of access and
> refresh token protection in the context of different SPA architectures
> (mTLS, CORS for CSRF prevention, …).
>
> kind regards,
> Torsten.
>

---

From: Brian Campbell <[email-masked]>
Date: Tue, 23 Jul 2019 12:47:54 -0600

On Mon, Jul 22, 2019 at 7:31 AM Torsten Lodderstedt <[email-masked]>
wrote:

> I suggest to remove section c. and to rephrase the second paragraph of the
> abstract.
>

I believe the experiences that the statement is based on are the
predominant practice over the course of much of the history of the web of
using a cookie to maintain an authenticated HTTP session in web
applications. When the script of the browser-based application is served
from a domain that can share cookies with the domain of the API, then
cookies can still be used to authorize requests (even if those requests are
API calls rather than full page HTTP request/response). And I do believe
that's likely a better decision in a lot of such cases.

That authenticated HTTP session may be establish from a username/password
form submission, FIDO/WebAuthn, or whatever.  Even as a result of an OpenID
Connect flow. Or even SAML for that matter. But the the requests after that
are authorized by the cookie.

I think there's a tendency to assume because SPA style apps make API calls,
they simply must use OAuth. Because API implies OAuth in the minds of many
(which is a sign of its success). But OAuth isn't necessarily the only
thing that can be used for API authorization. Cookies work too. I
think/hope that's what Section 6.1. is getting at - providing some
potential guidance that OAuth might not necessarily be the right choice in
those cases where a common domain allows for a cookie. Perhaps the text in
that section could be phased in a different or better way, but I think its
useful to have some mention of in this document.

Although taking out "and OpenID Connect" from the sentence quoted above
might be more appropriate and alleviate some confusion.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: David Waite <[email-masked]>
Date: Tue, 23 Jul 2019 20:13:50 -0600

> On Jul 23, 2019, at 12:47 PM, Brian Campbell <bcampbell=[email-masked]> wrote:
> 
> 
> 
> On Mon, Jul 22, 2019 at 7:31 AM Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I suggest to remove section c. and to rephrase the second paragraph of the abstract.
> 
> I believe the experiences that the statement is based on are the predominant practice over the course of much of the history of the web of using a cookie to maintain an authenticated HTTP session in web applications. When the script of the browser-based application is served from a domain that can share cookies with the domain of the API, then cookies can still be used to authorize requests (even if those requests are API calls rather than full page HTTP request/response). And I do believe that's likely a better decision in a lot of such cases. 
> 
> That authenticated HTTP session may be establish from a username/password form submission, FIDO/WebAuthn, or whatever.  Even as a result of an OpenID Connect flow. Or even SAML for that matter. But the the requests after that are authorized by the cookie. 
> 
> I think there's a tendency to assume because SPA style apps make API calls, they simply must use OAuth. Because API implies OAuth in the minds of many (which is a sign of its success). But OAuth isn't necessarily the only thing that can be used for API authorization. Cookies work too. I think/hope that's what Section 6.1. is getting at - providing some potential guidance that OAuth might not necessarily be the right choice in those cases where a common domain allows for a cookie. Perhaps the text in that section could be phased in a different or better way, but I think its useful to have some mention of in this document. 
> 
> Although taking out "and OpenID Connect" from the sentence quoted above might be more appropriate and alleviate some confusion. 
> 

Perhaps it should be turned into a stated document assumption (that the reader has decided to use OAuth) rather than guidance later in the document (that OAuth may not be the best fit)

There is AFAIK no set of security considerations or best practices we can point to for “use some non-standardized system for acquiring and using cookies” or even “here’s a standard for acquiring and using cookies”. Omitting some of the moving pieces of OAuth might alleviate some security concerns, but also resurrect some other security issues. The most immediate example that comes to mind: using a HttpOnly cookie-as-token instead of an access token may mean that you can’t have injected scripts exfiltrate the token, but applying the access token was also a mitigation against browser CSRF for your APIs.

-DW

---

From: Tomek Stojecki <[email-masked]>
Date: Wed, 24 Jul 2019 07:50:10 +0000 (UTC)

I agree that 6.1 takes too broad of a swipe, but I'd say with same-site cookies and (sadly) without token-binding, the suggestion to use cookie based session following oauth/oidc auth is a good one and should be incorporated perhaps in 6.2?

Leo sums it up well here:
> 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.  

Finally and sorry if this is off-topic, why isn't this discussion taking place in github? Aaron has uploaded the document there. This medium, while good for some things, seems to have a lot of shortcomings for this sort of discussion and review. 

Thanks,
Tomek

On Wednesday, July 24, 2019, 04:14:14 AM GMT+2, David Waite <[email-masked]> wrote: 

> On Mon, Jul 22, 2019 at 7:31 AM Torsten Lodderstedt <[email-masked]> wrote:
>> 

-DW

---

From: Aaron Parecki <[email-masked]>
Date: Wed, 24 Jul 2019 16:13:55 -0400

*whew* this is a lot of feedback. I will try to address all of these points
in this thread.

On Mon, Jul 22, 2019 at 9:30 AM Torsten Lodderstedt <[email-masked]>
wrote:

> statements limiting the BCP to public clients.

Agreed, this was a holdover from before I added the section that describes
the confidential client architecture option. I've updated this accordingly.

> and assessing other solutions (e.g. section 6.1.).

This section was originally added from a discussion on the list, I believe
it was actually Torsten's suggestion:
https://mailarchive.ietf.org/arch/msg/oauth/JoEjvUrwE3pBPJI1olkEIR7ov9Q The
section was later modified and expanded based on feedback from the meeting
in Prague.

> might be more appropriate and alleviate some confusion.

I will remove this, since this document is supposed to be focusing on OAuth
anyway.

> - 6.3. Apps Served from a Static Web Server -> SPA without backend

I agree, but I'd like to continue to avoid using the term "SPA," so I'll
expand it out to "JavaScript Applications with a Backend".

> Neither the Native apps BCP nor security BCP do so and need to.

This was part of the original brainstorming of the document at IIW in
October, because many of us were worried about people deploying "creative"
solutions in first-party app situations such as iframes or using the
password grant. The intent was to be explicit about using the OAuth
authorization code flow rather than password or an iframe solution even for
first-party apps.

> giving the complete threat model) - what is the benefit of duplicating this

The intent here is to explicitly point out the issues with returning access
tokens in the front channel, in a way that is easy to find if someone is
looking for "what's wrong with using the implicit flow". I'd be happy to
shorten these to summaries and link out to the security BCP for the
details, but I do think it's valuable to have these called out in this
document.

> (mTLS, CORS for CSRF prevention, …).

One reason I didn't want to go with this approach is it kind of reinforces
the assumption that implicit flow == browser apps. Instead of defining the
BCP in terms of what *not* to do, I wanted to start with the
recommendations for what you *should* do when building a browser-based app,
and eventually get to describing why not to use the implicit flow.

On Tue, Jul 23, 2019 at 12:25 AM Leo Tohill <[email-masked]> wrote:

> holds the token(s)?

I believe that was the original intent, but then we wanted to call out the
case that you can actually have a SPA where the tokens don't live in the
browser and that may be a better choice for you.

On Wed, Jul 24, 2019 at 3:50 AM Tomek Stojecki <tstojecki=
[email-masked]> wrote:

Finally and sorry if this is off-topic, why isn't this discussion taking
> place in github? Aaron has uploaded the document there. This medium, while
> good for some things, seems to have a lot of shortcomings for this sort of
> discussion and review.

I would *love* to have this discussion on GitHub with individual GitHub
issues for each conversation thread, since it would be much easier to keep
track of when a particular conversation has been resolved. But my
understanding is that only the mailing list is the "official" or "on the
record" medium, so discussion has to happen here.

The changes mentioned here are now pushed to my GitHub version.

----
Aaron Parecki
aaronparecki.com

On Wed, Jul 24, 2019 at 3:50 AM Tomek Stojecki <tstojecki=
[email-masked]> wrote:

> I agree that 6.1 takes too broad of a swipe, but I'd say with same-site
> cookies and (sadly) without token-binding, the suggestion to use cookie
> based session following oauth/oidc auth is a good one and should be
> incorporated perhaps in 6.2?
>
> > 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.
>
> Finally and sorry if this is off-topic, why isn't this discussion taking
> place in github? Aaron has uploaded the document there. This medium, while
> good for some things, seems to have a lot of shortcomings for this sort of
> discussion and review.
>
> Thanks,
> Tomek
>
>
> > On Jul 23, 2019, at 12:47 PM, Brian Campbell <bcampbell=
> [email-masked]> wrote:
> >
> >
> >
> >> "OAuth and OpenID Connect provide very little benefit in this
> deployment scenario, so it is recommended to reconsider whether you need
> OAuth or OpenID Connect at all in this case.”
> >>
> > That authenticated HTTP session may be establish from a
> username/password form submission, FIDO/WebAuthn, or whatever.  Even as a
> result of an OpenID Connect flow. Or even SAML for that matter. But the the
> requests after that are authorized by the cookie.
> >
> > I think there's a tendency to assume because SPA style apps make API
> calls, they simply must use OAuth. Because API implies OAuth in the minds
> of many (which is a sign of its success). But OAuth isn't necessarily the
> only thing that can be used for API authorization. Cookies work too. I
> Perhaps it should be turned into a stated document assumption (that the
> reader has decided to use OAuth) rather than guidance later in the document
> (that OAuth may not be the best fit)
>
> There is AFAIK no set of security considerations or best practices we can
> point to for “use some non-standardized system for acquiring and using
> cookies” or even “here’s a standard for acquiring and using cookies”.
> Omitting some of the moving pieces of OAuth might alleviate some security
> concerns, but also resurrect some other security issues. The most immediate
> example that comes to mind: using a HttpOnly cookie-as-token instead of an
> access token may mean that you can’t have injected scripts exfiltrate the
> token, but applying the access token was also a mitigation against browser
> CSRF for your APIs.
>
> -DW

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 25 Jul 2019 20:59:18 +0200

Am 24.07.2019 um 22:13 schrieb Aaron Parecki <[email-masked]>:

>> 2) Regarding architectures: I think this BCP should focus on recommendations for securely implementing OAuth in the different potential architecture. I don’t think we should get into the business of recommending and assessing other solutions (e.g. section 6.1.).
> 
> This section was originally added from a discussion on the list, I believe it was actually Torsten's suggestion: https://mailarchive.ietf.org/arch/msg/oauth/JoEjvUrwE3pBPJI1olkEIR7ov9Q The section was later modified and expanded based on feedback from the meeting in Prague.

My latest feedback is inline with the post you refer to. There I suggested to also consider an architecture where the OAuth logic resides in a backend. I never suggested to add anything outside of an OAuth-based architecture.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 25 Jul 2019 21:00:36 +0200

> Am 24.07.2019 um 04:13 schrieb David Waite <[email-masked]>:
> 

+1

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 25 Jul 2019 21:04:04 +0200

> Am 24.07.2019 um 09:50 schrieb Tomek Stojecki <tstojecki=[email-masked]>:
> 

Sure. Such mechanisms are also used in a backend based architecture for OAuth, just as a complement and not an alternative to OAuth

> Finally and sorry if this is off-topic, why isn't this discussion taking place in github? Aaron has uploaded the document there. This medium, while good for some things, seems to have a lot of shor…

Well, since this is IETF ;-)