Subject: [OAUTH-WG] OAuth 2.1 - recalling ROPC

From: Francis Pouatcha <[email-masked]>
Date: Mon, 11 May 2020 23:00:34 -0400

I am against OAuth 2.1 discarding the use of ROPC (Resource Owner Password
Credentials) with the following reasoning:

Auth Code Grant:
There are  many use cases on the market where redirection based flows do
not work. As  we see in the "OAuth 2.1 - require PKCE?" thread, the
complexity of user agents on non controllable client devices still make
user agent redirection a challenge.

Client Credentials Grant:
Requires the registration of an oAuth client.
- Citing the iot device use cases Beena which do not have a comfortable way
to have iot devices register with AS.
- This is a registration flow for the oAuth client role  and for the RO
(Resource Owner). Remember resource owner credentials might be sourced from
system external to the AS  like company's LDAP. oAuth Client Credentials
are generally managed by the AS.
For these reasons, we shall not use Client Credential Grant to manage RO
authorization.

ROPC:
Having an oAuth Client proxy the auth request of the RO to the AS only
presents a security risk if the oAuth Client is a third party application.
Therefore, the decision on whether to accept ROPC for a specified client
shall be left to the AS. Discarding this use case will take a lot of
business from oAuth servers back to the old market.

Beside this, I mentioned in my previous post that there are use cases in
the market where permanent passwords are replaced with one time passwords.

A lot of work is also being done in the direction of having the RO send
signed proof of ownership to the AS through the ROPC  flow using the
password field.

Therefore, I am ok with raising the attention of  implementers the same way
we are doing with PKCE,  mentioning that ROPC  must only be used if  AS /
oAuth Client can guarantee security of the RO credentials exposed to the
oAuth Client.

/Francis
-- 
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/

---

From: Jim Manico <[email-masked]>
Date: Tue, 12 May 2020 09:50:33 -0400

Forgive me if this question is late or poor context, but wouldn’t OIDC be a better replacement for ROPC since it’s essentially a authentication flow?

What use case for ROPC mandates OAuth2 over OIDC?

--
Jim Manico
@Manicode

> On May 11, 2020, at 11:00 PM, Francis Pouatcha <fpo=[email-masked]> wrote:
> 
> 
> I am against OAuth 2.1 discarding the use of ROPC (Resource Owner Password Credentials) with the following reasoning:
> 
> Auth Code Grant:
> There are  many use cases on the market where redirection based flows do not work. As  we see in the "OAuth 2.1 - require PKCE?" thread, the complexity of user agents on non controllable client devices still make user agent redirection a challenge. 
> 
> - Citing the iot device use cases Beena which do not have a comfortable way to have iot devices register with AS.
> - This is a registration flow for the oAuth client role  and for the RO (Resource Owner). Remember resource owner credentials might be sourced from system external to the AS  like company's LDAP. oAuth Client Credentials are generally managed by the AS.
> For these reasons, we shall not use Client Credential Grant to manage RO authorization.
> 
> ROPC:
> Having an oAuth Client proxy the auth request of the RO to the AS only presents a security risk if the oAuth Client is a third party application. Therefore, the decision on whether to accept ROPC for a specified client shall be left to the AS. Discarding this use case will take a lot of business from oAuth servers back to the old market.
> 
> Beside this, I mentioned in my previous post that there are use cases in the market where permanent passwords are replaced with one time passwords.
> 
> A lot of work is also being done in the direction of having the RO send signed proof of ownership to the AS through the ROPC  flow using the password field.
> 
> Therefore, I am ok with raising the attention of  implementers the same way we are doing with PKCE,  mentioning that ROPC  must only be used if  AS / oAuth Client can guarantee security of the RO credentials exposed to the oAuth Client. 
> 
> /Francis
> -- 
> Francis Pouatcha
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Francis Pouatcha <[email-masked]>
Date: Tue, 12 May 2020 13:23:11 -0400

On Tue, May 12, 2020 at 9:50 AM Jim Manico <[email-masked]> wrote:

> Forgive me if this question is late or poor context, but wouldn’t OIDC be
> a better replacement for ROPC since it’s essentially a authentication flow?
>
We are not talking about ROPC mandating  OAuth2, but about OAuth-2.1
forbidding the user of ROPC.

> - Citing the iot device use cases Beena which do not have a comfortable
> way to have iot devices register with AS.
> Therefore, I am ok with raising the attention of  implementers the same
> way we are doing with PKCE,  mentioning that ROPC  must only be used if  AS
> / oAuth Client can guarantee security of the RO credentials exposed to the
> oAuth Client.
>
> /Francis
> --
> Francis Pouatcha

---

From: Jim Manico <[email-masked]>
Date: Tue, 12 May 2020 13:44:58 -0400

