Subject: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 6 Nov 2018 09:55:15 +0000

Hi all,

Today we were not able to talk about draft-parecki-oauth-browser-based-apps-00, which describes  "OAuth 2.0 for Browser-Based Apps".

Aaron put a few slides together, which can be found here:
https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf

Your review of this new draft is highly appreciated.

Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Aaron Parecki <[email-masked]>
Date: Tue, 6 Nov 2018 11:13:37 +0100

Thanks Hannes,

Since I wasn't able to give an intro during the meeting today, I'd like to
share a little more context about this here as well.

At the Internet Identity Workshop in Mountain View last week, I led a
session to collect feedback on recommendations for OAuth for browser based
apps. During the session, we came up with a list of several points based on
the collective experience of the attendees. I then tried to address all
those points in this draft.

The goal of this is not to specify any new behavior, but rather to limit
the possibilities that the existing OAuth specs provide, to ensure a secure
implementation in browser based apps.

Thanks in advance for your review and feedback!

Aaron Parecki
aaronpk.com

On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig <[email-masked]>
wrote:

> Hi all,
>
> Today we were not able to talk about
> draft-parecki-oauth-browser-based-apps-00, which describes  "OAuth 2.0 for
> Browser-Based Apps".
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 
----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>

---

From: Joseph Heenan <[email-masked]>
Date: Wed, 7 Nov 2018 15:20:14 +0000

Hi Aaron,

Thanks for putting this document together, I think this kind of guidance is invaluable.

It may be worth slightly rewording 7.2 as it may encourage a growing misconception that all native apps must be public clients. With many devices now having embedded HSMs, we’ve seen increasing interest in mobile apps being dynamically (per-install) registered oauth2 private clients, and that model has a lot of advantages. (I’m not sure if we might see a similar model evolving for web apps.) 

The BCP for native apps does allow this:https://tools.ietf.org/html/rfc8252#section-8.4

Cheers,

Joseph

> On 6 Nov 2018, at 10:13, Aaron Parecki <[email-masked]> wrote:
> 
> Thanks Hannes,
> 
> Since I wasn't able to give an intro during the meeting today, I'd like to share a little more context about this here as well.
> 
> At the Internet Identity Workshop in Mountain View last week, I led a session to collect feedback on recommendations for OAuth for browser based apps. During the session, we came up with a list of several points based on the collective experience of the attendees. I then tried to address all those points in this draft.
> 
> The goal of this is not to specify any new behavior, but rather to limit the possibilities that the existing OAuth specs provide, to ensure a secure implementation in browser based apps.
> 
> aaronpk.com <http://aaronpk.com/>
> 
> 
> 
> On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> wrote:
> Hi all,
> 
> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf <https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> -- 
> ----
> Aaron Parecki
> aaronparecki.com <http://aaronparecki.com/>

---

From: Simon Moffatt <[email-masked]>
Date: Wed, 7 Nov 2018 16:08:15 +0000

It's an interesting topic.  I think there is a definitely a set of
options and considerations for this.  Namely operational.  For example,
hugely popular mobile apps (multi-million downloads across different
OS's) using dynamic reg with per-instance private creds requires the AS
to be able to store and index those client profiles easily.  Smaller
scale custom built authorization servers are not necessarily going to be
able to handle that - hence the popularity of assuming everything is
generic and public coupled with PKCE.

On the other hand, if a less popular first-party app used internally for
employees for example, might well go for secure element integration on
the appropriate mobile OS.

So, I guess options are needed and best practice for a few subtly
different scenarios.

Regards

Simon

On 07/11/18 15:20, Joseph Heenan wrote:
> It may be worth slightly rewording 7.2 as it may encourage a growing
> misconception that all native apps must be public clients. With many
> devices now having embedded HSMs, we’ve seen increasing interest in
> mobile apps being dynamically (per-install) registered oauth2 private
> clients, and that model has a lot of advantages. (I’m not sure if we
> might see a similar model evolving for web apps.) 
>
> The BCP for native apps does allow
> this:https://tools.ietf.org/html/rfc8252#section-8.4
>
> Cheers,
>
> Joseph
>
>
>
>
>
>> On 6 Nov 2018, at 10:13, Aaron Parecki <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> Thanks Hannes,
>>
>> Since I wasn't able to give an intro during the meeting today, I'd
>> like to share a little more context about this here as well.
>>
>> session to collect feedback on recommendations for OAuth for browser
>> based apps. During the session, we came up with a list of several
>> points based on the collective experience of the attendees. I then
>> tried to address all those points in this draft.
>>
>> The goal of this is not to specify any new behavior, but rather to
>> limit the possibilities that the existing OAuth specs provide, to
>> ensure a secure implementation in browser based apps.
>>
>> On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     Hi all,
>>
>>     draft-parecki-oauth-browser-based-apps-00, which describes 
>>     "OAuth 2.0 for Browser-Based Apps".
>>
>>     IMPORTANT NOTICE: The contents of this email and any attachments
>>     are confidential and may also be privileged. If you are not the
>>     intended recipient, please notify the sender immediately and do
>>     not disclose the contents to any other person, use it for any
>>     purpose, or store or copy the information in any medium. Thank you.
>>

-- 
ForgeRock <https://www.forgerock.com/> 	*Simon Moffatt*
Technical Director Product Management  |  ForgeRock
*t* (44) 7903 347 240  |  *e* [email-masked]
<mailto:[email-masked]>
*twitter* @simonmoffatt  |  *web* www.forgerock.com
<https://www.forgerock.com/>

NOTICE: This message, including any attachments, may contain
confidential information. If you are not the intended recipient, please
advise the sender immediately and destroy all copies of this message and
any attachments. ForgeRock Ltd may monitor email traffic data and also
the content of email transmitted over its network for security purposes.
No employee or agent is authorized to conclude any binding agreement on
behalf of ForgeRock Ltd by means of e-mail communication. ForgeRock Ltd
is a limited company registered in England and Wales; its registered
address is 60 Queen Square, Bristol, BS1 4JZ; and its registration
number is 7227664.

---

From: David Waite <[email-masked]>
Date: Wed, 7 Nov 2018 12:30:33 -0700

> On Nov 7, 2018, at 9:08 AM, Simon Moffatt <[email-masked]> wrote:
> 
> It's an interesting topic.  I think there is a definitely a set of options and considerations for this.  Namely operational.  For example, hugely popular mobile apps (multi-million downloads across different OS's) using dynamic reg with per-instance private creds requires the AS to be able to store and index those client profiles easily.  Smaller scale custom built authorization servers are not necessarily going to be able to handle that - hence the popularity of assuming everything is generic and public coupled with PKCE.
> 
Having unique client identifiers does provide some niceties. As examples: it gives a user a chance to administer/revoke those clients, and it gives the AS an opportunity to do behavioral analysis with a per-client rather than per-user granularity.

