Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 19 Nov 2018 10:34:22 +0000

Hi all,

The authors of the OAuth Security Topics draft came to the conclusion that it is not possible to adequately secure the implicit flow against token injection since potential solutions like token binding or JARM are in an early stage of adoption. For this reason, and since CORS allows browser-based apps to send requests to the token endpoint, Torsten suggested to use the authorization code instead of the implicit grant in call cases in his presentation (see https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).

A hum in the room at IETF#103 concluded strong support for his recommendations. We would like to confirm the discussion on the list.

Please provide a response by December 3rd.

Ciao

Hannes & Rifaat

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: Mike Jones <[email-masked]>
Date: Mon, 19 Nov 2018 22:13:29 +0000

This description of the situation is an oversimplification.  OpenID Connect secures the implicit flow against token injection attacks by including the at_hash (access token hash) in the ID Token, enabling the client to validate that the access token was created by the issuer in the ID Token (which is also the OAuth Issuer, as described in RFC 8414<https://tools.ietf.org/html/rfc8414>).  (Note that this mitigation was described in draft-ietf-oauth-mix-up-mitigation<https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-01>.)

Given the prevalence of this known-good solution for securing the implicit flow, I would request that the draft be updated to describe this mitigation.  At the same time, I'm fine with the draft recommending the code flow over the implicit flow when this mitigation is not used.

                                                                Thank you,
                                                                -- Mike

From: OAuth <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Monday, November 19, 2018 2:34 AM
To: oauth <[email-masked]>
Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Hi all,

Ciao

Hannes & Rifaat

---

From: Aaron Parecki <[email-masked]>
Date: Mon, 19 Nov 2018 15:49:17 -0800

My understanding was that the scope of the discussion was limited to OAuth,
and does not cover OpenID Connect ID Tokens. With that in mind, I support
the recommendation to use the authorization code instead of the implicit
flow.

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

On Mon, Nov 19, 2018 at 2:13 PM Mike Jones <Michael.Jones=
[email-masked]> wrote:

> This description of the situation is an oversimplification.  OpenID
> Connect secures the implicit flow against token injection attacks by
> including the at_hash (access token hash) in the ID Token, enabling the
> client to validate that the access token was created by the issuer in the
> ID Token (which is also the OAuth Issuer, as described in RFC 8414
> <https://tools.ietf.org/html/rfc8414>).  (Note that this mitigation was
> described in draft-ietf-oauth-mix-up-mitigation
> <https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-01>.)
>
>
>
> Given the prevalence of this known-good solution for securing the implicit
> flow, I would request that the draft be updated to describe this
> mitigation.  At the same time, I’m fine with the draft recommending the
> code flow over the implicit flow when this mitigation is not used.
>
>
>
>                                                                 Thank you,
>
>                                                                 -- Mike
>
>
>
> *From:* OAuth <[email-masked]> *On Behalf Of * Hannes Tschofenig
> *Sent:* Monday, November 19, 2018 2:34 AM
> *To:* oauth <[email-masked]>
> *Subject:* [OAUTH-WG] OAuth Security Topics -- Recommend authorization
> code instead of implicit
>
>
>
> Hi all,
>
>
>
> The authors of the OAuth Security Topics draft came to the conclusion that
> it is not possible to adequately secure the implicit flow against token
> injection since potential solutions like token binding or JARM are in an
> early stage of adoption. For this reason, and since CORS allows
> browser-based apps to send requests to the token endpoint, Torsten
> suggested to use the authorization code instead of the implicit grant in
> call cases in his presentation (see
> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01
> ).
>
>
>
> A hum in the room at IETF#103 concluded strong support for his
> recommendations. We would like to confirm the discussion on the list.
>
>
>
> 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
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 20 Nov 2018 08:35:17 +0100

Hi Mike, 

I agree that OIDC hybrid flows offer additional security over the OAuth implicit grant and are used in the wild. On my slides and in the initial version of the new section, we had included the hybrid OIDC flows because of their known token injection countermeasures.

I nevertheless feel very uncomfortable to recommend those flows and any flow issuing access tokens in the front channel. In the course of the detailed review of the new text we realized two issues: 

1) Since the access token is exposed in the URL, such flows possess a significantly higher risk to leak the access token (e.g. through browser history, open redirection and even referrer headers) than the code grant.
2) There is no viable way to sender constrain access tokens issued in the front channel. Given the WG decided to recommend use of sender constraint tokens (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2.2), it seems contradictory to recommend response types not supporting such an approach. 

kind regards,
Torsten. 

> Am 19.11.2018 um 23:13 schrieb Mike Jones <Michael.Jones=[email-masked]>:
> 
> This description of the situation is an oversimplification.  OpenID Connect secures the implicit flow against token injection attacks by including the at_hash (access token hash) in the ID Token, enabling the client to validate that the access token was created by the issuer in the ID Token (which is also the OAuth Issuer, as described in RFC 8414).  (Note that this mitigation was described in draft-ietf-oauth-mix-up-mitigation.)
>  
> Given the prevalence of this known-good solution for securing the implicit flow, I would request that the draft be updated to describe this mitigation.  At the same time, I’m fine with the draft recommending the code flow over the implicit flow when this mitigation is not used.
>  
>                                                                 Thank you,
>                                                                 -- Mike
>  
> The authors of the OAuth Security Topics draft came to the conclusion that it is not possible to adequately secure the implicit flow against token injection since potential solutions like token binding or JARM are in an early stage of adoption. For this reason, and since CORS allows browser-based apps to send requests to the token endpoint, Torsten suggested to use the authorization code instead of the implicit grant in call cases in his presentation (seehttps://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).
>

---

From: Neil Madden <[email-masked]>
Date: Tue, 20 Nov 2018 12:24:55 +0000

I think the draft should elaborate more on what it means by “token replay” in section 2.2 and how the proposal to use sender-constrained tokens prevents it. As far as I can tell, of the 4 methods presented in section 3.8.1.2, only jpop signed requests actually includes any specific countermeasure for replay (in the form of negotiated nonces). 

If we are discussing this in the context of client-side web apps/SPAs, then surely the threat model includes malicious 3rd party scripts - for which neither token binding nor mTLS constrained tokens are very effective as those scripts run in the same TLS context as the legitimate client?

— Neil

> On 20 Nov 2018, at 07:35, Torsten Lodderstedt <[email-masked]> wrote:
> 
> Hi Mike, 
>

---

From: John Bradley <[email-masked]>
Date: Tue, 20 Nov 2018 12:47:22 -0300

Yes the at_hash protects the client from accepting an injected AT.

Unfortunately it doesn't do anything to protect against leakage in logs 
or redirects.

So without the AT using some sort of POP mechanism it is hard to say 
sending it in a redirect is a good security practice.

John B.

On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:
> 2) There is no viable way to sender constrain access tokens issued in the front channel. Given the WG decided to recommend use of sender constraint tokens (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2), it seems contradictory to recommend response types not supporting such an approach.
>
> kind regards,
> Torsten.
>

---

From: Mike Jones <[email-masked]>
Date: Tue, 20 Nov 2018 21:00:32 +0000

Next question – doesn’t using the Form Post Response Mode https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html mitigate the threats you’re describing below John?  If so, I believe the Security Topics draft should say this.

I believe we owe it to readers to present the complete picture, which is why I believe that describing profiles using ID Tokens and the Form Post Response Mode are in scope.

                                                       -- Mike

From: OAuth <[email-masked]> On Behalf Of John Bradley
Sent: Tuesday, November 20, 2018 7:47 AM
To: [email-masked]
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Unfortunately it doesn't do anything to protect against leakage in logs or redirects.

So without the AT using some sort of POP mechanism it is hard to say sending it in a redirect is a good security practice.

John B.

Hi Mike,

kind regards,

Torsten.

Am 19.11.2018 um 23:13 schrieb Mike Jones <Michael.Jones=[email-masked]><mailto:Michael.Jones=[email-masked]>:

                                                                Thank you,

                                                                -- Mike

From: OAuth <[email-masked]><mailto:[email-masked]> On Behalf Of Hannes Tschofenig

To: oauth <[email-masked]><mailto:[email-masked]>

Hi all,

Ciao

Hannes & Rifaat

OAuth mailing list

[email-masked]<mailto:[email-masked]>

OAuth mailing list

[email-masked]<mailto:[email-masked]>

---

From: George Fletcher <[email-masked]>
Date: Tue, 20 Nov 2018 16:40:33 -0500

Hi Mike,

The Form Post Response Mode keeps the access_token out of the URL, but 
it doesn't prevent the token from traversing through the browser. So a 
man-in-the-browser attack may be able to intercept the values. It should 
help with leakage in logs.

Thanks,
George

On 11/20/18 4:00 PM, Mike Jones wrote:
>
> Next question – doesn’t using the Form Post Response Mode 
> https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html 
> mitigate the threats you’re describing below John?  If so, I believe 
> the Security Topics draft should say this.
>
> I believe we owe it to readers to present the complete picture, which 
> is why I believe that describing profiles using ID Tokens and the Form 
> Post Response Mode are in scope.
>
> -- Mike
>
> *From:* OAuth <[email-masked]> *On Behalf Of * John Bradley
> *Sent:* Tuesday, November 20, 2018 7:47 AM
> *To:* [email-masked]
> *Subject:* Re: [OAUTH-WG] OAuth Security Topics -- Recommend 
> authorization code instead of implicit
>
>         Am 19.11.2018 um 23:13 schrieb Mike Jones<Michael.Jones=[email-masked]>
>         <mailto:Michael.Jones=[email-masked]>:
>
>         From: OAuth<[email-masked]> <mailto:[email-masked]>  On Behalf Of Hannes Tschofenig
>
>         To: oauth<[email-masked]> <mailto:[email-masked]>
>
>         [email-masked] <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: John Bradley <[email-masked]>
Date: Tue, 20 Nov 2018 19:29:15 -0300

Post response works OK for server based clients.  I don't think POST works
for single page applications.

Basically that would be something more like postmessage between two JS
apps.

Postmessage also has security issues passing a access token and leaking.

Perhaps someone more familiar with SPA can comment on POST.

John B.

On Tue, Nov 20, 2018, 6:40 PM George Fletcher <[email-masked] wrote:

> Hi Mike,
>
> The Form Post Response Mode keeps the access_token out of the URL, but it
> doesn't prevent the token from traversing through the browser. So a
> mitigate the threats you’re describing below John?  If so, I believe the
> Security Topics draft should say this.
>
>
>
> I believe we owe it to readers to present the complete picture, which is
> why I believe that describing profiles using ID Tokens and the Form Post
> Response Mode are in scope.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* OAuth <[email-masked]> <[email-masked]> *On
> Behalf Of * John Bradley
> Am 19.11.2018 um 23:13 schrieb Mike Jones <Michael.Jones=[email-masked]> <Michael.Jones=[email-masked]>:
>
>
>
>  From: OAuth <[email-masked]> <[email-masked]> On Behalf Of Hannes Tschofenig
>
> To: oauth <[email-masked]> <[email-masked]>
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>

---

From: Daniel Fett <[email-masked]>
Date: Wed, 21 Nov 2018 09:26:19 +0100

> If we are discussing this in the context of client-side web apps/SPAs, then surely the threat model includes malicious 3rd party scripts - for which neither token binding nor mTLS constrained token…

Please correct me if I'm wrong, but if a page/SPA/origin includes a
malicious third party script, the third party script can access all data
of that JavaScript. It can exfiltrate tokens and/or send requests on
behalf of that page/SPA/origin (using the page/SPA/origin's TLS context,
cookies, etc.).

So I doubt that there is any better solution than token binding or mTLS.

If we assume that an SPA includes a malicious third party script, it is
completely compromised.

-Daniel

---

From: Neil Madden <[email-masked]>
Date: Wed, 21 Nov 2018 08:34:54 +0000

> On 21 Nov 2018, at 08:26, Daniel Fett <[email-masked]> wrote:
> 
> Please correct me if I'm wrong, but if a page/SPA/origin includes a malicious third party script, the third party script can access all data of that JavaScript. It can exfiltrate tokens and/or send requests on behalf of that page/SPA/origin (using the page/SPA/origin's TLS context, cookies, etc.). 
> 
> If we assume that an SPA includes a malicious third party script, it is completely compromised.
> 

No - same origin policy prevents those things. TLS doesn’t have those protections though because it acts at the transport layer and SOP is an application-layer concept. 

— Neil

---

From: Daniel Fett <[email-masked]>
Date: Wed, 21 Nov 2018 09:39:31 +0100

Am 21.11.18 um 09:34 schrieb Neil Madden:
> On 21 Nov 2018, at 08:26, Daniel Fett <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> malicious third party script, the third party script can access all
>> data of that JavaScript. It can exfiltrate tokens and/or send
>> requests on behalf of that page/SPA/origin (using the
>> page/SPA/origin's TLS context, cookies, etc.).
>>
> No - same origin policy prevents those things. TLS doesn’t have those
> protections though because it acts at the transport layer and SOP is
> an application-layer concept.

If a page from origin A includes a third-party script from origin B,
that external script runs in origin A and has access to all cookies and
the JavaScript context of the page.

The SPA from origin A would be compromised. That is why we need things
such as Subresource Integrity.

-Daniel

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 21 Nov 2018 09:47:49 +0100

We had a discussion about this topic on Twitter https://twitter.com/Apl3b/status/1064854507606208513

Outcome is POST requires a backend to receive the request so it’s not a viable solution for SPAs.

> Am 20.11.2018 um 23:29 schrieb John Bradley <[email-masked]>:
> 
> Post response works OK for server based clients.  I don't think POST works for single page applications.  
> 
> Basically that would be something more like postmessage between two JS apps.  
> 
> The Form Post Response Mode keeps the access_token out of the URL, but it doesn't prevent the token from traversing through the browser. So a man-in-the-browser attack may be able to intercept the values. It should help with leakage in logs.
> 
> Thanks,
> George
> 
>> This description of the situation is an oversimplification..  OpenID Connect secures the implicit flow against token injection attacks by including the at_hash (access token hash) in the ID Token, enabling the client to validate that the access token was created by the issuer in the ID Token (which is also the OAuth Issuer, as described in RFC 8414).  (Note that this mitigation was described in draft-ietf-oauth-mix-up-mitigation.)
>>

---

From: Neil Madden <[email-masked]>
Date: Wed, 21 Nov 2018 09:09:03 +0000

On 21 Nov 2018, at 08:39, Daniel Fett <[email-masked]> wrote:
> If a page from origin A includes a third-party script from origin B, that external script runs in origin A and has access to all cookies and the JavaScript context of the page.
> 
> The SPA from origin A would be compromised. That is why we need things such as Subresource Integrity.

I think we’re talking about different things. I am talking about scripts from places like ad servers that are usually included via an iframe to enforce the SOP and sandbox them from other scripts. If they get access to an access token - e.g. via document.referrer or a redirect or some other leak, then they still act within the same TLS context as the legitimate client.

— Neil

---

From: Daniel Fett <[email-masked]>
Date: Wed, 21 Nov 2018 10:25:49 +0100

> I think we’re talking about different things. I am talking about scripts from places like ad servers that are usually included via an iframe to enforce the SOP and sandbox them from other scripts.…

Thanks for the clarification! I see that you highlight an important
point there.

The protection that would be required essentially boils down to
something similar to a CSRF protection for the resource server.

Luckily, CORS covers this: You can't set the Authorization header
cross-origin unless the appropriate CORS headers are set. So while the
third party origin would be able to send a request through the browser
using the TLS context, it would not be able to attach the access token.
(Unless, of course, that third party origin is whitelisted, or if the
bearer token is sent in a different way, e.g., as a URL parameter.)

As a side note, interestingly, this would leave an authorization code
unprotected, if the sender authentication would be mTLS or token
binding. PKCE on the other hand is fine.

---

From: Neil Madden <[email-masked]>
Date: Wed, 21 Nov 2018 10:01:49 +0000

> On 21 Nov 2018, at 09:25, Daniel Fett <[email-masked]> wrote:
> 
> Thanks for the clarification! I see that you highlight an important point there.
> 
> The protection that would be required essentially boils down to something similar to a CSRF protection for the resource server.
> 
> Luckily, CORS covers this: You can't set the Authorization header cross-origin unless the appropriate CORS headers are set. So while the third party origin would be able to send a request through the browser using the TLS context, it would not be able to attach the access token. (Unless, of course, that third party origin is whitelisted, or if the bearer token is sent in a different way, e.g., as a URL parameter.)

Right. But two points here:

Firstly, this assumes the access token is actually passed in an Authorization header and not just sent in a URL parameter or a CORS-safe form POST body (e.g. application/x-www-form-urlencoded). This should probably be its own security best practice recommendation, but I haven’t seen it anywhere. I think most REST APIs already do this following RFC 6750, but we should spell out that it has security benefits.

Secondly, this means that we are relying on something other than (TLS-based) sender-constrained access tokens to prevent this, so we should clarify that in the document.

> 
> As a side note, interestingly, this would leave an authorization code unprotected, if the sender authentication would be mTLS or token binding. PKCE on the other hand is fine.

Right - that’s why I am glad to see the security topics draft recommending PKCE in all cases.

Why is PKCE so effective? In my opinion, you can view PKCE as a one-time PoP scheme for the auth code - you prove possession of the secret to the AS by simply giving it the secret along with the auth code. You could do something similar with the implicit flow, but I won’t share that scheme here as I am happy for the implicit flow to die ;-)

— Neil

---

From: Daniel Fett <[email-masked]>
Date: Wed, 21 Nov 2018 11:06:49 +0100

> Firstly, this assumes the access token is actually passed in an Authorization header and not just sent in a URL parameter or a CORS-safe form POST body (e.g. application/x-www-form-urlencoded). Thi…

Exactly what I thought. I will prepare a proposal for the security BCP.

-Daniel

---

From: George Fletcher <[email-masked]>
Date: Wed, 21 Nov 2018 08:24:01 -0500

An SPA has a backend because it has to be loaded from somewhere :)

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 22 Nov 2018 05:44:23 +0100

that’s certainly true, but that might by a web server with static content only.

If the server is a real backend, there is even less reasons to use a implicit or hybrid. No even a performance gain in comparison to code.

> Am 21.11.2018 um 14:24 schrieb George Fletcher <[email-masked]>:
>

---

From: Hans Zandbelt <[email-masked]>
Date: Sun, 25 Nov 2018 12:55:07 +0100

I strongly support the recommendation of using code instead of implicit. I
do so based on my own experience in the field [1] and stick to that also
after reading the comments and (what I would call) workarounds on this
thread.

Hans.

[1]
https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-page-applications/

On Thu, Nov 22, 2018 at 5:45 AM Torsten Lodderstedt <[email-masked]>
wrote:

> If the server is a real backend, there is even less reasons to use a
> implicit or hybrid. No even a performance gain in comparison to code.
>
> Am 21..11.2018 um 14:24 schrieb George Fletcher <[email-masked]
> <gffletch@aol..com>>:
>
> Am 20.11.2018 um 23:29 schrieb John Bradley <[email-masked]> <[email-masked]>:
>
> From: OAuth <[email-masked]> <[email-masked]> On Behalf Of John Bradley
> [email-masked]://www.ietf.org/mailman/listinfo/oauth
>

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 25 Nov 2018 18:32:53 +0100

Hi all, 

I would like to state again what the proposal of the authors of the Security BCP is:

Here is the respective text from the draft:

——

2.1.2.  Implicit Grant

   The implicit grant (response type "token") and other response types
   causing the authorization server to issue access tokens in the
   authorization response are vulnerable to access token leakage and
   access token replay as described in Section 3.1, Section 3.2, Section 3.3, and Section 3.6.

   Moreover, no viable mechanism exists to cryptographically bind access
   tokens issued in the authorization response to a certain client as it
   is recommended in Section 2.2.  This makes replay detection for such
   access tokens at resource servers impossible.

   In order to avoid these issues, Clients SHOULD NOT use the implicit
   grant or any other response type causing the authorization server to
   issue an access token in the authorization response.

   Clients SHOULD instead use the response type "code" (aka
   authorization code grant type) as specified in Section 2.1.1 or any
   other response type that causes the authorization server to issue
   access tokens in the token response.  This allows the authorization
   server to detect replay attempts and generally reduces the attack
   surface since access tokens are not exposed in URLs.  It also allows
   the authorization server to sender-constrain the issued tokens.
——

In my observation, discouraging implicit seems to be the less controversial issue.

„or any other response type causing the authorization server to issue an access token in the authorization response.“ in the 3rd paragraph caused discussions because it suggests to discourage developers from using ANY response type issuing access tokens in the authorization response. This includes OIDC’s response types „token id_token“, „code token“ & „code token id_token“, where at least  „token id_token“ is used in the wild to implement SPAs.

Why did we come up with this proposal given at least „token id_token“ & „code token id_token“ protect against injection?

Two reasons: 

1) „token id_token“ does not support sender constrained tokens. Also use of refresh tokens to frequently issue new live-time and privilege restricted access tokens is not supported. „code token id_token“ seems more complex than just „code“+pkce for achieving the same goal.

2) Protection against token leakage is rather thin and fragile. There is just a single line of defense (CSP, open redirection prevention, browser history manipulation) implemented by the client. 

Daniel and I collected some more information and argument at https://github.com/tlodderstedt/oauth2_spa/blob/master/README.md that you might like to give a read.

My conclusion after 2 weeks of intensive discussions with SPA developers (mostly on twitter): code+pkce is the more secure, simpler, and more versatile approach to (also) implement SPAs. I prefer to approach developers with a clean and robust message instead of a lengthy description of what needs to go right in order to secure a SPA using OAuth. That’s why I think code+pkce should be the recommendation of our working group.

So please vote in favor of our proposal. I think that’s a huge improvement for OAuth.

kind regards, 
Torsten. 

> Am 25.11.2018 um 12:55 schrieb Hans Zandbelt <[email-masked]>:
> 
> I strongly support the recommendation of using code instead of implicit. I do so based on my own experience in the field [1] and stick to that also after reading the comments and (what I would call) workarounds on this thread.
> 
> Hans.
> 
> [1] https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-page-applications/
> 
> On Thu, Nov 22, 2018 at 5:45 AM Torsten Lodderstedt <[email-masked]> wrote:
> Am 21..11.2018 um 14:24 schrieb George Fletcher <[email-masked]>:
> 
>>>> On Tue, Nov 20, 2018, 6:40 PM George Fletcher <
>>>> [email-masked]
>>>>  wrote:
>>>> Hi Mike,
>>>> 
>>>>> Next question – doesn’t using the Form Post Response Mode https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
>>>>>  mitigate the threats you’re describing below John?  If so, I believe the Security Topics draft should say this.
>>>>> 
>>>>>  
>>>>> 
>>>>> From: OAuth 
>>>>> <[email-masked]>
>>>>>  On Behalf Of John Bradley
>>>>> To: 
>>>>> [email-masked]
>>>>> 2) There is no viable way to sender constrain access tokens issued in the front channel. Given the WG decided to recommend use of sender constraint tokens (
>>>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2
>>>>> ), it seems contradictory to recommend response types not supporting such an approach. 
>>>>>  
>>>>> kind regards,
>>>>> Torsten. 
>>>>>  
>>>>> Am 19.11.2018 um 23:13 schrieb Mike Jones 
>>>>> <Michael.Jones=[email-masked]>
>>>>> :
>>>>>  
>>>>> From: OAuth 
>>>>> <[email-masked]>
>>>>>  On Behalf Of Hannes Tschofenig
>>>>> The authors of the OAuth Security Topics draft came to the conclusion that it is not possible to adequately secure the implicit flow against token injection since potential solutions like token binding or JARM are in an early stage of adoption. For this reason, and since CORS allows browser-based apps to send requests to the token endpoint, Torsten suggested to use the authorization code instead of the implicit grant in call cases in his presentation (seehttps://
>>>>> datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01
>>>>> ).
>>>>>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 25 Nov 2018 13:22:44 -0500

Hi Torsten,

I am assuming that these recommendations are mainly for Public Clients, not
Confidential Clients; is that correct?

Regards,
 Rifaat

On Sun, Nov 25, 2018 at 12:33 PM Torsten Lodderstedt <
[email-masked]> wrote:

> „or any other response type causing the authorization server to issue an
> access token in the authorization response.“ in the 3rd paragraph caused
> discussions because it suggests to discourage developers from using ANY
> response type issuing access tokens in the authorization response. This
> includes OIDC’s response types „token id_token“, „code token“ & „code token
> id_token“, where at least  „token id_token“ is used in the wild to
> implement SPAs.
>
> Why did we come up with this proposal given at least „token id_token“ &
> „code token id_token“ protect against injection?
>
> Two reasons:
>
> 1) „token id_token“ does not support sender constrained tokens. Also use
> of refresh tokens to frequently issue new live-time and privilege
> restricted access tokens is not supported. „code token id_token“ seems more
> complex than just „code“+pkce for achieving the same goal.
>
> 2) Protection against token leakage is rather thin and fragile. There is
> just a single line of defense (CSP, open redirection prevention, browser
> history manipulation) implemented by the client.
>
> Daniel and I collected some more information and argument at
> https://github.com/tlodderstedt/oauth2_spa/blob/master/README.md that you
> might like to give a read.
>
> My conclusion after 2 weeks of intensive discussions with SPA developers
> (mostly on twitter): code+pkce is the more secure, simpler, and more
> versatile approach to (also) implement SPAs. I prefer to approach
> developers with a clean and robust message instead of a lengthy description
> of what needs to go right in order to secure a SPA using OAuth. That’s why
> I think code+pkce should be the recommendation of our working group.
>
> > Am 25.11.2018 um 12:55 schrieb Hans Zandbelt <[email-masked]
> >:
> >
> > I strongly support the recommendation of using code instead of implicit.
> I do so based on my own experience in the field [1] and stick to that also
> >>> We had a discussion about this topic on Twitter
> https://twitter.com/Apl3b/status/1064854507606208513
> >>>
> >>>
> >>>> The Form Post Response Mode keeps the access_token out of the URL,
> but it doesn't prevent the token from traversing through the browser. So a
> >>>>>  mitigate the threats you’re describing below John?  If so, I
> believe the Security Topics draft should say this.
> >>>>>
> >>>>>
> >>>>>
> >>>>> I believe we owe it to readers to present the complete picture,
> which is why I believe that describing profiles using ID Tokens and the
> Form Post Response Mode are in scope.
> >>>>>
> >>>>>
> >>>>>
> >>>>>                                                        -- Mike
> >>>>>
> >>>>>
> >>>>>
> >>>>> From: OAuth
> >>>>> <[email-masked]>
> >>>>> I agree that OIDC hybrid flows offer additional security over the
> OAuth implicit grant and are used in the wild. On my slides and in the
> initial version of the new section, we had included the hybrid OIDC flows
> because of their known token injection countermeasures.
> >>>>>
> >>>>> I nevertheless feel very uncomfortable to recommend those flows and
> any flow issuing access tokens in the front channel. In the course of the
> detailed review of the new text we realized two issues:
> >>>>>
> >>>>> 1) Since the access token is exposed in the URL, such flows possess
> a significantly higher risk to leak the access token (e.g. through browser
> history, open redirection and even referrer headers) than the code grant.
> >>>>> 2) There is no viable way to sender constrain access tokens issued
> in the front channel. Given the WG decided to recommend use of sender
> constraint tokens (
> >>>>>
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2...2
> >>>>> This description of the situation is an oversimplification..  OpenID
> ID Token (which is also the OAuth Issuer, as described in RFC 8414).  (Note
> that this mitigation was described in draft-ietf-oauth-mix-up-mitigation.)
> >>>>>
> >>>>> Given the prevalence of this known-good solution for securing the
> implicit flow, I would request that the draft be updated to describe this
> Mike
> >>>>> The authors of the OAuth Security Topics draft came to the
> conclusion that it is not possible to adequately secure the implicit flow
> against token injection since potential solutions like token binding or
> JARM are in an early stage of adoption. For this reason, and since CORS
> allows browser-based apps to send requests to the token endpoint, Torsten
> call cases in his presentation (seehttps://
> >>>>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 25 Nov 2018 19:41:31 +0100

Hi Rifaat,

this is a recommendation to anyone using implicit now. Implicit can only be used with public clients, so one could interpret it that way. I could also envision a SPA to use a backend, which in turn is a confidential client. There were some posts about this topic on the list recently. 

Does this answer your question?

kind regards,
Torsten. 

> Am 25.11.2018 um 19:22 schrieb Rifaat Shekh-Yusef <[email-masked]>:
> 
> Hi Torsten,
> 
> I am assuming that these recommendations are mainly for Public Clients, not Confidential Clients; is that correct?
> 
> Regards,
>  Rifaat
> 
> 
> On Sun, Nov 25, 2018 at 12:33 PM Torsten Lodderstedt <[email-masked]> wrote:
> Hi all, 
>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 25 Nov 2018 14:55:21 -0500

RFC6749, Section 3.1.2.2, implies that Implicit is not limited to public
clients:

3.1.2.2 <https://tools.ietf.org/html/rfc6749#section-3.1.2.2>.
Registration Requirements

   The authorization server MUST require the following clients to

   register their redirection endpoint:

   o  Public clients.

*   o  Confidential clients utilizing the implicit grant type.*

I do not know if anybody is using Implicit with Confidential clients, but
just in case, you might want to make it clear that your recommendations are
specifically for public clients.

Regards,
 Rifaat

On Sun, Nov 25, 2018 at 1:41 PM Torsten Lodderstedt <[email-masked]>
wrote:

> Hi Rifaat,
>
> this is a recommendation to anyone using implicit now. Implicit can only
> be used with public clients, so one could interpret it that way. I could
> also envision a SPA to use a backend, which in turn is a confidential
> client. There were some posts about this topic on the list recently.
>
> > Am 25.11.2018 um 19:22 schrieb Rifaat Shekh-Yusef <[email-masked]
> >:
> >
> > Hi Torsten,
> >
> > I am assuming that these recommendations are mainly for Public Clients,
> not Confidential Clients; is that correct?
> >
> > Regards,
> >  Rifaat
> >
> >
> > > I strongly support the recommendation of using code instead of
> implicit. I do so based on my own experience in the field [1] and stick to
> that also after reading the comments and (what I would call) workarounds on
> this thread.
> > >
> > > Hans.
> > >
> > > [1]
> > >>>>> So without the AT using some sort of POP mechanism it is hard to
> say sending it in a redirect is a good security practice.
> > >>>>>
> > >>>>> John B.
> > >>>>>
> > >>>>> I nevertheless feel very uncomfortable to recommend those flows
> and any flow issuing access tokens in the front channel. In the course of
> the detailed review of the new text we realized two issues:
> > >>>>>
> > >>>>> 1) Since the access token is exposed in the URL, such flows
> possess a significantly higher risk to leak the access token (e.g. through
> browser history, open redirection and even referrer headers) than the code
> grant.
> > >>>>> This description of the situation is an oversimplification..
> OpenID Connect secures the implicit flow against token injection attacks by
> > >>>>> IMPORTANT NOTICE: The contents of this email and any attachments
> are confidential and may also be privileged. If you are not the intended

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 25 Nov 2018 21:15:20 +0100

as I said, it’s a recommendation for anyone using the implicit now. If there are confidential clients out there using implicit (I don’t think there are), it is applicable to them as well. 

> Am 25.11.2018 um 20:55 schrieb Rifaat Shekh-Yusef <[email-masked]>:
> 
> RFC6749, Section 3.1.2.2, implies that Implicit is not limited to public clients:
> 
> 3.1.2.2.  Registration Requirements
>    o  Confidential clients utilizing the implicit grant type.
> 
> 
> I do not know if anybody is using Implicit with Confidential clients, but just in case, you might want to make it clear that your recommendations are specifically for public clients.
> 
> Regards,
>  Rifaat
> 
> 
> 
> 
>> On Sun, Nov 25, 2018 at 1:41 PM Torsten Lodderstedt <[email-masked]> wrote:
>> Hi Rifaat,
>>

---

From: John Bradley <[email-masked]>
Date: Sun, 25 Nov 2018 17:55:41 -0300

There is no such thing as a implicit confidential client.

Implicit clients are not authenticated, so are not confidential.

You could have a hybrid client using the "code token" response type that is
confidential for the code flow but i don't think anyone would consider the
token returned from the authorization endpoint as confidential.

That should have been hybrid rather than confidential I suspect.  Perhaps a
errata could be looked at.

John B.

On Sun, Nov 25, 2018, 4:55 PM Rifaat Shekh-Yusef <[email-masked]
wrote:

> 3.1.2.2 <https://tools.ietf.org/html/rfc6749#section-3.1.2.2>.  Registration Requirements
>
> *   o  Confidential clients utilizing the implicit grant type..*
>
>
>
>> > „or any other response type causing the authorization server to issue
>> an access token in the authorization response.“ in the 3rd paragraph caused
>> > 1) „token id_token“ does not support sender constrained tokens. Also
>> use of refresh tokens to frequently issue new live-time and privilege
>> > 2) Protection against token leakage is rather thin and fragile. There
>> is just a single line of defense (CSP, open redirection prevention, browser
>> https://github.com/tlodderstedt/oauth2_spa/blob/master/README.md that
>> you might like to give a read.
>> >
>> > My conclusion after 2 weeks of intensive discussions with SPA
>> developers (mostly on twitter): code+pkce is the more secure, simpler, and
>> more versatile approach to (also) implement SPAs. I prefer to approach
>> > >>>>> 2) There is no viable way to sender constrain access tokens
>> issued in the front channel. Given the WG decided to recommend use of
>> sender constraint tokens (
>> > >>>>>
>> > >>>>> <Michael.Jones=[email-masked]
>> <[email-masked]>>
>> > >>>>> :
>> > >>>>>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sun, 25 Nov 2018 16:43:44 -0500

Thanks John!

Would you be able to create a new errata report about this?

Regards,
 Rifaat

On Sun, Nov 25, 2018 at 3:55 PM John Bradley <[email-masked]> wrote:

> You could have a hybrid client using the "code token" response type that
> is confidential for the code flow but i don't think anyone would consider
> the token returned from the authorization endpoint as confidential.
>
> That should have been hybrid rather than confidential I suspect.  Perhaps
> a errata could be looked at.
>
> John B.
>
>
>>> > I am assuming that these recommendations are mainly for Public
>>> Clients, not Confidential Clients; is that correct?
>>> >
>>> > Regards,
>>> >  Rifaat
>>> >
>>> >
>>> > Why did we come up with this proposal given at least „token id_token“
>>> & „code token id_token“ protect against injection?
>>> >
>>> > Two reasons:
>>> >
>>> > >>>> The Form Post Response Mode keeps the access_token out of the
>>> URL, but it doesn't prevent the token from traversing through the browser.
>>> So a man-in-the-browser attack may be able to intercept the values. It
>>> should help with leakage in logs.
>>> > >>>>
>>> > >>>> Thanks,
>>> > >>>> George
>>> > >>>>
>>> > >>>>> I agree that OIDC hybrid flows offer additional security over
>>> the OAuth implicit grant and are used in the wild. On my slides and in the
>>> > >>>>> Given the prevalence of this known-good solution for securing
>>> the implicit flow, I would request that the draft be updated to describe
>>> this mitigation.  At the same time, I’m fine with the draft recommending
>>> the code flow over the implicit flow when this mitigation is not used.
>>> > >>>>>
>>> > >>>>>
>>>  Thank you,
>>> > >>>>>
>>>  -- Mike
>>> > >>>>>
>>> > >>>>> From: OAuth
>>> > >>>>> <[email-masked]>

---

From: Antonio Sanso <[email-masked]>
Date: Mon, 26 Nov 2018 08:18:11 +0000

Hi Torsten,

nice one. FWIW I am reallly happy to see this happening.

Quick question though. What is the recommendation about dealing with the client secret in this situation?

regards

antonio

________________________________
From: OAuth <[email-masked]> on behalf of Torsten Lodderstedt <[email-masked]>
Sent: Sunday, November 25, 2018 6:32:53 PM
To: [email-masked]
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Hi all,

——

2.1.2.  Implicit Grant

Two reasons:

kind regards,
Torsten.

> ZmartZone IAM - www.zmartzone.eu<http://www.zmartzone.eu>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 26 Nov 2018 10:34:40 +0100

Hi Antonio,

good point. I would assume most SPAs will be public clients. Even if a single instance registers dynamically and obtains a secret, this secret can only be used as kind of „same originator“ proof (much like PKCE). SPAs with a backend can also make the backend a confidential client. There was a thread about SPAs & backends on the list recently.

I would argue this is inline with RFC6749 security considerations. Do you see a need to add this to the BCP?

kind regards,
Torsten.

> Am 26.11.2018 um 09:18 schrieb Antonio Sanso <[email-masked]>:
> 
> Hi Torsten,
>

---

From: Antonio Sanso <[email-masked]>
Date: Mon, 26 Nov 2018 09:38:02 +0000

Hi Torsten, thanks it makes sense.

> Do you see a need to add this to the BCP?

Well, while you are on it this might be a good chance to include this IMHO. At least it will be a pointer for a question that might pop up quite often.

Regards

antonio

From: Torsten Lodderstedt <[email-masked]>
Date: Monday, November 26, 2018 at 10:34 AM
To: Antonio Sanso <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Hi Antonio,

kind regards,
Torsten.

Am 26.11.2018 um 09:18 schrieb Antonio Sanso <[email-masked]<mailto:[email-masked]>>:

Hi Torsten,

regards

antonio

________________________________
From: OAuth <[email-masked]<mailto:[email-masked]>> on behalf of Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, November 25, 2018 6:32:53 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Hi all,

——

2.1.2.  Implicit Grant

Two reasons:

kind regards,
Torsten.

> Am 25.11.2018 um 12:55 schrieb Hans Zandbelt <[email-masked]<mailto:[email-masked]>>:
>
> On Thu, Nov 22, 2018 at 5:45 AM Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:
> Am 21..11.2018 um 14:24 schrieb George Fletcher <[email-masked]<mailto:[email-masked]>>:
>
>>>> Am 20.11.2018 um 23:29 schrieb John Bradley <[email-masked]<mailto:[email-masked]>>
>>>> :
>>>>
>>>> [email-masked]<mailto:[email-masked]>
>>>>  wrote:
>>>> Hi Mike,
>>>>
>>>>> <[email-masked]<mailto:[email-masked]>>
>>>>> [email-masked]<mailto:[email-masked]>
>>>>>
>>>>> <Michael.Jones=[email-masked]<mailto:Michael.Jones=[email-masked]>>
>>>>> :
>>>>>
>>>>> <[email-masked]<mailto:[email-masked]>>
>>>>> To: oauth
>>>>> <[email-masked]<mailto:[email-masked]>>
>>>>>
>>>>> datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01<http://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01>
>>>>> ).
>>>>>
> [email-masked]<mailto:[email-masked]>

---

From: George Fletcher <[email-masked]>
Date: Mon, 26 Nov 2018 09:08:25 -0500

> That’s why I think code+pkce should be the recommendation of our 
working group.

I am in favor of this recommendation for OAuth2 implementations.

On 11/25/18 12:32 PM, Torsten Lodderstedt wrote:
>>>>>> <[email-masked]>

---

From: n-sakimura <[email-masked]>
Date: Tue, 27 Nov 2018 08:10:08 +0000

I am not sure about it. There are no confidential implicit grant client that uses bearer token is correct, but if the token is sender constrained, it can act as a confidential client.

Think of the case where an OP that is unreacheable directly from the client but only indirectly through the browser, e.g., Self-Issued OP and AS that are behind the corporate firewall. Then, such OP/AS can return a sender constrained token to the full confidential client that can use its keys to authenticate against the resource server when using the sender constrained access token. I categorize it as a confidential client.

So, IMHO, Rifaat’s point is correct.

Nat

From: OAuth <[email-masked]> On Behalf Of John Bradley
Sent: Monday, November 26, 2018 5:56 AM
To: Rifaat Shekh-Yusef <[email-masked]>
Cc: IETF oauth WG <[email-masked]>
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

You could have a hybrid client using the "code token" response type that is confidential for the code flow but i don't think anyone would consider the token returned from the authorization endpoint as confidential.

That should have been hybrid rather than confidential I suspect.  Perhaps a errata could be looked at.

John B.

On Sun, Nov 25, 2018, 4:55 PM Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]> wrote:
RFC6749, Section 3.1.2.2, implies that Implicit is not limited to public clients:

3.1.2.2<https://tools.ietf.org/html/rfc6749#section-3.1.2.2>.  Registration Requirements

   o  Public clients.

   o  Confidential clients utilizing the implicit grant type...

Regards,
 Rifaat

On Sun, Nov 25, 2018 at 1:41 PM Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:
Hi Rifaat,

kind regards,
Torsten.

> Am 25.11.2018 um 19:22 schrieb Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>>:
>
> Hi Torsten,
>
> On Sun, Nov 25, 2018 at 12:33 PM Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:
> Hi all,
>
> >>>>> <Michael.Jones=[email-masked]<mailto:[email-masked]>>
> >>>>> :
> >>>>>

---

From: Neil Madden <[email-masked]>
Date: Tue, 27 Nov 2018 09:53:53 +0000

> Please provide a response by December 3rd.

ForgeRock are in favour of deprecating the implicit flow in favour of the authorization code flow as suggested.

In our opinion, it is more secure and more consistent to prefer the authorization code in all such cases.

Kind regards,

Neil Madden
Security Director, ForgeRock Engineering

---

From: Jim Manico <[email-masked]>
Date: Tue, 27 Nov 2018 18:51:26 +0530

Manicode Security is strongly in favor of deprecating the implicit flow in favor of the authorization code flow as suggested by this recommendation.

We're also eager to see secure implementations for SPA delegation be clarified by the working group as well.

Thank you for this important work!

Aloha and Well Wishes,
-- 
Jim Manico
Manicode Security
https://www.manicode.com

On 11/19/18 4:04 PM, Hannes Tschofenig wrote:

> Hi all,
>
> The authors of the OAuth Security Topics draft came to the conclusion
> that it is not possible to adequately secure the implicit flow against
> token injection since potential solutions like token binding or JARM
> are in an early stage of adoption. For this reason, and since CORS
> allows browser-based apps to send requests to the token endpoint,
> Torsten suggested to use the authorization code instead of the
> implicit grant in call cases in his presentation (see
> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).
>
> 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: Vladimir Dzhuvinov <[email-masked]>
Date: Tue, 27 Nov 2018 17:00:32 +0200

+1 to recommend the deprecation of implicit.

I don't see a compelling reason to keep implicit when there is an
established alternative that is more secure.

Our duty as WG is to give developers the best and most sensible practice.

CORS adoption is currently at 94% according to
https://caniuse.com/#feat=cors

Vladimir

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 27 Nov 2018 16:30:35 +0100

I am actually -1.

+1 for public client and the tokens that are not sender/key constrained.

Just not being used right now does not mean that it is not useful. In fact,
I see it coming.
Implicit (well, Hybrid “token id_token” really) is very useful in certain
cases.
Specifically, when the client is confidential (based on public key pair),
and uses sender constrained (key-constrained) token such as the one
explained in
https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5, it is
very useful.
(Key-constrained token is the remaining portion of this draft that did not
get incorporated in the MTLS draft. )
In fact it is the only viable method for Self-Issued OpenID Provider.

So, the text is generally good but it needs to be constrained like “Unless
the client is confidential and the access token issued is key constrained,
... “

Best,

Nat Sakimura

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Jim Manico <[email-masked]>
Date: Tue, 27 Nov 2018 21:25:03 +0530

Nat,

How is proof of possession established in a modern web browser in the
implicit flow?

My understanding is that token binding was removed from Chrome recently
effectively killing browser-based PoP tokens.

https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/

Am I missing something?

Aloha, Jim

On 11/27/18 9:00 PM, Nat Sakimura wrote:
> Just not being used right now does not mean that it is not useful.. In
> fact, I see it coming. 
> Implicit (well, Hybrid “token id_token” really) is very useful in
> certain cases. 
> Specifically, when the client is confidential (based on public key
> pair), and uses sender constrained (key-constrained) token such as the
> one explained in
> https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5, it
> is very useful. 
> (Key-constrained token is the remaining portion of this draft that did
> not get incorporated in the MTLS draft. )
> So, the text is generally good but it needs to be constrained like
> “Unless the client is confidential and the access token issued is key
> constrained, ... “
>
> Best, 
>
> Nat Sakimura
>
>
> 2018年11月27日(火) 16:01 Vladimir Dzhuvinov <[email-masked]
> <mailto:[email-masked]>>:
>

-- 
Jim Manico
Manicode Security
https://www.manicode.com

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 27 Nov 2018 16:57:57 +0100

I am not talking about SPA.
The client is a regular confidential client that is running on a server.

Best,

Nat Sakimura

2018年11月27日(火) 16:55 Jim Manico <[email-masked]>:

> Manicode Securityhttps://www.manicode.com
>
> --
Nat Sakimura (=nat)

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 27 Nov 2018 20:30:45 +0100

Hi Nat, 

I understand you are saying your draft could provide clients with an application level mechanism to sender constrain access tokens. That’s great! 

But I don’t see a binding to response type „token id_token“. Why do you want to expose the tokens via the URL to attackers? 

You could easily use your mechanism with code. That would also give you the chance to really authenticate the confidential client before you issue the token.

kind regards,
Torsten.

> Am 27.11.2018 um 16:57 schrieb Nat Sakimura <[email-masked]>:
> 
> How is proof of possession established in a modern web browser in the implicit flow?
> 
> My understanding is that token binding was removed from Chrome recently effectively killing browser-based PoP tokens.
> 
>> Just not being used right now does not mean that it is not useful.. In fact, I see it coming. 
>> Implicit (well, Hybrid “token id_token” really) is very useful in certain cases. 
>> Specifically, when the client is confidential (based on public key pair), and uses sender constrained (key-constrained) token such as the one explained in https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5, it is very useful. 
>> (Key-constrained token is the remaining portion of this draft that did not get incorporated in the MTLS draft. )
>> So, the text is generally good but it needs to be constrained like “Unless the client is confidential and the access token issued is key constrained, ... “
>> 
>> Best, 
>> 
>> Nat Sakimura
>> 
>> 
>> http://nat..sakimura.org/
>> @_nat_en
>> 
>>

---

From: John Bradley <[email-masked]>
Date: Tue, 27 Nov 2018 16:54:15 -0300

I talked to Nat about this a bit today.

The thing he is concerned about is mostly around the self issued IDP that
doesn't have a token endpoint(atleast not easaly).

The main use case for that is the id_token response type where claims are
retuned in the id_token.

Because it is fragment encoded some people call that implicit.   That is
not what we are trying to stop.

In some cases in that flow there may be distributed claims returned with
access Token inside the id_token.    I think most people would agree that
those should be pop or sender constrained tokens.

In the case of self issued the RP would be a server and could do sender
constrained via some mechinisim that is yet to be defined.

So if someone wanted to return a access token in a id_token to do
distributed claims I don't think we have a problem with that as long as the
token is protected by being sender constrained in some reasonable way.

This is a touch hypothetical from the basic OAuth perspective, so I don't
know how deep we want to go into it.

I think the point is not to accidently prohibit something that could be
done in future.

I also think we should not conflate confidential clients that can
authenticate to the token endpoint with sender constrained/PoP clients that
can deal with bound tokens.   Yes both have keys but it is better to
describe them separately.

John B.

On Tue, Nov 27, 2018, 4:30 PM Torsten Lodderstedt via Openid-specs-ab <
[email-masked] wrote:

> Hi Nat,
>
> I understand you are saying your draft could provide clients with an
> application level mechanism to sender constrain access tokens. That’s
> great!
>
> But I don’t see a binding to response type „token id_token“. Why do you
> want to expose the tokens via the URL to attackers?
>
> You could easily use your mechanism with code. That would also give you
> the chance to really authenticate the confidential client before you issue
> the token.
>
> kind regards,
> Torsten.
>
> pair), and uses sender constrained (key-constrained) token such as the one
> explained in
> Openid-specs-ab mailing list
> [email-masked]
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 27 Nov 2018 21:28:11 +0100

Hi John, 

as you said, self issued IDPs (https://openid.net/specs/openid-connect-core-1_0.html#SelfIssued) are supposed to provide the response type „id_token“ only. I don’t think the proposal being discussed here is related to this OIDC mode. 

best regards,
Torsten. 

> Am 27.11.2018 um 20:54 schrieb John Bradley <[email-masked]>:
> 
> The thing he is concerned about is mostly around the self issued IDP that doesn't have a token endpoint(atleast not easaly).  
> 
> The main use case for that is the id_token response type where claims are retuned in the id_token.  
> 
> Because it is fragment encoded some people call that implicit.   That is not what we are trying to stop.   
> 
> In some cases in that flow there may be distributed claims returned with access Token inside the id_token.    I think most people would agree that those should be pop or sender constrained tokens.  
> 
> In the case of self issued the RP would be a server and could do sender constrained via some mechinisim that is yet to be defined.  
> 
> So if someone wanted to return a access token in a id_token to do distributed claims I don't think we have a problem with that as long as the token is protected by being sender constrained in some reasonable way.
> 
> This is a touch hypothetical from the basic OAuth perspective, so I don't know how deep we want to go into it.
> 
> I think the point is not to accidently prohibit something that could be done in future.  
> 
> I also think we should not conflate confidential clients that can authenticate to the token endpoint with sender constrained/PoP clients that can deal with bound tokens.   Yes both have keys but it is better to describe them separately.  
> 
> John B. 
> 
> On Tue, Nov 27, 2018, 4:30 PM Torsten Lodderstedt via Openid-specs-ab <[email-masked] wrote:
> Hi Nat, 
>

---

From: John Bradley <[email-masked]>
Date: Tue, 27 Nov 2018 17:36:58 -0300

I understand that, but hat is Nat's concern as I understand it.

When we say no implicit people, have a problem because implicit is 
imprecise.

We are saying no AT returned in the response from the authorization 
endpoint.

Nat points out that id_token may contain AT for the self issued client.

So unless we say that is OK if the AT are sender constrained we wind up 
implying that a OpenID profile of OAuth is in violation of the BCP.

I am just trying to make sure everyone is on the same page with why Nat 
was -1.

It really has nothing to do with the SPA use case.

John B.

---

From: William Denniss <[email-masked]>
Date: Tue, 27 Nov 2018 12:54:07 -0800

In BCP 212 we currently recommend against using implicit flow for native
apps (Section 8.2), due to the inability to protect against interception
with PKCE. AppAuth iOS & Android don't implement it, and the JS version
didn't initially although it was requested by users who needed to do
implicit auth and was eventually supported.

To me the usefulness of implicit on the web is limited, as the code flow
can be used for public clients anyway. The one place I've seen implicit
come up in discussions was for situations where reducing complexity for
third-party developers who needed to implement an OAuth server was a high
priority (one less endpoint to implement).

+1 to have language recommending against the use in most cases (without
needing to exclude Nat's use-case). The code flow has better security
properties, and reducing optionality in the spec reduces the surface area
and simplifies implementations.

On Tue, Nov 27, 2018 at 12:36 PM, John Bradley via Openid-specs-ab <
[email-masked]> wrote:

>> as you said, self issued IDPs (https://openid.net/specs/open
>> id-connect-core-1_0.html#SelfIssued) are supposed to provide the
>> response type „id_token“ only. I don’t think the proposal being discussed
>> here is related to this OIDC mode.
>>
>> best regards,
>> Torsten.
>>
>>> The thing he is concerned about is mostly around the self issued IDP
>>> that doesn't have a token endpoint(atleast not easaly).
>>>
>>> This is a touch hypothetical from the basic OAuth perspective, so I
>>> don't know how deep we want to go into it.
>>>
>>> application level mechanism to sender constrain access tokens. That’s great!
>>>
>>>>> explained in https://tools.ietf.org/html/dr
>>>>> aft-sakimura-oauth-jpop-04#section-5, it is very useful.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 27 Nov 2018 21:59:03 +0100

> Am 27.11.2018 um 21:54 schrieb William Denniss <[email-masked]>:
> 
> +1 to have language recommending against the use in most cases (without needing to exclude Nat's use-case).

Can you (or someone else) propose text?

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 27 Nov 2018 22:03:28 +0100

I still don’t understand why the use case must be solved using a flow issuing something in the front channel. 

I would also like to take a closer look. Can you or Nat provide pointers to existing implementations? 

> Am 27.11.2018 um 21:36 schrieb John Bradley <[email-masked]>:
> 
> When we say no implicit people, have a problem because implicit is imprecise.
> 
> We are saying no AT returned in the response from the authorization endpoint.
> 
> So unless we say that is OK if the AT are sender constrained we wind up implying that a OpenID profile of OAuth is in violation of the BCP.
> 
> I am just trying to make sure everyone is on the same page with why Nat was -1.
>

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 28 Nov 2018 07:58:04 +0900

Self Issued OP is described in Chapter 7 of the OpenID Connect Core 1.0.
It lives on a local machine, typically a phone. Even if it did provide an
authorization code to the client, the client cannot establish a direct
connection to the local machine (phone) as it is not addressable.
Therefore, a token endpoint cannot be provided unless it is coupled with
some kind of cloud-based service, which would negate some of the very
reason for having the Self-issued OP. In other words, only the viable
communication channel between the SIOP and the client is the front channel.
The situation could be true to other "wallet" type of implementations.

This is one of the exotic features of OpenID Connect that never got a
traction but it is getting a renewed interest as "Self-sovereign Identity"
gained some interest.

On Wed, Nov 28, 2018 at 6:03 AM Torsten Lodderstedt <[email-masked]>
wrote:

> >> as you said, self issued IDPs (
> https://openid.net/specs/openid-connect-core-1_0.html#SelfIssued) are
> supposed to provide the response type „id_token“ only. I don’t think the
> proposal being discussed here is related to this OIDC mode.
> >>
> >> best regards,
> >> Torsten.
> >>
> >>> In some cases in that flow there may be distributed claims returned
> with access Token inside the id_token.    I think most people would agree
> that those should be pop or sender constrained tokens.
> >>>
> >>> In the case of self issued the RP would be a server and could do
> sender constrained via some mechinisim that is yet to be defined.
> >>>
> >>> But I don’t see a binding to response type „token id_token“. Why do
> you want to expose the tokens via the URL to attackers?
> >>>
> >>> You could easily use your mechanism with code. That would also give
> you the chance to really authenticate the confidential client before you
> issue the token.
> >>>
> >>> kind regards,
> >>> Torsten.
> >>>
> >>>> My understanding is that token binding was removed from Chrome
> recently effectively killing browser-based PoP tokens.
> >>>>
> >>>>
> >>>>> (Key-constrained token is the remaining portion of this draft that
> did not get incorporated in the MTLS draft. )

---

From: n-sakimura <[email-masked]>
Date: Tue, 27 Nov 2018 23:50:15 +0000

Tom,

It is good to hear that you will be there.
I understand John will also be there.

To your question, self-issued ID does not require a (semi-)permanent URL as the user’s identifier, as it is always “localhost”.
The identifier is derived as the hash of the public key that was generated by the Self-issued OP.
If your question was “URI”, then yes. Its issuer is always https://self-issued.me and there is a `sub` for that identity, so synthesized URI for the user would be something like https://self-issued.me/{sub}<https://self-issued.me/%7bsub%7d> where {sub} represents the value of the `sub` claim. `sub` claim value is defined as follows:

sub (subject) Claim value is the base64url encoded representation of the thumbprint of the key in the sub_jwk Claim. This thumbprint value is computed as the SHA-256 hash of the octets of the UTF-8 representation of a JWK constructed containing only the REQUIRED members to represent the key, with the member names sorted into lexicographic order, and with no white space or line breaks. For instance, when the kty value is RSA, the member names e, kty, and n are the ones present in the constructed JWK used in the thumbprint computation and appear in that order; when the kty value is EC, the member names crv, kty, x, and y are present in that order. Note that this thumbprint calculation is the same as that defined in the JWK Thumbprint [JWK.Thumbprint]Jones, M., “JSON Web Key (JWK) Thumbprint,” July 2014.<https://openid.net/specs/openid-connect-core-1_0.html#JWK.Thumbprint> specification.

So, yes. The string https://self-issued.me/{sub}<https://self-issued.me/%7bsub%7d> is probabilistically unique and “persistent” (better to phrase it as ‘never re-assigned’).

The reason it is not a “URL” is that you cannot reach it. However, It is a “URI”.

Cheers,

Nat Sakimura <[email-masked]<mailto:[email-masked]>>

PLEASE READ :This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail.

From: Openid-specs-ab <[email-masked]> On Behalf Of Tom Jones via Openid-specs-ab
Sent: Wednesday, November 28, 2018 8:16 AM
To: Artifact Binding/Connect Working Group <[email-masked]>
Cc: Tom Jones <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Openid-specs-ab] [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

I am headed to a w3c meeting that will talk about DIDs for the future. I would like to understand if the self-issued ID requires (or should require) some sort of (semi) permanent URL on the internet. (including on a block-chain, for example.)  Without that i cannot understand what a self-issued ID might even mean.

Peace ..tom

On Tue, Nov 27, 2018 at 3:06 PM Nat Sakimura via Openid-specs-ab <[email-masked]<mailto:[email-masked]>> wrote:
Self Issued OP is described in Chapter 7 of the OpenID Connect Core 1.0.
It lives on a local machine, typically a phone. Even if it did provide an authorization code to the client, the client cannot establish a direct connection to the local machine (phone) as it is not addressable. Therefore, a token endpoint cannot be provided unless it is coupled with some kind of cloud-based service, which would negate some of the very reason for having the Self-issued OP. In other words, only the viable communication channel between the SIOP and the client is the front channel. The situation could be true to other "wallet" type of implementations.

This is one of the exotic features of OpenID Connect that never got a traction but it is getting a renewed interest as "Self-sovereign Identity" gained some interest.

On Wed, Nov 28, 2018 at 6:03 AM Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:
I still don’t understand why the use case must be solved using a flow issuing something in the front channel.

> Am 27.11.2018 um 21:36 schrieb John Bradley <[email-masked]<mailto:[email-masked]>>:
>
>>> Am 27.11.2018 um 20:54 schrieb John Bradley <[email-masked]<mailto:[email-masked]>>:
>>>
>>> On Tue, Nov 27, 2018, 4:30 PM Torsten Lodderstedt via Openid-specs-ab <[email-masked]<mailto:[email-masked]> wrote:
>>> Hi Nat,
>>>
>>>> Am 27.11.2018 um 16:57 schrieb Nat Sakimura <[email-masked]<mailto:[email-masked]>>:
>>>>
>>>> 2018年11月27日(火) 16:55 Jim Manico <[email-masked]<mailto:[email-masked]>>:
>>>> Nat,
>>>>
>>>>> 2018年11月27日(火) 16:01 Vladimir Dzhuvinov <[email-masked]<mailto:[email-masked]>>:
>>>>> http://nat..sakimura.org/<http://sakimura.org/>
>>>>> @_nat_en
>>>>>
>>>>>
>>> [email-masked]<mailto:[email-masked]>

[email-masked]<mailto:[email-masked]>

---

From: n-sakimura <[email-masked]>
Date: Wed, 28 Nov 2018 00:56:13 +0000

Not really.

It is not a requirement of SIOP to leverage the device’s secure element to create key-pairs. So, the keys can be exported and ported to other devices as well. There could be key syncing mechanism as well, like 1password, but it is not standardized.

Re: discovery
In the use-case of SIOP, from the client’s point of view, SIOP is always in the user’s device, i.e., localhost. So, there is no need for discovery.

Having said that: SIOP spec is a bit old and depends on custom scheme on iOS. Now iOS has newer capability like claimed URI, which is more secure. So, having a discovery mechanism that returns  [Self-issued Identifier – device type – claimed URI] triple kind of thing may be useful. (Note, I just came up with it now and it’s 2 AM here so it may be a bad idea after all.)

From: Tom Jones <[email-masked]>
Sent: Wednesday, November 28, 2018 9:14 AM
To: Nat Sakimura <[email-masked]>
Cc: Artifact Binding/Connect Working Group <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Openid-specs-ab] [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

I see, so then the self-issued ID is device-locked? it sounds more like a device ID than a user ID.  Which is useful, but not too helpful in a multiple device world. The screen i am using right now has 3 devices driving it in one form or another. Is there any way that a self-issued ID of this form can be made useful in today's world?  BTW - i like the idea of URN's rather than URL's, but some resolver capability seems to be a requirement?
Peace ..tom

On Tue, Nov 27, 2018 at 3:50 PM n-sakimura <[email-masked]<mailto:[email-masked]>> wrote:
Tom,

Cheers,

From: Openid-specs-ab <[email-masked]<mailto:[email-masked]>> On Behalf Of Tom Jones via Openid-specs-ab
Sent: Wednesday, November 28, 2018 8:16 AM
To: Artifact Binding/Connect Working Group <[email-masked]<mailto:[email-masked]>>
Cc: Tom Jones <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Openid-specs-ab] [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Peace ..tom

---

From: Dick Hardt <[email-masked]>
Date: Wed, 28 Nov 2018 11:57:50 -0800

+1

While there are various mechanisms to alleviate some of the issues of
implicit, I don't think we can recommend specifics, and there may be future
ones in the future. I think we all agree that implicit without any
mitigation is problematic.

How about we recommend against using implicit alone?

---

From: n-sakimura <[email-masked]>
Date: Wed, 28 Nov 2018 20:10:06 +0000

I would support

1) clearly defining Implicit as the flow that returns access token from the authorization endpoint ( some people confuses implicit as the flow that returns ID Token in the front channel)

2) Banning the returning of the access token that are not sender constrained from the authorization endpoint

Best,

Nat

Outlook for iOS<https://aka.ms/o0ukef> を入手

________________________________
差出人: OAuth <[email-masked]> (Dick Hardt <[email-masked]> の代理)
送信日時: 水曜日, 11月 28, 2018 8:58 午後
宛先: Hannes Tschofenig
Cc: [email-masked]
件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

+1

While there are various mechanisms to alleviate some of the issues of implicit, I don't think we can recommend specifics, and there may be future ones in the future. I think we all agree that implicit without any mitigation is problematic.

On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

Ciao

Hannes & Rifaat

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 28 Nov 2018 21:44:41 +0000

I strongly support the author’s proposed text recommending that “Clients SHOULD NOT use the implicit grant or any other response type causing the authorization server to issue an access token in the authorization response.” While it may be possible to construct scenarios in which use of sender-constrained access tokens mitigates the major known threats, this strikes me as a niche use case that will be very hard for developers to get right, in practice (particularly if browsers don’t support token binding). This seems to meet the criteria for “SHOULD NOT.”

Bear in mind that the proposed text does not prohibit the practice, but it informs the reader that they had better know what they are doing if they’re going to use implicit grant (or the OIDC hybrid flow, etc.). I think that is good guidance – sending access tokens through a front channel is definite “here there be dragons” territory.

--
Annabelle Richard Backman
AWS Identity

From: OAuth <[email-masked]> on behalf of n-sakimura <[email-masked]>
Date: Wednesday, November 28, 2018 at 12:11 PM
To: Dick Hardt <[email-masked]>, Hannes Tschofenig <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

I would support

Best,

Nat

+1

Hi all,

Ciao

Hannes & Rifaat

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 28 Nov 2018 23:38:03 +0100

Hi Nat, 

> Am 28.11.2018 um 21:10 schrieb n-sakimura <[email-masked]>:
> 
> I would support
> 

That’s the current text: 

What would you like to modify? 

In order to avoid these issues, Clients SHOULD NOT use the implicit
   grant or any other response type causing the authorization server to
   issue an access token in the authorization response, if this access tokens is not sender-constraint.

What about this?

kind regards,
Torsten.

> Outlook for iOS を入手
> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <[email-masked]> wrote:
> Hi all,
>

---

From: n-sakimura <[email-masked]>
Date: Wed, 28 Nov 2018 22:50:53 +0000

That works.

In fact, I would further go and say MUST NOT but that probably is too much for a security consideration.

Best,

Nat

Nat Sakimura / [email-masked] / +81-90-6013-6276

このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、誠に申し訳ございませんが、送信者までお知らせ頂き、また受信されたメールは削除してくださいますようお願い申し上げます。

PLEASE READ :This e-mail is confidential and intended for the named recipient only.
If you are not an intended recipient, please notify the sender and delete this e-mail.

________________________________
差出人: Torsten Lodderstedt <[email-masked]>
送信日時: 水曜日, 11月 28, 2018 11:38 午後
宛先: n-sakimura
Cc: Dick Hardt; Hannes Tschofenig; [email-masked]
件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Hi Nat,

Am 28.11.2018 um 21:10 schrieb n-sakimura <[email-masked]<mailto:[email-masked]>>:

I would support

That’s the current text:

What about this?

kind regards,
Torsten.

Best,

Nat

Outlook for iOS を入手

差出人: OAuth <[email-masked]<mailto:[email-masked]>> (Dick Hardt <[email-masked]<mailto:[email-masked]>> の代理)
送信日時: 水曜日, 11月 28, 2018 8:58 午後
宛先: Hannes Tschofenig
Cc: [email-masked]<mailto:[email-masked]>
件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

+1

On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Ciao

Hannes & Rifaat

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 29 Nov 2018 00:03:27 +0100

> Am 28.11.2018 um 23:50 schrieb n-sakimura <[email-masked]>:
> 
> That works.

Good!

I just realized this text has an issue with „token“ (only). It would allow „token“ to be used if the token would sender constrained. This completely ignores the fact implicit also shall be abandoned because of its vulnerability for access token injection. 

I therefore propose a modified text: 

   In order to avoid these issues, Clients SHOULD NOT use the implicit
   grant. Furthermore, clients SHOULD only use other response types causing the authorization server to
   issue an access token in the authorization response, if the particular response type detects access token 
   injection and the issued access tokens are sender-constrained.

Or we just state:

  In order to avoid these issues, Clients SHOULD NOT use the response type „token". The response types
„token id_token“ and „code token id_token“ SOULD NOT be used, if the issued access tokens are not 
sender-constrained.

> In fact, I would further go and say MUST NOT but that probably is too much for a security consideration.

Mike suggested to go with a SHOULD NOT to get the message out but give implementors time to move/change.

---

From: William Denniss <[email-masked]>
Date: Wed, 28 Nov 2018 15:16:13 -0800

> for a security consideration.
Personally I think it's fine for a MUST NOT to appear in a security
consideration section of a BCP. If you break it, then you're not following
the BCP.

We did exactly this in BCP 212:

"This best current
   practice requires that native apps MUST NOT use embedded user-agents
   to perform authorization requests
"

William

> ------------------------------
> *差出人:* Torsten Lodderstedt <[email-masked]>
> *送信日時:* 水曜日, 11月 28, 2018 11:38 午後
> *宛先:* n-sakimura
> *Cc:* Dick Hardt; Hannes Tschofenig; [email-masked]
> *件名:* Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization
> code instead of implicit
>
> Hi Nat,
>
> 1) clearly defining Implicit as the flow that returns access token from
> the authorization endpoint ( some people confuses implicit as the flow that
> returns ID Token in the front channel)
>
>
> That’s the current text:
>
> 2) Banning the returning of the access token that are not sender
> constrained from the authorization endpoint
>
>
>    issue an access token in the authorization response*, if this access
> tokens is not sender-constraint.*
>
> What about this?
>
> kind regards,
> Torsten.
>
>
> Best,
>
> Nat
>
>
> Outlook for iOS を入手
>

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 29 Nov 2018 00:33:34 +0100

Inline:

2018年11月29日(木) 0:03 Torsten Lodderstedt <[email-masked]>:

> I just realized this text has an issue with „token“ (only). It would allow
> „token“ to be used if the token would sender constrained. This completely
> ignores the fact implicit also shall be abandoned because of its
> vulnerability for access token injection.
>

A friendly amendment.

In order to avoid these issues, clients SHOULD NOT return access token in
the authorization response unless the particular response type detects
access token injection and the issued access tokens are sender-constrained.

> issued access tokens are not

This one looks on the surface but as John points out, it misses out the
cases where response types are expanded.

> implementors time to move/change.

As William says, I actually advocate MUST NOT but OK with SHOULD NOT as
well.

> token injection since potential solutions like token binding or JARM are in
> an early stage of adoption. For this reason, and since CORS allows
-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en

---

From: Petteri Stenius <[email-masked]>
Date: Thu, 29 Nov 2018 13:26:37 +0000

Hi all,

I support this proposal of recommending authorization code grant and advising to not use implicit grant.
As a developer we value clean and robust specifications with less opportunity for mistakes.

Thank you,
Petteri Stenius / Ubisecure

-----Original Message-----
From: OAuth <[email-masked]> On Behalf Of Torsten Lodderstedt
Sent: sunnuntai 25. marraskuuta 2018 19.33
To: [email-masked]
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Hi all, 

——

2.1.2.  Implicit Grant

Two reasons: 

kind regards, 
Torsten.

---

From: John Bradley <[email-masked]>
Date: Thu, 29 Nov 2018 11:15:36 -0300

I am ok with that.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 29 Nov 2018 19:06:00 +0100

Hi all, 

based on your feedback on the list and off list, Daniel and I polished the text. That’s our proposal:

—
In order to avoid these issues, clients MUST NOT use the implicit
grant (response type "token") or any other response type issuing access 
tokens in the authorization response, such as "token id_token" and "code token id_token“, 
unless the issued access tokens are sender-constrained and access token injection in 
the authorization response is prevented. 
—

Explantation: 
- we wanted to have the right balance between a generic definition of the response types we do not recommend/allow to be used and a concrete/actionable list of the affected response types. 
- we changed from SHOULD NOT to MUST NOT as suggested by Nat and supported by William

We look forward to seeing your feedback.

kind regards,
Torsten.  

> Am 29.11.2018 um 15:15 schrieb John Bradley <[email-masked]>:
> 
> I am ok with that.  
> 
> On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt <[email-masked] wrote:
>

---

From: John Bradley <[email-masked]>
Date: Thu, 29 Nov 2018 15:33:57 -0300

+1

On Thu, Nov 29, 2018, 3:06 PM Torsten Lodderstedt <[email-masked]
wrote:

> - we wanted to have the right balance between a generic definition of the
> response types we do not recommend/allow to be used and a
> concrete/actionable list of the affected response types.
> > I just realized this text has an issue with „token“ (only). It would
> allow „token“ to be used if the token would sender constrained. This
> completely ignores the fact implicit also shall be abandoned because of its
> >    issue an access token in the authorization response, if the
> particular response type detects access token
> > >> 1) clearly defining Implicit as the flow that returns access token
> from the authorization endpoint ( some people confuses implicit as the flow
> that returns ID Token in the front channel)
> > >
> > > That’s the current text:
> > >

---

From: n-sakimura <[email-masked]>
Date: Thu, 29 Nov 2018 18:43:05 +0000

+1

PLEASE READ :This e-mail is confidential and intended for the named recipient only.
If you are not an intended recipient, please notify the sender and delete this e-mail.
________________________________
From: OAuth <[email-masked]> on behalf of John Bradley <[email-masked]>
Sent: Thursday, November 29, 2018 7:33:57 PM
To: Torsten Lodderstedt
Cc: Daniel Fett; IETF oauth WG
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

+1

On Thu, Nov 29, 2018, 3:06 PM Torsten Lodderstedt <[email-masked]<mailto:[email-masked]> wrote:
Hi all,

—

Explantation:

kind regards,
Torsten.

> Am 29.11.2018 um 15:15 schrieb John Bradley <[email-masked]<mailto:[email-masked]>>:
>
> I am ok with that.
>
> On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt <[email-masked]<mailto:[email-masked]> wrote:
>
> > Am 28.11.2018 um 23:50 schrieb n-sakimura <[email-masked]..jp<mailto:[email-masked]>>:
> >
> > That works.
>
> Good!
>
> > Nat Sakimura / [email-masked]<mailto:[email-masked]> / +81-90-6013-6276
> >
> > 差出人: Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>>
> > Cc: Dick Hardt; Hannes Tschofenig; [email-masked]<mailto:[email-masked]>
> >> 差出人: OAuth <oauth-bounces@ietf..org<mailto:[email-masked]>> (Dick Hardt <[email-masked]<mailto:[email-masked]>> の代理)

---

From: William Denniss <[email-masked]>
Date: Thu, 29 Nov 2018 10:49:27 -0800

+1

On Thu, Nov 29, 2018 at 10:43 AM n-sakimura <[email-masked]> wrote:

> *From:* OAuth <[email-masked]> on behalf of John Bradley <
> [email-masked]>
> *Sent:* Thursday, November 29, 2018 7:33:57 PM
> *To:* Torsten Lodderstedt
> *Cc:* Daniel Fett; IETF oauth WG
>> > > Am 28.11.2018 um 23:50 schrieb n-sakimura <[email-masked]..jp
>> <[email-masked]>>:
>> > >
>> > > That works.
>> >
>> > Good!
>> >
>> > >> 差出人: OAuth <oauth-bounces@ietf..org <[email-masked]>> (Dick
>> Hardt <[email-masked]> の代理)
>> > >> While there are various mechanisms to alleviate some of the issues
>> of implicit, I don't think we can recommend specifics, and there may be
>> future ones in the future. I think we all agree that implicit without any

---

From: Dave Tonge <[email-masked]>
Date: Fri, 30 Nov 2018 06:03:30 +0100

+1

-- 
Dave Tonge

---

From: Neil Madden <[email-masked]>
Date: Fri, 30 Nov 2018 08:26:51 +0000

+1 from me too. 

> On 29 Nov 2018, at 18:06, Torsten Lodderstedt <[email-masked]> wrote:
> 
> Hi all, 
>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 30 Nov 2018 13:02:44 -0700

As was pointed out to me in WGLC review of the MTLS document,
"sender-constrained" has or is likely to be interpreted with a pretty
specific meaning of the token being bound to the client and the client
authenticating itself to the resource and the resource checking all that
matches up. That makes the text more restrictive than is likely intended.
Perhaps the text should say something like "sender or key constrained" to
allow for different variants of PoP access tokens?

-- 
_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: Torsten Lodderstedt <[email-masked]>
Date: Fri, 30 Nov 2018 21:42:52 +0100

Hi Brian,

we use „sender constrained tokens“ throughout the BCP to denote tokens bound to a sender in possession of a certain key/secret and I thought that was established terminology in the group. Are you suggesting „key constrained” would be more appropriate?

kind regards,
Torsten.

> Am 30.11.2018 um 21:02 schrieb Brian Campbell <[email-masked]>:
> 
> As was pointed out to me in WGLC review of the MTLS document, "sender-constrained" has or is likely to be interpreted with a pretty specific meaning of the token being bound to the client and the client authenticating itself to the resource and the resource checking all that matches up. That makes the text more restrictive than is likely intended. Perhaps the text should say something like "sender or key constrained" to allow for different variants of PoP access tokens? 
> 
> 
> 
>> On Thu, Nov 29, 2018 at 11:06 AM Torsten Lodderstedt <[email-masked]> wrote:
>> Hi all, 
>> 
> 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: Brian Campbell <[email-masked]>
Date: Fri, 30 Nov 2018 15:23:26 -0700

Kind of, yes. I guess so. I think. It's just semantics. But yeah. Key
constrained might be more appropriate. But the Security Topics document
probably should allow for both/either.

I don't think that these are necessarily terms with widely agreed upon or
understood meaning. But it was pointed out to me that the OAuth 2.0 Pop
Architecture draft defines sender constraint and key confirmation as
different things (
https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-6.2
and
https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-6.3).
And the definitions their do kind of make sense when thinking about the
words used. The line between sender and key constrained isn't exactly clear
but it seems MTLS and token binding access tokens are more key constrained
than sender. The -08 version of the MTLS draft dropped the use of the
"sender constrained" terminology based on that feedback.

I dunno. Maybe the Security Topics could say something in a terminology
section that says when sender or key constrained is used within they can be
taken to mean the same concept. Or something like that.

On Fri, Nov 30, 2018 at 1:42 PM Torsten Lodderstedt <[email-masked]>
wrote:

> Hi Brian,
>
> we use „sender constrained tokens“ throughout the BCP to denote tokens
> bound to a sender in possession of a certain key/secret and I thought that
> was established terminology in the group. Are you suggesting „key
> constrained” would be more appropriate?
>
> kind regards,
> Torsten.
>
> Am 30.11.2018 um 21:02 schrieb Brian Campbell <[email-masked]
> >:
>
> *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: Dick Hardt <[email-masked]>
Date: Fri, 30 Nov 2018 14:35:39 -0800

+ 1 to the change

I'd suggest we work to define terms such as "sender constrained" in the BCP
so that it is clear what is meant by it.

On Fri, Nov 30, 2018 at 2:24 PM Brian Campbell <bcampbell=
[email-masked]> wrote:

> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-6.3
> <https://tools.ietf..org/html/draft-ietf-oauth-pop-architecture-08#section-6.3>).
> On Fri, Nov 30, 2018 at 1:42 PM Torsten Lodderstedt <
>>> - we wanted to have the right balance between a generic definition of
>>> the response types we do not recommend/allow to be used and a
>> review, use, distribution or disclosure by others is strictly prohibited..
> review, use, distribution or disclosure by others is strictly prohibited..
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Jim Willeke <[email-masked]>
Date: Fri, 30 Nov 2018 17:46:58 -0500

+1 for the change.
--
-jim
Jim Willeke

On Fri, Nov 30, 2018 at 5:36 PM Dick Hardt <[email-masked]> wrote:

> + 1 to the change
>
> I'd suggest we work to define terms such as "sender constrained" in the
> BCP so that it is clear what is meant by it.
>
>>> 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.*
>>>
>>>
>> 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: Aaron Parecki <[email-masked]>
Date: Fri, 30 Nov 2018 18:17:57 -0800

+1

I would also like to ensure there is a clear definition of "sender
constrained" tokens in this BCP.

Aaron