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

[John Bradley <[e-mail]>]

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
>