> We are not talking about ROPC mandating  OAuth2, but about OAuth-2.1 forbidding the user of ROPC.

Absolutely and this seems like a good thing. ROPC seems very close to a use case that calls for OIDC instead of a OAuth2x token so I endorse the move.

--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On May 12, 2020, at 1:23 PM, Francis Pouatcha <[email-masked]> wrote:
> 
> 
> 
> 
> We are not talking about ROPC mandating  OAuth2, but about OAuth-2.1 forbidding the user of ROPC.
> 
>> 
>> --
>> Jim Manico
>> @Manicode
>>

---

From: Aaron Parecki <[email-masked]>
Date: Tue, 12 May 2020 11:19:10 -0700

Keep in mind that while the Security BCP explicitly forbids the use of the
Password grant in OAuth 2.0, technically OAuth 2.1 just never includes it
in the first place. Subtle difference.

Aaron Parecki

On Tue, May 12, 2020 at 10:23 AM Francis Pouatcha <fpo=
[email-masked]> wrote:

>> I am against OAuth 2.1 discarding the use of ROPC (Resource Owner
>> Password Credentials) with the following reasoning:
>>
>> Auth Code Grant:
>> not work.. As  we see in the "OAuth 2.1 - require PKCE?" thread, the

---

From: Falk Andreas <[email-masked]>
Date: Tue, 12 May 2020 19:50:28 +0000

> Keep in mind that while the Security BCP explicitly forbids the use of the Password grant in OAuth 2.0, technically OAuth 2.1 just never includes it in the first place. Subtle difference.

As RFC 6749 clearly targets third-party applications, ROPC never has been a good fit.  It always felt like a bad workaround just for legacy applications.

I am primarily looking at OAuth 2.1 from a developer's perspective. Unfortunately, developers often look for a shortcut and the easiest way to implement a required use case.

You can find many entries on StackOverflow directing developers to use ROPC instead of a "complicated" redirection flow.

Frameworks like Spring Security or Angular clearly follow a "secure by default" approach, this may also be a good direction to follow in future specifications.

As Jim already pointed out, I also consider the ROPC being an authentication flow (for trusted first-party applications) and this use case is covered by OIDC.

Same as for PKCE an AS may still provide ROPC in an OAuth 2.0 compatibility mode to not break existing apps.

That is why I support OAuth 2.1 omitting ROPC.

Andreas Falk

________________________________
From: OAuth <[email-masked]> on behalf of Aaron Parecki <[email-masked]>
Sent: 12 May 2020 20:19
To: Francis Pouatcha
Cc: OAuth WG
Subject: Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC

> We are not talking about ROPC mandating  OAuth2, but about OAuth-2.1 forbidding the user of ROPC.

Keep in mind that while the Security BCP explicitly forbids the use of the Password grant in OAuth 2.0, technically OAuth 2.1 just never includes it in the first place. Subtle difference.

Aaron Parecki

On Tue, May 12, 2020 at 10:23 AM Francis Pouatcha <fpo=[email-masked]<mailto:[email-masked]>> wrote:

On Tue, May 12, 2020 at 9:50 AM Jim Manico <[email-masked]<mailto:[email-masked]>> wrote:
Forgive me if this question is late or poor context, but wouldn’t OIDC be a better replacement for ROPC since it’s essentially a authentication flow?

--
Jim Manico
@Manicode

On May 11, 2020, at 11:00 PM, Francis Pouatcha <fpo=[email-masked]<mailto:[email-masked]>> wrote:

Auth Code Grant:
There are  many use cases on the market where redirection based flows do not work.. As  we see in the "OAuth 2.1 - require PKCE?" thread, the complexity of user agents on non controllable client devices still make user agent redirection a challenge.

ROPC:

/Francis
[email-masked]<mailto:[email-masked]>

[email-masked]<mailto:[email-masked]>

---

From: Phillip Hunt <[email-masked]>
Date: Tue, 12 May 2020 14:38:50 -0700

One of the use cases brought up in the ROPC thread mentioned that redirect was hard to do in some cases (like IoT). This reminded me of RFC8628, the OAuth Device Authorization Grant. I mention it because for *some* of the cases who say redirection is hard may be able to use the Device Authz Grant.

Would it be worth including a section in OAuth 2.1 referencing RFC8628 or, possibly incorporating it?

Phil Hunt
@independentid
[email-masked]

---

From: Aaron Parecki <[email-masked]>
Date: Tue, 12 May 2020 14:44:09 -0700

I have a draft I'm about to publish after our recent discussions. One of
the changes is adding an appendix that lists out a bunch of existing OAuth
extensions, and the device grant is in there. I also replaced the
"Extension Grants" example in section 4.3 (
https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02#section-4.3) with
the device grant since that is deployed far wider than the SAML Assertion
grant that was in that example in RFC6749. This will be published as
version -03 in the next few days. Do you think that would be enough?

Aaron Parecki

On Tue, May 12, 2020 at 2:39 PM Phillip Hunt <[email-masked]>
wrote:

> One of the use cases brought up in the ROPC thread mentioned that redirect
> was hard to do in some cases (like IoT). This reminded me of RFC8628, the
> OAuth Device Authorization Grant. I mention it because for *some* of the
> cases who say redirection is hard may be able to use the Device Authz Grant.
>

---

From: Francis Pouatcha <[email-masked]>
Date: Tue, 12 May 2020 23:15:44 -0400

The draft  draft-parecki-oauth-v2-1-02 mentions in the abstract:
"This specification replaces and obsoletes the OAuth 2.0
Authorization Framework described in RFC 6749."  Believe me we will witness
a lot of client calls asking for the replacement of ROPC  flows.

There is no way we can omit ROPC without providing an equivalent
alternative (From the perspective of simplicity). Even with the exact match
of redirect-uri included in oAuth-2.1, there is still a lot of hazard
associated with redirection on a user controlled device. The security BCP
(draft-ietf-oauth-security-topics-15) is still far from covering all use
cases as there are too many parameters involved in the redirection thread
models, as redirect-uri travel  through client devices, as client device
operating system decides which url get forwarded to which user agent, as
user default web browser might change in the course of a redirection flow,
...

The only really secure relationship between a user agent and a server is a
one  time established connection in which the user (RO) in control of
that user agent instance can prove ownership of some credentials without
leaving the context of the loaded application loaded by that user agent. In
oAuth2.0 this behavior is only guaranteed by the ROPC flow (Client
credential flow not being considered an end user flow). Each flow requiring
redirection leads to offloading and reloading of the application context of
the resource owner in the target user agent. User device configuration
might lead to reload in a different user agent leading to more confusion.

RFC8628 does not solve the problem. Once again, it is essential to
distinguish between an oAuth Client and a resource owner (RO). Resource
owner authorization flows can not be replaced by oAuth client
authorizations flows. Even if the oAuth Client runs on the user devices. It
is essential from AS to distinguish between client credentials  and
resource owner credentials, else we will break a lot of authorization
models out there.

As we do not have an equivalent alternative for ROPC, we have to raise the
attention of  implementers by mentioning that ROPC  must only be used if
AS / oAuth Client can guarantee security of the RO credentials exposed to
the oAuth Client. Without this, oAuth2.1 can not be a replacement of
oAuth2.0 but just a security BCP.

Related Topic:
We can have a better theoretical analysis of redirection thread models, if
oAuth2.1 includes draft-ietf-oauth-par-01. As this will solidify
redirection based approaches by limiting the quantity of information pushed
by oAuth Client over client devices to AS.

The oAuth2.1 as presented now is still not secure enough to replace
oAuth2.0-ROPX and not secure enough to be accepted in some critical
environments. In order to increase acceptance:
- Include ROPC  with provision/warning on sharing RO password with oAuth
Client.
- Include PAR to solidify redirection based flow.

On Tue, May 12, 2020 at 3:50 PM Falk Andreas <[email-masked]>
wrote:

> > Keep in mind that while the Security BCP explicitly forbids the use of
> the Password grant in OAuth 2.0, technically OAuth 2.1 just never includes
> it in the first place. Subtle difference.
>
>
> As RFC 6749 clearly targets third-party applications, ROPC never has been
> a good fit.  It always felt like a bad workaround just for legacy
> applications.
>
>
> I am primarily looking at OAuth 2.1 from a developer's perspective.
> Unfortunately, developers often look for a shortcut and the easiest way to
> implement a required use case.
>
> You can find many entries on StackOverflow directing developers to use
> ROPC instead of a "complicated" redirection flow.
>
> Frameworks like Spring Security or Angular clearly follow a "secure by
> default" approach, this may also be a good direction to follow in future
> specifications.
>
>
> As Jim already pointed out, I also consider the ROPC being an
> authentication flow (for trusted first-party applications) and this use
> case is covered by OIDC.
>
>
> Same as for PKCE an AS may still provide ROPC in an OAuth 2.0
> compatibility mode to not break existing apps.
>
>
> ------------------------------
> *From:* OAuth <[email-masked]> on behalf of Aaron Parecki <
> [email-masked]>
> *Sent:* 12 May 2020 20:19
> *To:* Francis Pouatcha
> *Cc:* OAuth WG
> *Subject:* Re: [OAUTH-WG] OAuth 2.1 - recalling ROPC
>
>>> Forgive me if this question is late or poor context, but wouldn’t OIDC
>>> be a better replacement for ROPC since it’s essentially a authentication
>>> flow?
>>>