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

[Rifaat Shekh-Yusef <[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]> 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]
> >:
> >
> > 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]> 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]>:
> >
> >> 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]>
> >>>> :
> >>>>
> >>>> 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]
> >>>>  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]>
> >>>>>  On Behalf Of John Bradley
> >>>>> Sent: Tuesday, November 20, 2018 7:47 AM
> >>>>> To:
> >>>>> [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]>
> >>>>> :
> >>>>>
> >>>>> 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]>
> >>>>>  On Behalf Of Hannes Tschofenig
> >>>>> Sent: Monday, November 19, 2018 2:34 AM
> >>>>> To: oauth
> >>>>> <[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
> >>>>> ).
> >>>>>
> >>>>> 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]
> >>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>>
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>>
> >>>>>
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>> _______________________________________________
> >>>> OAuth mailing list
> >>>>
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/oauth
> >>
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> > --
> > [e-mail]
> > ZmartZone IAM - www.zmartzone.eu
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>