It also allows you to track user-granted consent per client. There are very limited options (really, just id_token_hint from OIDC) to indicate when hitting the authorization endpoint that you have prior consent.

In any case, the ability to work with public clients or the need to do dynamic client registration is AS policy, not something clients typically have the power to decide.

-DW

---

From: Tomek Stojecki <[email-masked]>
Date: Thu, 8 Nov 2018 11:19:14 +0000 (UTC)

Thanks for putting this together Aaron. 

Having read through the document, I am not as convinced that there is enough of a benefit of Authorization Code + PKCE vs Implict Flow for SPAs.

In section 7.8. the document outlines the Implicit flow disadvantages as following:

"- OAuth 2.0 provides no mechanism for a client to verify that an access token was issued to it, which could lead to misuse and possible impersonation attacks if a malicious party hands off an access token it retrieved through some other means to the client."

If you use Code + PKCE with no client secret (public client) as it is being advocated, you can't verify the client either. PKCE is not for authenticating the client, it is there to provide a mechanism to verify inter-app communication, which occurs between a browser and a native app. There is no inter-app communication in implicit (everything stays in the browser), so no need for PKCE.

"- Supporting the implicit flow requires additional code, more upkeep and understanding of the related security considerations, while limiting the authorization server to just the authorization code flow simplifies the implementation."

This is subjective and can be easily argued the other way. I think one of the main selling points behind implicit was its simplicity. It is hard to argue (putting libraries aside) that making one redirect (implicit) requires more code, work, etc.. than making a redirect and at least two additional calls in order to get AT (plus CORS on AS side).

Further, in the beginning paragraph of 7.8, you mention that implicit gets the AT through the front-channel. Exchanging code for AT will also happen in the browser , where instead of a url you will have an xhr (and again, now we have cors)

Finally, how is the AT going to be refreshed? Are we allowing for long lived RT in the browser? I see that the document mentions CSP in 7.7, but doesn't the same apply to securing AT with Implicit?

Regrads,
Tomek Stojecki

On Tuesday, November 6, 2018, 10:55:40 AM GMT+1, Hannes Tschofenig <[email-masked]> wrote: 

Hi all,

Ciao
Hannes

---

From: Daniel Fett <[email-masked]>
Date: Thu, 8 Nov 2018 17:42:21 +0100

Hi Aaron,

Thanks for writing up clear guidelines for SPAs. I reviewed the draft
and would like to offer some feedback:

One important aspect I am missing is a brief discussion on how, in
general, SPAs should be implemented; in particular, whether the
browser-app exchanges the code for an access token or whether the server
does that. In Section 7.6 it becomes clear that you propose to use the
first solution (do everything in the browser, as would be expected from
a true in-browser app).

Other remarks:

6.1.:
"The PKCE extension prevents an attack where the authorization code is
intercepted and exchanged for an access token by a malicious client"
I guess what you want to say here is that PKCE prevents the injection of
an *authorization code* by a *malicious user*, right?

6.2.:
"If an authorization server wishes to provide some flexibility in
redirect URI usage to clients, it MAY require that only the hostname
component of the redirect URI match the hostname of the URL the
application is served from."
At the bare minimum, the whole origin should be an exact match
(otherwise a network attacker can intercept the auth code in the authz
response when he uses the redirect URI http://correct-hostname.example ).

This is also further discussed here:
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-08#section-3.1
We there recommend exact redirect URI matching only.

And finally some nitpicking:

5.
"For example, an web email client" (an -> a)

"or use the OAuth Password grant" -> should be the "Resource Owner
Password Credentials Grant" to stick to the RFC6749 terminology

- Daniel

Am 06.11.18 um 11:13 schrieb Aaron Parecki:
> aaronpk.com <http://aaronpk.com>
>
>
>
>     draft-parecki-oauth-browser-based-apps-00, which describes  "OAuth
>     2.0 for Browser-Based Apps".
>
> aaronparecki.com <http://aaronparecki.com>

---

From: Daniel Fett <[email-masked]>
Date: Thu, 8 Nov 2018 17:43:38 +0100

Hi Tomek,

> If you use Code + PKCE with no client secret (public client) as it is being advocated, you can't verify the client either. PKCE is not for authenticating the client, it is there to provide a mechan…

PKCE can protect the auth code also in SPAs:

The assumption is that the authz response can leak - it is just a URL
after all. It can appear in log files, leak through mix-up, and many
other attacks. (Browser-to-native app communication is just one case
where the authz response can leak.)

When using PKCE, an attacker cannot redeem a leaked auth code for a
token at the token endpoint, since he does not know the pkce verifier. 

That is the extra protection that PKCE provides.

- Daniel

---

From: David Waite <[email-masked]>
Date: Thu, 8 Nov 2018 14:59:16 -0700

> On Nov 8, 2018, at 4:19 AM, Tomek Stojecki <tstojecki=[email-masked]> wrote:
> 

Use of a fixed set of uniquely resolvable redirect URIs (e.g. not localhost, not arbitrarily registrable custom URI schemes) does provide an addressable channel to the public client for codes and implicit tokens. I should not be able to make a client that can reuses the public identifier as a third party, because I cannot catch the response URL from the authorization endpoint.

The difference is with implicit, the first party client cannot verify the tokens were meant for the client (or really even that they came from the AS). With code, you are contacting the AS and doing an exchange based on the code and your public client identifier.

In the sense of pure OAuth, where no authentication or additional authorization decisions are made based on the access token, the issuer and audience client could be checked via an introspection endpoint - but if you are using pure OAuth and not relying on things like CORS restrictions for your security model, it shouldn’t matter.

For OpenID Connect and cases where you are going beyond a pure authorization model (perhaps by having API access restricted by CORS), this sort of check is important. You could trust clients to explicitly check by looking in an id_token (when available) or calling an introspection endpoint, or you could have this check happen as part of normal flow by using code flow.

PCKE does not resolve any known code injection attacks for SPA public clients. Recommending administrators require PKCE does allow them to start to make a single coherent policy for public clients.

A consistent policy also helps in SPA/native app crossover cases. For examples, a javascript app could be published as a native app via wrapping in a Cordova-style toolset, or by sharing a significant amount of code using a React-native style toolset. Both the SPA and native app could then share handling links depending on native app installation due to universal/app link features of the operating systems. For this reason, there was a definite effort to propose best practices that overlapped with the native app BCP.

It is also worth noting that since the SPA and native app could share the same client identifier and redirect handling (via universal links), you *could* have code injection, but it would be between multiple first-party apps.

> This is subjective and can be easily argued the other way. I think one of the main selling points behind implicit was its simplicity. It is hard to argue (putting libraries aside) that making one r…

The implicit flow is only simpler for clients until they have to get a new access token. Typically then you need a different set of OAuth code to request a new token in the background via a hidden iframe, failing back to temporarily leaving the app via top-level redirect. There are also cases where the safari browser detects this cross-domain iframe bouncing as a tracker and segments any AS cookies/storage per client site.

It is more work for the AS to support both. You may also wind up having different security models for the two different public client flows. In particular, you may find yourself as an AS policy setter wanting to have longer lived sessions for implicit clients which do not have refresh tokens to extend access token validity in the background. For this reason, you may also decide implicit clients cannot get access to the same scopes that a code client can. 

There are also gotchas people are not used to in implicit, such as fragment identifiers being preserved on redirects.

For OpenID Connect, getting the id_token on a back-end call means that there is still transport-level security of the value if clients ignore the signature. Again, you could trust your clients to explicitly add signature verification code for id_tokens and access token hashes, as well as verify the token issuer and audience - or you could have a baseline level of security by using the code flow.

> Finally, how is the AT going to be refreshed? Are we allowing for long lived RT in the browser? I see that the document mentions CSP in 7.7, but doesn't the same apply to securing AT with Implicit?

Refresh tokens are used for two different purposes, and this might be worth clarifying for those setting their security policy:

1. refresh tokens for “offline” access, meaning that the client may perform actions on the user’s behalf while the user isn’t around. Typically, this means the refresh token lasts until the user or AS revokes it, so authorization thus also remains until revoked.
2. refresh tokens as a signaling method for re-authentication. In this case, the idea is that tokens are being used “online” as part of user interaction, with the application being forced to send the user to the AS to re-authenticate when the access token can no longer be refreshed. If the AS can track consent to the client (by a unique client identifier or via a mechanism like id_token_hint), this re-authentication may still require no user interaction.

For public clients, I see us using the second “online” refresh tokens. Whether they are long-lived or not really depends on the AS policy for re-authentication. If the client is being run on a device falling under corporate management, the AS might decide to make those particular refresh tokens last indefinitely.

-DW

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 9 Nov 2018 18:14:37 +0100

> Am 08.11.2018 um 22:59 schrieb David Waite <[email-masked]>:
> 
> PCKE does not resolve any known code injection attacks for SPA public clients.

It can be utilized to detect code injection at the redirect between AS and client. The PKCE verifier is bound to user agent that initiated the corresponding request. The AS binds the code to the respective PCKE challenge. If a code is stolen and injected at a different user agent, the PKCE verifier check will fail at the AS (because the client will use the wrong PKCE verifier).    

https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-3.5

---

From: David Waite <[email-masked]>
Date: Fri, 9 Nov 2018 11:44:22 -0700

Hi Hans, I hope it is acceptable to reply to your message on-list.

Others could correct me if I am wrong, but I believe the purpose of this document is to recommend uses of other OAuth/OIDC specifications, not to include its own technologies.

In terms of being another spec to be referenced, I think it would be useful but I wonder hypothetically how to best write that specification. This method seems to be relying on standards-defined tokens and converting them to an application server session, which isn’t defined by behavior other than HTTP cookies. The session info hook then lets you use those proprietary session tokens to retrieve the access/id token.

As such, it is closer to an architecture for implementing a client - as a confidential client backend with an associated SPA frontend that needs to make OAuth-protected calls. It is not describing the communication between existing OAuth roles, such as between the client and AS.

There’s obvious value here, and it's one of several architectures for browser-based apps using a confidential client rather than a public one (another example being a reverse proxy which maps remote OAuth endpoints into local, session-token-protected ones). I personally am just not sure how you would define the communication between back-end and front-end portions of the client in these architectures as a standard within OAuth.

-DW

> On Nov 6, 2018, at 3:03 AM, Hans Zandbelt <[email-masked]> wrote:
> 
> Hi Aaron, DW,
> 
> About draft-parecki-oauth-browser-based-apps:
> would you consider including a recommendation about and the standardization of a "session info" endpoint (I'm open for better naming ;-)) as described in:
> https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-page-applications/ <https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-page-applications/>
> 
> this approach is not just something that I cooked up; it is based on real world requests & deployments at Netflix and OAth.
> 
> Let me know what you think,
> 
> Hans.
> 
> [email-masked] <mailto:[email-masked]>
> ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu/>

---

From: "Brock Allen" <[email-masked]>
Date: Fri, 09 Nov 2018 15:22:11 -0500

Hello all --

I also have some thoughts/feedback on this document.

Personally I agree with some of the conclusions, but as it stands I think the document's main conclusion that code flow is the real solution is not sufficiently convincing.

I would like to see a brief summary of the current concerns (much like RFC8252 does) so we have context before the document just jumps to what a best practice is. The reason I bring this up is that generally the concept of "best practice" is meaningless without context. I think stating that code flow is best practice without motivation seems somewhat "cart before the horse".

I think just a short blurb about the desire to eliminate the access token from being delivered in the URL, and the current attacks against doing so would be helpful (showing attacks is super important in making this "real"). I guess this would make the most sense in section "4. Overview" prior to the list of "best practice" conclusions.

Section "7.8. OAuth Implicit Grant Authorization Flow" does try to get into specifics, but many of the points seem confused (or at least confuse me) and/or the conclusion that code flow is the only approach seems misleading. For example:

"The Implicit Flow cannot be protected by PKCE [RFC7636] (which is required according to Section 6), so clients and authorization servers MUST NOT use the Implicit Flow for browser-based apps."

This is specious. The threat is the token is in the URL, not that implicit clients can't use PKCE. So perhaps the document should explain the variety of mitigations, not just one? While code flow is one, using CSP and the browser history API to remove the token from the URL is another. Elsewhere in the document the use of CSP is a "SHOULD". That's great, but using CSP can be and is used today, and doesn't necessitate code flow.

"OAuth 2.0 provides no mechanism for a client to verify that an access token was issued to it, which could lead to misuse and possible impersonation attacks if a malicious party hands off an access token it retrieved through some other means to the client."

Sure, but OIDC does provide a mitigation for this (even with implicit). So perhaps it should be offered as a suggestion as well? I did see the point that with code flow id_token validation could instead rely upon the token endpoint, but the client still has other work to do (namely around PKCE). That's just trading one bit of work for another, not a clear cut reason to use one flow over another.

"Supporting the implicit flow requires additional code, more upkeep and understanding of the related security considerations, while limiting the authorization server to just the authorization code flow simplifies the implementation."

As offered by someone else already, this is opinion and not objective. IMO, this diminishes the potential of this document.

"If the JavaScript application gets wrapped into a native app, then [RFC8252] also requires the use of the authorization code flow."

Given how many browser dependencies SPA apps tend to have, is this really common? In all my years building both, I've never seen it.

"Historically, the Implicit flow provided an advantage to single-page apps since JavaScript could always arbitrarily read and manipulate the fragment portion of the URL without triggering a page reload. Now with the Session History API (described in "Session history and navigation" of [HTML]), browsers have a mechanism to modify the path component of the URL without triggering a page reload, so this overloaded use of the fragment portion is no longer needed."

While this section is intended to indicate the existence of the history API is a reason to move away from implicit, it's also what can be used to protect token exposure in the URL, which I think weakens its point. As a section, to me, it seems unnecessary.

The push to a single flow (for consistency) is a marginal motivation, and I agree with that theme in the document.

Much of the other guidance in this document is already covered elsewhere (e.g. RFC6819). I don't know if the goal of the document is to reproduce those existing recommendations (as a contrast RFC8252 does not and mainly focuses on what's unique to the native scenario).

I can't quite tell the real motivation for this "best practice" document. If it's trying to give guidance for browser-based JS apps, then perhaps it should be enhanced to give guidance for the existing implicit flow, as well as suggesting code flow? But if the real motivation is just to kill off implicit flow then more needs to be done, IMO.

Finally, my last real concern (which is why I'm pushing back so much on code flow), is that this implies refresh tokens in the browser. My sense is that given the danger of this, the original OAuth2 RFC (via the implicit flow) was designed to limit the client's ability to obtain new access tokens based on the user's authentication session at the AS (via a cookie). Allowing refresh tokens now means that a successful attacker has unfettered ability to do this (beyond just an access token's lifetime). And yes, CSP is mentioned as a mitigation to protect the refresh token, but it was already necessary to protect the access token, so CSP is not the only mitigation. What's missing is strong guidance for token servers to provide mechanisms to limit the lifetime of refresh tokens for these high risk client scenarios. I have a suspicion that many existing token servers do not have such features, and this would imply more features mandated for the token servers (beyond PKCE for example).

Having said all of these things, I am all for using code flow. I just would like there to be more clear rationale. My comments above were the various counter arguments I was thinking while reading this document, and given how many of these I came up with I was left feeling unconvinced (as I already mentioned).

Thanks for reading this far, and thanks for putting forth the document.

-Brock

On 11/6/2018 5:14:05 AM, Aaron Parecki <[email-masked]> wrote:
Thanks Hannes,

Aaron Parecki
aaronpk.com [http://aaronpk.com]

On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig <[email-masked] [mailto:[email-masked]]> wrote:

Hi all,

Aaron put a few slides together, which can be found here:
https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf [https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf]

Ciao
Hannes

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

--

----
Aaron Parecki
aaronparecki.com [http://aaronparecki.com]
@aaronpk [http://twitter.com/aaronpk]

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

---

From: "Brock Allen" <[email-masked]>
Date: Fri, 09 Nov 2018 17:07:31 -0500

> Finally, my last real concern (which is why I'm pushing back so much on code flow), is that this implies refresh tokens in the browser. My sense is that given the danger of this, the original OAuth…

And to expand upon this serious concern -- CSP only protects the current page from things like XSS. It does not protect every other page under your domain. IOW, your app using/storing refresh tokens (and access tokens) is trusting every other page on the domain to also be protected from XSS. At least an access token compromised this way has an expiration, whereas unbounded refresh tokens won't necessarily. This is why I am pushing for strong guidance around refresh token expirations, and this requires the token servers to implement and enforce this. 

So this sort of threat should possibly be used in the document to reinforce and motivate such guidance.

-Brock

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 13 Nov 2018 20:07:58 +0100

Hi Brock,

> Am 09.11.2018 um 21:22 schrieb Brock Allen <[email-masked]>:
> 
> Hello all --
> 

I agree, justifications are needed. As draft-ietf-oauth-security-topics-09 provides those justifications, I suggest to add suitable references here. 

> "The Implicit Flow cannot be protected by PKCE [RFC7636] (which is required according to Section 6), so clients and authorization servers MUST NOT use the Implicit Flow for browser-based apps.“

Don’t understand the wording either. The text should state that the implicit cannot detect token injection.

> 
> This is specious. The threat is the token is in the URL, not that implicit clients can't use PKCE. So perhaps the document should explain the variety of mitigations, not just one? While code flow is one, using CSP and the browser history API to remove the token from the URL is another.

Helps to prevent leakage, not injection in the authorization response. 

> Elsewhere in the document the use of CSP is a "SHOULD". That's great, but using CSP can be and is used today, and doesn't necessitate code flow.
> 
> Sure, but OIDC does provide a mitigation for this (even with implicit).

This is about token replay detection at the RS. What mitigation does OIDC provide here? 

> So perhaps it should be offered as a suggestion as well? I did see the point that with code flow id_token validation could instead rely upon the token endpoint, but the client still has other work to do (namely around PKCE). That's just trading one bit of work for another, not a clear cut reason to use one flow over another.
> 
> Finally, my last real concern (which is why I'm pushing back so much on code flow), is that this implies refresh tokens in the browser. My sense is that given the danger of this, the original OAuth2 RFC (via the implicit flow) was designed to limit the client's ability to obtain new access tokens based on the user's authentication session at the AS (via a cookie).

The implicit grant was not equipped with the ability to issue refresh tokens simply because the working group didn’t want them to end up in the browser history, leak through open redirectors etc. This is different with code since tokens travel directly through a TLS protected connection.  

> Allowing refresh tokens now means that a successful attacker has unfettered ability to do this (beyond just an access token's lifetime).

First of all the AS decides whether it issues refresh tokens or not. Having the ability does not mean the AS must do it. If you feel it’s safer to not do it. Fine. It’s still possible to refresh your access tokens the way you mentioned above by sending another authorization request to the AS. 

But let’s assume for a moment the AS, based on its risk assessment, decides to issue refresh tokens. Can you please explain how an attacker will get access to this tokens? Especially what the expected strength of the attacker would need to be? 

I would also like to understand how a refresh token is any different from a long living cookie in the browser and what you think is the big difference to mobile apps when it comes to refresh token handling. 

> And yes, CSP is mentioned as a mitigation to protect the refresh token, but it was already necessary to protect the access token, so CSP is not the only mitigation. What's missing is strong guidance for token servers to provide mechanisms to limit the lifetime of refresh tokens for these high risk client scenarios. I have a suspicion that many existing token servers do not have such features, and this would imply more features mandated for the token servers (beyond PKCE for example).

Good point! I will add text on refresh protection to the Security BCP. Limiting the refresh tokens lifetime, rotating them on every refresh (allowing the AS to detect replay), binding refresh tokens to certs etc. 

> Thanks for reading this far, and thanks for putting forth the document.

Thanks for your feedback. 

kind regards, 
Torsten,

>> On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig <[email-masked]> wrote:
>> Hi all,
>> 
>> Your review of this new draft is highly appreciated..
>> 
>> Ciao
>> Hannes
>> @aaronpk

---

From: "Brock Allen" <[email-masked]>
Date: Thu, 15 Nov 2018 09:01:27 -0500

> Helps to prevent leakage, not injection in the authorization response.

So then wording and its motivation could get updated to correctly reflect that.

>This is about token replay detection at the RS. What mitigation does OIDC provide here? 

The wording doesn't go with that, then. My point about OIDC is that with the at_hash in the id_token provides a mitigation so the client can verify that the access token was issued to it.

> The implicit grant was not equipped with the ability to issue refresh tokens simply because the working group didn’t want them to end up in the browser history, leak through open redirectors etc. T…

Well, if limiting the access token renewal to the user's session lifetime wasn't a conscious design goal, it's a very interesting side effect which does limit the potential of an attacker.

> First of all the AS decides whether it issues refresh tokens or not. Having the ability does not mean the AS must do it. If you feel it’s safer to not do it. Fine. 

Sure, and this should be mentioned then somewhere (either in the threats doc or in this proposed best practice doc). Not all end developers using these protocols fully understand the ramifications. 

> It’s still possible to refresh your access tokens the way you mentioned above by sending another authorization request to the AS. 

This also could be added as a proposal for an alternative to renewing tokens. It provides more awareness to folks, and aids in a potential best practice depending on the requirements of the consuming app.

> But let’s assume for a moment the AS, based on its risk assessment, decides to issue refresh tokens. Can you please explain how an attacker will get access to this tokens? Especially what the expec…

I don't have a profile of an attack. But I'm assuming it's no different than anything in the past we've been trying to defend against when we considered the potential for an access token to be exfiltrated. So my point is that an access token will expire so an attacker would then have to go back and re-attack the app to get a new access token to continue to have access to the user's resource. But now with refresh tokens in the picture, the attacker would have both and then not need to go back to the app to continue to have access to the user's resource. 

> I would also like to understand how a refresh token is any different from a long living cookie in the browser and what you think is the big difference to mobile apps when it comes to refresh token…

To use the cookie, the app must be active, and the attacker must be attacking the app itself.

Maybe a different way to say it is that an attacker must only compromise the app once to have long lived access, whereas without refresh tokens the attacker can attack the app once, but the once the comprised access token is expired they would have to re-attack the app to get another access token. Refresh tokens means they only have to get in once to the app, then they no longer have to go back to the source. Maybe there's a better way to convey what I'm trying to say...

Also, I guess my question/comment about providing guidance for existing implicit flow clients is not up for discussion? Again, my reasoning is that it's a hard sell to always say there's exactly one right way to do something. And since so many clients have been built based on implicit flow that might not be able to change quickly to a new flow, perhaps there are "baby steps" that can be suggested to help them improve their security.

-Brock

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 15 Nov 2018 20:27:07 +0100

Hi Brock, 

> Am 15.11.2018 um 15:01 schrieb Brock Allen <[email-masked]>:
> 

Understand, you are referring to the token injection prevention provided by „token id_token“ or „code token id_token“. It still lacks the ability to issue sender constraint access tokens. So if you wanna take the risk associated with bearer tokens you can use it. The Security BCP recommends to use sender constraint access tokens, so we cannot recommend response types not supporting this pattern. 

> Well, if limiting the access token renewal to the user's session lifetime wasn't a conscious design goal, it's a very interesting side effect which does limit the potential of an attacker.

That’s true. Note that the effectiveness of limitation depends on the lifetime of the issued access tokens. 

The AS can bind the lifetime of the refresh tokens to the session lifetime, i.e. automatically revoke it on logout. 

In my opinion, whether this is the most appropriate choice largely depends on what the client uses the token for. If the client effectively relies on the AS (OP) to login the user and obtain user data that makes sense. If the client has an independent login and uses the tokens to access resources (e.g. contacts), the session with the AS does not have  a real meaning with respect to this client. Potentially the client even stores the refresh token in a backend with the user account. 

> Sure, and this should be mentioned then somewhere (either in the threats doc or in this proposed best practice doc). Not all end developers using these protocols fully understand the ramifications. 

@Aaron: I suggest this goes to the SPA BCP since this is client specific.

> This also could be added as a proposal for an alternative to renewing tokens. It provides more awareness to folks, and aids in a potential best practice depending on the requirements of the consumi…

I agree. 

> I don't have a profile of an attack. But I'm assuming it's no different than anything in the past we've been trying to defend against when we considered the potential for an access token to be exfi…

Largely depends on the refresh token protection. I case of public clients I would always recommend to rotation refresh tokens with every refresh. This renders the old refresh tokens useless. If the attacker happens to be at the lucky end and conducts the first refresh, the AS should be able to detect the replay when the legit user tries to refresh. It then shall revoke the active (in possession of the attacker) refresh token as well. 

I will add this to the Security BCP.

> Maybe a different way to say it is that an attacker must only compromise the app once to have long lived access, whereas without refresh tokens the attacker can attack the app once, but the once the comprised access token is expired they would have to re-attack the app to get another access token. Refresh tokens means they only have to get in once to the app, then they no longer have to go back to the source. Maybe there's a better way to convey what I'm trying to say…

I think I understand. Refresh tokens can be used outside of the user agent. Token rotation and expiration would be potential mitigations, token binding too.

> Also, I guess my question/comment about providing guidance for existing implicit flow clients is not up for discussion? Again, my reasoning is that it's a hard sell to always say there's exactly on…

The only potential „baby step“ I would see is to move towards „token id_token“. Since this requires signature/at_hash checks etc. I doubt this is really easier than moving to code and exchange the code for an access token. What’s your opinion?

kind regards,
Torsten.

---

From: "Brock Allen" <[email-masked]>
Date: Thu, 15 Nov 2018 17:01:10 -0500

> It still lacks the ability to issue sender constraint access tokens.

So you mean at the resource server ensuring the token was really issued to the client? Isn't that an inherent limitation of all bearer tokens (modulo HTTP token binding, which is still some time off)? Resource servers don't know the flow the clients might use, especially if/when they have many clients.

> The AS can bind the lifetime of the refresh tokens to the session lifetime, i.e. automatically revoke it on logout.

Yea, I saw your other email asking about refresh token revocation relating to session management. Obviously for certain clients, this won't make sense, but for implicit/browser-based ones it's a nice feature to have.

The alternative, as you mentioned, is to not issue refresh tokens and do token renewal the "same old way" via iframe with prompt=none, while still using code flow.

> The only potential „baby step“ I would see is to move towards „token id_token“. Since this requires signature/at_hash checks etc. I doubt this is really easier than moving to code and exchange the…

Even since OIDC arrived, this is the only flow I use for JS/browser-based clients (anything less has always seemed so obviously inferior). So for me and my customers, all browser-based clients I am involved in are already there. Perhaps this is the reason for all of my questions/comments about the recent BCP doc. Given "id_token token", CSP, and using the browser history API to wipe the access token from browser history, we already have a decent set of tools to mitigate attacks. As I already conceded, the only remaining issue (IMO) is the short window of time the access token is in the URL.

Given that it seems to me that OIDC and OAuth2 are typically used together (at least when a user is involved with authentication), I always wonder why the OAuth and OIDC WGs are separate. Given that so much effort of the two sets of specs overlap, it seems odd to keep adding onto the OAuth specs and ignoring the added features that OIDC provides. I don't mean to derail this thread, or step on any political toes, so apologies in advance.

-Brock

---

From: Daniel Fett <[email-masked]>
Date: Fri, 16 Nov 2018 08:57:52 +0100

Hi all,

Am 09.11.18 um 21:22 schrieb Brock Allen:
>
> Section "7.8. OAuth Implicit Grant Authorization Flow" does try to get
> into specifics, but many of the points seem confused (or at least
> confuse me) and/or the conclusion that code flow is the only approach
> seems misleading. For example:
>
> "The Implicit Flow cannot be protected by PKCE [RFC7636] (which is
> required according to Section 6), so clients and authorization servers
> MUST NOT use the Implicit Flow for browser-based apps."
>
> This is specious. The threat is the token is in the URL, not that
> implicit clients can't use PKCE. So perhaps the document should
> explain the variety of mitigations, not just one? While code flow is
> one, using CSP and the browser history API to remove the token from
> the URL is another. Elsewhere in the document the use of CSP is a
> "SHOULD". That's great, but using CSP can be and is used today, and
> doesn't necessitate code flow.

Could you please expand on what you are achieving with replacing the URL
using the history API? Removing the token from the browser's history, or
any protection beyond that?

>
> "Supporting the implicit flow requires additional code, more upkeep
> and understanding of the related security considerations, while
> limiting the authorization server to just the authorization code flow
> simplifies the implementation."
>
> As offered by someone else already, this is opinion and not objective.
> IMO, this diminishes the potential of this document.

Another aspect is that removing implicit as an option greatly simplifies
security analysis and formal proofs of security (of which I hope we will
see more instances in the future). If you look at it this way, it is
much more than an opinion and it is definitely objective.

- Daniel

---

From: n-sakimura <[email-masked]>
Date: Fri, 16 Nov 2018 09:12:11 +0000

Good points.

Also, while it may be off-topic, I do see values in implicit flows. In some cases, such as when the AS is inside the firewall or on a localhost (e.g., smartphone), “code flow” is not possible as the client cannot reach the AS directly. Banning implicit (and thus “token id_token” as well) has this repercussion and I would not agree to it.

Best,

Nat Sakimura

From: OAuth <[email-masked]> On Behalf Of Brock Allen
Sent: Friday, November 16, 2018 7:01 AM
To: Torsten Lodderstedt <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

-Brock

---

From: Tomek Stojecki <[email-masked]>
Date: Fri, 16 Nov 2018 12:59:50 +0000 (UTC)

> Yea, I saw your other email asking about refresh token revocation relating to session management. Obviously for certain clients, this won't make sense, but for implicit/browser-based ones it's a ni…
I agree that this can be useful, however with where we are today, is this supported by auth servers such that it can distinguish offline from renewable-online clients and only revoke the latter when logging out? 
> The alternative, as you mentioned, is to not issue refresh tokens and do token renewal the "same old way" via iframe with prompt=none, while still using code flow.

Going from Implicit to Code deals with the problem of sending RT in the URL, which I agree is a plus. Is there anything else in a way of an improvement? I still am not comfortable enough with the idea of releasing RTs to the browser clients where it can't be encrypted, prone to xss, etc... 

-Tomek

-Brock

---

From: "Brock Allen" <[email-masked]>
Date: Fri, 16 Nov 2018 10:11:17 -0500

> Could you please expand on what you are achieving with replacing the URL using the history API? Removing the token from the browser's history, or any protection beyond that?

Just this block of code which would be run on the redirect_uri page loaded in the client (after id_token/token validation is complete):

https://github.com/IdentityServer/IdentityServer4.Samples/blob/release/Clients/src/JsOidc/wwwroot/callback.js#L4-L6

-Brock

---

From: "Brock Allen" <[email-masked]>
Date: Fri, 16 Nov 2018 11:01:19 -0500

> Going from Implicit to Code deals with the problem of sending RT in the URL, which I agree is a plus. Is there anything else in a way of an improvement? 

As far as I can tell, that's the only additional security feature (beyond what we already use for mitigations today) that code flow adds. That's why I was hoping for the proposed BCP to explicitly point this out, which means all the other mitigations and guidance in the document are valid and useful for implicit flow.

-Brock

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 17 Nov 2018 12:07:00 +0100

Hi Brock,

> Am 15.11.2018 um 23:01 schrieb Brock Allen <[email-masked]>:
> 
> So you mean at the resource server ensuring the token was really issued to the client? Isn't that an inherent limitation of all bearer tokens (modulo HTTP token binding, which is still some time off)?

Sure. That’s why the Security BCP recommends use of TLS-based methods for sender constraining access tokens (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2.2). Token Binding for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as Mutual TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options available. 

> Resource servers don't know the flow the clients might use, especially if/when they have many clients.

They don’t need to. All they need to know is how to determine whether the sender of the token is the legit client. This is achieved by comparing the hash of the token binding id or the cert of the client conveyed in the access token with the respective data from the TLS handshake. 

> The alternative, as you mentioned, is to not issue refresh tokens and do token renewal the "same old way" via iframe with prompt=none, while still using code flow.

yes. 

Have you ever experienced issues with the latter approach and the browser’s 3rd party cookie policy?

> Even since OIDC arrived, this is the only flow I use for JS/browser-based clients (anything less has always seemed so obviously inferior). So for me and my customers, all browser-based clients I am…

There are two angles to approach access token leakage and replay from two angles, (a) preventing leakage (that’s what you can do with the browser history API, TLS, ...) or (b) detecting replay (that’s what one can do with sender constraint access tokens). 

The focus of OAuth/OIDC was on (a) but experiences have shown this is of limited effectivity, especially in dynamic/open scenarios, which we are seeing increasingly due to open banking, eHealth, eID, …. So sealing the problem from both ends seems reasonable.  
 
> Given that it seems to me that OIDC and OAuth2 are typically used together (at least when a user is involved with authentication), I always wonder why the OAuth and OIDC WGs are separate. Given tha…

No problem. As already stated, OIDC, esp. FAPI, and OAuth need to be aligned on that point. 

Thanks for the insights you shared. We will be publishing another revision of the OAuth Security BCP soon, which also adds recommendation and justification based on our discussions. 

kind regards, 
Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 17 Nov 2018 12:14:38 +0100

Hi Nat, 

> Am 16.11.2018 um 10:12 schrieb n-sakimura <[email-masked]>:
> 
> Good points.
> 
>  
> 
> Also, while it may be off-topic, I do see values in implicit flows. In some cases, such as when the AS is inside the firewall or on a localhost (e.g., smartphone), “code flow” is not possible as the client cannot reach the AS directly.

are you saying the browser can send the HTTP GET to the authorization endpoint but the JS in the browser cannot send the HTTP POST to the token endpoint? 

> Banning implicit (and thus “token id_token” as well) has this repercussion

First of all we are not banning anything. The OAuth WG does no longer recommend to use the implicit for very good reasons, which can be found here https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi#rfc.section.2.1.2

I would appreciate your comments. 

> and I would not agree to it.

As you were always on the „make it secure“ side, I’m a bit surprised. 

kind regards,
Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 17 Nov 2018 12:26:56 +0100

Hi Tomek,

> Am 16.11.2018 um 13:59 schrieb Tomek Stojecki <[email-masked]>:
> 

See other thread on refresh token revocation on logout. There seems to be some implementations. Basically, I don’t think the clients needs to now because it always needs to be prepared to handle invalid (invalidated) refresh tokens (see https://tools.ietf.org/html/rfc6749#section-5.2). 

> Going from Implicit to Code deals with the problem of sending RT in the URL, which I agree is a plus.

Have you taken a look at https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2.1.2? It gives all the justification. 

> Is there anything else in a way of an improvement? I still am not comfortable enough with the idea of releasing RTs to the browser clients where it can't be encrypted, prone to xss, etc… 

As already stated. The AS is not required to issue refresh tokens.

If the AS decides to issue refresh tokens, there are ways to protect the refresh token from replay even for public clients. 

To start with, the AS may use refresh token rotation in combination with automatic revocation in case of detected replay attempts. 

How does it work? The AS issues a new refresh token with every refresh and invalidate the old one. This restricts the lifetime of a refresh token. If someone (might be the legit client or an attacker) submits one of the older, invalidated refresh token, the AS might interpret this as a signal indicating token leakage and revoke the valid refresh token as well. We used this technique at Deutsche Telekom since our first OAuth 2.0 implementation back in 2012.

An emerging alternative is to use Token Binding (in browser) or Mutual TLS (other clients) to bind the refresh token to the client’s key key pair.

kind regards,
Torsten.

---

From: Brian Campbell <[email-masked]>
Date: Sat, 17 Nov 2018 15:08:18 -0700

I might suggest that neither of those are really best current practice per
se. Using key constrained tokens is more of an aspirational recommendation
for what would be good security practice than it is something that's done
much for real in practice today.

On Sat, Nov 17, 2018, 4:07 AM Torsten Lodderstedt <[email-masked]
wrote:

> > So you mean at the resource server ensuring the token was really issued
> to the client? Isn't that an inherent limitation of all bearer tokens
> (modulo HTTP token binding, which is still some time off)?
>
> Sure. That’s why the Security BCP recommends use of TLS-based methods for
> sender constraining access tokens (
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2).
> Token Binding for OAuth (
> https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as
> Mutual TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12)
> are the options available.
>
>
>
>

-- 
_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: Vladimir Dzhuvinov <[email-masked]>
Date: Mon, 19 Nov 2018 11:48:40 +0200

Hi everyone,

> Have you ever experienced issues with the latter approach and the browser’s 3rd party cookie policy?

I expect that what's ultimately going to drive people away from
"implicit" and to "code" is blocked 3rd party cookies in browsers
breaking renewal for clients via an iframe.

IMO this policy is only more likely to spread out in browsers than
getting rolled back.

Vladimir

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Mon, 19 Nov 2018 11:58:35 +0200

> How does it work? The AS issues a new refresh token with every refresh and invalidate the old one. This restricts the lifetime of a refresh token. If someone (might be the legit client or an attack…

This is a clever solution. Did you experience any false positives, e.g.
due to HTTP response timeouts on slow / poor connections?

We were also thinking of additionally binding the refresh token to the
end-user session at the AS / OP:

  * A valid refresh causing the session to be refreshed too
  * AS / OP logout or session expiration invalidating the refresh token

Vladimir

---

From: Hans Zandbelt <[email-masked]>
Date: Mon, 19 Nov 2018 11:03:04 +0100

+1 to the suggestions that Vladimir raises; I've seen a fair number of
requests  in the field for exactly that

Hans.

On Mon, Nov 19, 2018 at 10:59 AM Vladimir Dzhuvinov <[email-masked]>
wrote:

>    - A valid refresh causing the session to be refreshed too
>    - AS / OP logout or session expiration invalidating the refresh token
>
>
> Vladimir

-- 
[email-masked]
ZmartZone IAM - www.zmartzone.eu

---

From: Jim Manico <[email-masked]>
Date: Mon, 19 Nov 2018 16:18:25 +0545

I want to +1 this as well. This really got my attention as an impressive and straightforward defense technique.

Jim

> On Nov 19, 2018, at 3:48 PM, Hans Zandbelt <[email-masked]> wrote:
> 
> +1 to the suggestions that Vladimir raises; I've seen a fair number of requests  in the field for exactly that
> 
> Hans.
> 
>> On Mon, Nov 19, 2018 at 10:59 AM Vladimir Dzhuvinov <[email-masked]> wrote:
>> This is a clever solution. Did you experience any false positives, e.g. due to HTTP response timeouts on slow / poor connections?
>> 
>> We were also thinking of additionally binding the refresh token to the end-user session at the AS / OP:
>> 
>> A valid refresh causing the session to be refreshed too
>> AS / OP logout or session expiration invalidating the refresh token
>> 
>> 
>> Vladimir
>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 19 Nov 2018 16:36:57 +0100

You mean the binding between refresh tokens and sessions?

> Am 19.11.2018 um 11:03 schrieb Hans Zandbelt <[email-masked]>:
>

---

From: Aaron Parecki <[email-masked]>
Date: Mon, 19 Nov 2018 18:09:03 -0800

On Wed, Nov 7, 2018 at 7:20 AM Joseph Heenan <[email-masked]> wrote:

> devices now having embedded HSMs, we’ve seen increasing interest in mobile
> apps being dynamically (per-install) registered oauth2 private clients, and
> that model has a lot of advantages. (I’m not sure if we might see a similar
> model evolving for web apps.)
>

That's a great point, thanks. I've removed the reference to native apps
being public clients since it doesn't really add anything to this spec if I
have to caveat the description.

On Thu, Nov 15, 2018 at 12:58 PM Torsten Lodderstedt <
[email-masked]> wrote:

> > First of all the AS decides whether it issues refresh tokens or not.
> Having the ability does not mean the AS must do it. If you feel it’s safer
> to not do it. Fine.
> > Sure, and this should be mentioned then somewhere (either in the threats
> doc or in this proposed best practice doc). Not all end developers using
> these protocols fully understand the ramifications.

Thanks, I agree that this document should include some recommendations
around refresh token handling. Looking at the discussion in this thread, it
seems there are a few different strategies folks are taking. Since it seems
like there isn't a strong consensus, it sounds like this would be better
suited for the "Security Considerations" section, and to not make
MUST/SHOULD recommendations, but rather just point out the issues. Any
thoughts on that before I take a stab at writing something?

I've incorporated some of the other feedback here and published an updated
version:

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

Thanks for the feedback so far.

---
Aaron Parecki
https://aaronparecki.com

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 20 Nov 2018 20:39:16 +0100

Hi all, 

please find some thoughts about refresh token protection in the new revision of the Security BCP https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3.12

Feedback welcome!

kind regards,
Torsten. 

> Am 19.11.2018 um 11:33 schrieb Jim Manico <[email-masked]>:
> 
>> 	• A valid refresh causing the session to be refreshed too
>> 	• AS / OP logout or session expiration invalidating the refresh token
>> 
>> 
>> Vladimir
>>

---

From: George Fletcher <[email-masked]>
Date: Tue, 20 Nov 2018 17:00:19 -0500

+1

This model is useful and should be documented in its own right. Once 
documented it could possibly be referenced in the BCP.

On 11/9/18 1:44 PM, David Waite wrote:
> Others could correct me if I am wrong, but I believe the purpose of 
> this document is to recommend uses of other OAuth/OIDC specifications, 
> not to include its own technologies.
>
> In terms of being another spec to be referenced, I think it would be 
> useful but I wonder hypothetically how to best write that 
> specification. This method seems to be relying on standards-defined 
> tokens and converting them to an application server session, which 
> isn’t defined by behavior other than HTTP cookies. The session info 
> hook then lets you use those proprietary session tokens to retrieve 
> the access/id token.
>
> As such, it is closer to an architecture for implementing a client - 
> as a confidential client backend with an associated SPA frontend that 
> needs to make OAuth-protected calls. It is not describing the 
> communication between existing OAuth roles, such as between the client 
> and AS.
>
> There’s obvious value here, and it's one of several architectures for 
> browser-based apps using a confidential client rather than a public 
> one (another example being a reverse proxy which maps remote OAuth 
> endpoints into local, session-token-protected ones). I personally am 
> just not sure how you would define the communication between back-end 
> and front-end portions of the client in these architectures as a 
> standard within OAuth.
>
> -DW
>
>> On Nov 6, 2018, at 3:03 AM, Hans Zandbelt <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi Aaron, DW,
>>
>> would you consider including a recommendation about and the 
>> standardization of a "session info" endpoint (I'm open for better 
>> naming ;-)) as described in:
>> https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-page-applications/
>>
>> this approach is not just something that I cooked up; it is based on 
>> real world requests & deployments at Netflix and OAth.
>>

---

From: Hans Zandbelt <[email-masked]>
Date: Wed, 21 Nov 2018 08:08:08 +0100

I think of this as somewhat similar to:
a)  a grant type where a cookie grant is exchanged at an "RP token
endpoint" for an associated access and refresh token; the protocol between
SPA and the API to do so would benefit from standardization e.g. into SDKs
and server side frameworks
b) an "RP token introspection endpoint" where the cookie is introspected at
the RP and associated tokens are returned

if anyone comes up with a better name for this model and endpoint (and
probably less overloading of AS endpoint names...) and/or is willing to
help writing this down, please come forward and we'll pick it up on a new
thread/doc

Hans.

On Tue, Nov 20, 2018 at 11:00 PM George Fletcher <[email-masked]> wrote:

> Others could correct me if I am wrong, but I believe the purpose of this
> document is to recommend uses of other OAuth/OIDC specifications, not to
> include its own technologies.
>
> useful but I wonder hypothetically how to best write that specification.
> This method seems to be relying on standards-defined tokens and converting
> them to an application server session, which isn’t defined by behavior
> other than HTTP cookies. The session info hook then lets you use those
> proprietary session tokens to retrieve the access/id token.
>
> As such, it is closer to an architecture for implementing a client - as a
> confidential client backend with an associated SPA frontend that needs to
> make OAuth-protected calls. It is not describing the communication between
> existing OAuth roles, such as between the client and AS.
>
> browser-based apps using a confidential client rather than a public one
> (another example being a reverse proxy which maps remote OAuth endpoints
> into local, session-token-protected ones). I personally am just not sure
> how you would define the communication between back-end and front-end
> portions of the client in these architectures as a standard within OAuth.
>
> -DW
>
> standardization of a "session info" endpoint (I'm open for better naming
> ;-)) as described in:
>
> this approach is not just something that I cooked up; it is based on real
> world requests & deployments at Netflix and OAth.
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>

---

From: David Waite <[email-masked]>
Date: Wed, 21 Nov 2018 21:21:53 -0700

> On Nov 21, 2018, at 12:08 AM, Hans Zandbelt <[email-masked]> wrote:
> 
> a)  a grant type where a cookie grant is exchanged at an "RP token endpoint" for an associated access and refresh token; the protocol between SPA and the API to do so would benefit from standardization e.g. into SDKs and server side frameworks
> b) an "RP token introspection endpoint" where the cookie is introspected at the RP and associated tokens are returned
> 
> if anyone comes up with a better name for this model and endpoint (and probably less overloading of AS endpoint names...) and/or is willing to help writing this down, please come forward and we'll pick it up on a new thread/doc 

Hand waving follows :-)

This sounds like the RP environment as two pieces, a javascript application and back-end infrastructure. The RP infrastructure maintains local tokens which it derives from remote tokens issued by a single upstream AS/IdP, which it interacts with as a confidential client.

This RP infrastructure separately manages authentication/authorization for a javascript application. In this use case, this infrastructure allows the javascript application to get the access token issued by the upstream AS, so that the javascript application may then act as the client to interact with protected resources associated with that AS. (For protected resources within the RP environment, a separate local token is used for authorization; possibly a non-OAuth token such as the cookie)

The first requirement of access token exposure sounds like a fit for token exchange, with the RP exposing its own authorization service token endpoint for this purpose, and the javascript acting as a public client to the RP and not to the upstream OAuth AS. The “cookie token” would have a specific token type for this use case. Multiple exchanges would potentially return the same upstream access token, or could silently use the refresh token if needed to acquire and return a fresh access token.

In this scenario I would not expose the refresh token, as the javascript application should not have a direct relationship with the upstream AS, nor should it have credentials to perform the refresh.  Likewise, the id_token was addressed to the RP infrastructure and not the javascript application - I would expect authentication interactions to be between the RP infrastructure and the javascript application, indirectly based on the RP infrastructure’s relationship upstream service.

Once the javascript app has the access token, it should be able to use it to interact with a user info endpoint. This might be a RP user info endpoint, or the upstream user info endpoint, depending on RP requirements.

FWIW, if there are multiple upstream AS’s, I would expect the local RP environment to be a ‘full fledged’ AS issuing its own local access tokens, and to provide its own local protected resources which then may dispatch to the protected resources of the various upstream AS’s as needed. Everything above could be reused in this scenario, although you might just decide to have the local protected resources accept the cookie directly in addition to the local RP environment access tokens.

-DW

---

From: Brian Campbell <[email-masked]>
Date: Fri, 30 Nov 2018 15:43:11 -0700

> are the options available.

Unfortunately even when using the token endpoint, for SPA / in-browser
client applications, the potential mechanisms for sender/key-constraining
access tokens don't work very well or maybe don't work at all. So I don't
know that the recommendation is very realistic.