Subject: Re: [OAUTH-WG] OAuth Digest, Vol 136, Issue 9

From: Bruno Brito <[email-masked]>
Date: Wed, 19 Feb 2020 17:20:50 -0300

No, I cannot see any use case where authorization code cannot replace
implicit. Go ahead and remove it!

Bruno

On Wed, Feb 19, 2020 at 5:01 PM <[email-masked]> wrote:

> Send OAuth mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
> Today's Topics:
>
>    1. Re: OAuth 2.1 - drop implicit flow? (Dominick Baier)
>    2. Re: OAuth Digest, Vol 136, Issue 7 (Torsten Lodderstedt)
>    3. Re: [EXTERNAL]  OAuth 2.1: dropping password grant (Dick Hardt)
>
>
>
> ---------- Forwarded message ----------
> From: Dominick Baier <[email-masked]>
> To: Dick Hardt <[email-masked]>, [email-masked]
> Cc:
> Bcc:
> Date: Tue, 18 Feb 2020 22:49:05 -0800
> Subject: Re: [OAUTH-WG] OAuth 2.1 - drop implicit flow?
> No - please get rid of it.
>
> ———
> Dominick Baier
>
> On 18. February 2020 at 21:32:31, Dick Hardt ([email-masked]) wrote:
>
> Hey List
>
> (I'm using the OAuth 2.1 name as a placeholder for the doc that Aaron,
> Torsten, and I are working on)
>
> Given the points Aaron brought up in
>
> https://mailarchive.ietf.org/arch/msg/oauth/hXEfLXgEqrUQVi7Qy8X_279DCNU
>
>
> Does anyone have concerns with dropping the implicit flow from the OAuth
> 2.1 document so that developers don't use it?
>
> /Dick
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> ---------- Forwarded message ----------
> From: Torsten Lodderstedt <[email-masked]>
> To: Bruno Brito <[email-masked]>
> Cc: [email-masked]
> Bcc:
> Date: Wed, 19 Feb 2020 08:25:19 +0100
> Subject: Re: [OAUTH-WG] OAuth Digest, Vol 136, Issue 7
> Hi Bruno,
>
> thanks for your insights.
>
> The recommendation is not only based on security considerations but just
> utility. As soon as one wants to integrate federated login or multi factor
> authentication,  ROPG reaches its limits.
>
> Moreover, how do those teams implement user registration and user account
> recovery? In my experience, implementing this in a native experience will
> significantly increase cost of the implementation.
>
> Two reasons to go with the code flow.
>
> best regards,
> Torsten.
>
> > Am 19.02.2020 um 01:49 schrieb Bruno Brito <[email-masked]>:
> >
>
>
>
> ---------- Forwarded message ----------
> From: Dick Hardt <[email-masked]>
> To: Anthony Nadalin <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Bcc:
> Date: Wed, 19 Feb 2020 11:35:03 -0800
> Subject: Re: [OAUTH-WG] [EXTERNAL]  OAuth 2.1: dropping password grant
> Tony: are you ok with dropping password grant?
>
> You reference valid use cases. If you think it should continue, would you
> provide the use cases?
>
> ᐧ
>
> On Tue, Feb 18, 2020 at 12:57 PM Dick Hardt <[email-masked]> wrote:
>
>> The security topics says MUST. If you want to change that, then that is a
>> different discussion. :)
>>
>> In the OAuth 2.1 document, it would just not be included. Applications
>> can continue to be OAuth 2.0 compliant.
>>
>> BUT ... if there are valid, new use cases. Please describe them! Perhaps
>> it should not be dropped.
>>
>>
>> On Tue, Feb 18, 2020 at 12:54 PM Anthony Nadalin <[email-masked]>
>> wrote:
>>
>>> I would suggest a SHOULD NOT instead of MUST, there are still sites
>>> using this and a grace period should be provided before a MUST is pushed
>>> out as there are valid use cases out there still.
>>>
>>>
>>>
>>> *From:* OAuth <[email-masked]> *On Behalf Of * Dick Hardt
>>> *Sent:* Tuesday, February 18, 2020 12:37 PM
>>> *To:* [email-masked]
>>> *Subject:* [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant
>>>
>>>
>>>
>>> Hey List
>>>
>>>
>>>
>>> (Once again using the OAuth 2.1 name as a placeholder for the doc that
>>> Aaron, Torsten, and I are working on)
>>>
>>>
>>>
>>> In the security topics doc
>>>
>>>
>>>
>>>
>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.4
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-security-topics-14%23section-2.4&data=02%7C01%7Ctonynad%40microsoft.com%7C47bb597eef584c95ba4108d7b4b274b2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637176550905333283&sdata=nA1S7TBfZg6cSwY2hI8hpRXhIA2joaaJFmNXrATgr2Y%3D&reserved=0>
>>>
>>>
>>>
>>> The password grant MUST not be used.
>>>
>>>
>>>
>>> Some background for those interested. I added this grant into OAuth 2.0
>>> to allow applications that had been provided password to migrate. Even with
>>> the caveats in OAuth 2.0, implementors decide they want to prompt the user
>>> to enter their credentials, the anti-pattern OAuth was created to
>>> eliminate.
>>>
>>>
>>>
>>>
>>>
>>> Does anyone have concerns with dropping the password grant from the
>>> OAuth 2.1 document so that developers don't use it?
>>>
>>>
>>>
>>> /Dick
>>>
>> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Bhupinder Saini <[email-masked]>
Date: Thu, 20 Feb 2020 11:39:35 +0000

Hello All

I have recently joined this working group but have I have been IAM consultant for 15+ years.
My opinion and experience on following:

  *   Implicit Grant – Definitely Dropped
  *   Password Grant – Definitely Dropped

I had so many conversation with App (WEB/MOBILE) developers on NOT using them in last few years, now with revised 2.1 we can avoid those conversations. Although these grants made it look less complex but never really aligned to utilise the full security of OAUTH2.

I favour the vote to drop them for good and make Oauth 2.1 clean as following:

  *   Authorisation Code Grants
  *   Client Credentials

Thanks
Bhupinder Singh

From: OAuth <[email-masked]> on behalf of Bruno Brito <[email-masked]>
Date: Wednesday, 19 February 2020 at 20:21
To: "[email-masked]" <[email-masked]>
Subject: Re: [OAUTH-WG] OAuth Digest, Vol 136, Issue 9

No, I cannot see any use case where authorization code cannot replace implicit. Go ahead and remove it!

Bruno

On Wed, Feb 19, 2020 at 5:01 PM <[email-masked]<mailto:[email-masked]>> wrote:
Send OAuth mailing list submissions to
        [email-masked]<mailto:[email-masked]>

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
        [email-masked]<mailto:[email-masked]>

You can reach the person managing the list at
        [email-masked]<mailto:[email-masked]>

---------- Forwarded message ----------
From: Dominick Baier <[email-masked]<mailto:[email-masked]>>
To: Dick Hardt <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>
Cc:
Bcc:
Date: Tue, 18 Feb 2020 22:49:05 -0800
Subject: Re: [OAUTH-WG] OAuth 2.1 - drop implicit flow?

———
Dominick Baier

On 18. February 2020 at 21:32:31, Dick Hardt ([email-masked]<mailto:[email-masked]>) wrote:
Hey List

(I'm using the OAuth 2.1 name as a placeholder for the doc that Aaron, Torsten, and I are working on)

Does anyone have concerns with dropping the implicit flow from the OAuth 2.1 document so that developers don't use it?

/Dick
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---------- Forwarded message ----------
From: Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>>
To: Bruno Brito <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Bcc:
Date: Wed, 19 Feb 2020 08:25:19 +0100
Subject: Re: [OAUTH-WG] OAuth Digest, Vol 136, Issue 7
Hi Bruno,

The recommendation is not only based on security considerations but just utility. As soon as one wants to integrate federated login or multi factor authentication,  ROPG reaches its limits.

Moreover, how do those teams implement user registration and user account recovery? In my experience, implementing this in a native experience will significantly increase cost of the implementation.

best regards,
Torsten.

> Am 19.02.2020 um 01:49 schrieb Bruno Brito <[email-masked]<mailto:[email-masked]>>:
>

---------- Forwarded message ----------
From: Dick Hardt <[email-masked]<mailto:[email-masked]>>
To: Anthony Nadalin <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Bcc:
Date: Wed, 19 Feb 2020 11:35:03 -0800
Subject: Re: [OAUTH-WG] [EXTERNAL]  OAuth 2.1: dropping password grant
Tony: are you ok with dropping password grant?

You reference valid use cases. If you think it should continue, would you provide the use cases?

[Image removed by sender.]ᐧ

On Tue, Feb 18, 2020 at 12:57 PM Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
The security topics says MUST. If you want to change that, then that is a different discussion. :)

In the OAuth 2.1 document, it would just not be included. Applications can continue to be OAuth 2.0 compliant.

BUT ... if there are valid, new use cases. Please describe them! Perhaps it should not be dropped.

On Tue, Feb 18, 2020 at 12:54 PM Anthony Nadalin <[email-masked]<mailto:[email-masked]>> wrote:
I would suggest a SHOULD NOT instead of MUST, there are still sites using this and a grace period should be provided before a MUST is pushed out as there are valid use cases out there still.

From: OAuth <[email-masked]<mailto:[email-masked]>> On Behalf Of Dick Hardt
Sent: Tuesday, February 18, 2020 12:37 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant

Hey List

(Once again using the OAuth 2.1 name as a placeholder for the doc that Aaron, Torsten, and I are working on)

https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.4<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-security-topics-14%23section-2.4&data=02%7C01%7Ctonynad%40microsoft.com%7C47bb597eef584c95ba4108d7b4b274b2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637176550905333283&sdata=nA1S7TBfZg6cSwY2hI8hpRXhIA2joaaJFmNXrATgr2Y%3D&reserved=0>

Some background for those interested. I added this grant into OAuth 2.0 to allow applications that had been provided password to migrate. Even with the caveats in OAuth 2.0, implementors decide they want to prompt the user to enter their credentials, the anti-pattern OAuth was created to eliminate.

Does anyone have concerns with dropping the password grant from the OAuth 2.1 document so that developers don't use it?

/Dick
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth