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

[n-sakimura <[e-mail]>]

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

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 <[e-mail]<mailto:[e-mail]> 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

   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 <[e-mail]<mailto:[e-mail]>> 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.

Does this answer your question?

kind regards,
Torsten.

> Am 25.11.2018 um 19:22 schrieb Rifaat Shekh-Yusef <[e-mail]<mailto:[e-mail]>>:
>
> 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 <[e-mail]<mailto:[e-mail]>> wrote:
> 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 <[e-mail]<mailto:[e-mail]>>:
> >
> > 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 <[e-mail]<mailto:[e-mail]>> wrote:
> > 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 <[e-mail]<mailto:[e-mail]>>:
> >
> >> An SPA has a backend because it has to be loaded from somewhere :)
> >>
> >> On 11/21/18 3:47 AM, Torsten Lodderstedt wrote:
> >>> 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 <[e-mail]<mailto:[e-mail]>>
> >>>> :
> >>>>
> >>>> 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 <
> >>>> [e-mail]<mailto:[e-mail]>
> >>>>  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 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
> >>>>> <[e-mail]<mailto:[e-mail]>>
> >>>>>  On Behalf Of John Bradley
> >>>>> Sent: Tuesday, November 20, 2018 7:47 AM
> >>>>> To:
> >>>>> [e-mail]<mailto:[e-mail]>
> >>>>>
> >>>>> Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
> >>>>>
> >>>>>
> >>>>>
> >>>>> 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:
> >>>>>
> >>>>> 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=[e-mail]<mailto:[e-mail]>>
> >>>>> :
> >>>>>
> >>>>> 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
> >>>>>
> >>>>> From: OAuth
> >>>>> <[e-mail]<mailto:[e-mail]>>
> >>>>>  On Behalf Of Hannes Tschofenig
> >>>>> Sent: Monday, November 19, 2018 2:34 AM
> >>>>> To: oauth
> >>>>> <[e-mail]<mailto:[e-mail]>>
> >>>>>
> >>>>> 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 (seehttps://
> >>>>> 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>
> >>>>> ).
> >>>>>
> >>>>> 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.
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>>
> >>>>> [e-mail]<mailto:[e-mail]>
> >>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>>
> >>>>> [e-mail]<mailto:[e-mail]>
> >>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>>
> >>>>>
> >>>>> [e-mail]<mailto:[e-mail]>
> >>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>> _______________________________________________
> >>>> OAuth mailing list
> >>>>
> >>>> [e-mail]<mailto:[e-mail]>
> >>>> https://www.ietf.org/mailman/listinfo/oauth
> >>
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]<mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> > --
> > [e-mail]<mailto:[e-mail]>
> > ZmartZone IAM - www.zmartzone.eu<http://www.zmartzone.eu>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth