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

[Rifaat Shekh-Yusef <[e-mail]>]

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

> 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]
> 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]> 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]>:
>>> >
>>> > 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]
>>> <[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
>>>
>>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>