Subject: [OAUTH-WG] OAuth 2.1: dropping password grant

From: Dick Hardt <[email-masked]>
Date: Tue, 18 Feb 2020 12:37:26 -0800

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

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

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 18 Feb 2020 20:54:14 +0000

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)

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

---

From: Dick Hardt <[email-masked]>
Date: Tue, 18 Feb 2020 12:57:19 -0800

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
>
>
>
> <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>
>
>
>

---

From: Justin Richer <[email-masked]>
Date: Tue, 18 Feb 2020 16:15:36 -0500

There is no need for a grace period. People using OAuth 2.0 can still do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1. 

 — Justin

> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin <tonynad=[email-masked]> wrote:
> 
> 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>
>  
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Phillip Hunt <[email-masked]>
Date: Tue, 18 Feb 2020 13:28:16 -0800

I do recall password flow was only in 6749 to facilitate transition to oauth. Maybe it is reasonable to consider ending it now.

Phil

> On Feb 18, 2020, at 1:15 PM, Justin Richer <[email-masked]> wrote:
>

---

From: Aaron Parecki <[email-masked]>
Date: Tue, 18 Feb 2020 13:43:37 -0800

Agreed. Plus, the Security BCP is already effectively acting as a grace
period since it currently says the password grant MUST NOT be used, so in
the OAuth 2.0 world that's already a pretty strong signal.

Aaron

On Tue, Feb 18, 2020 at 4:16 PM Justin Richer <[email-masked]> wrote:

> There is no need for a grace period. People using OAuth 2.0 can still do
> OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1.
>
>  — Justin
>
> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin <
> tonynad=[email-masked]> wrote:
>
> *From:* OAuth <[email-masked]> *On Behalf Of *Dick Hardt
-- 
----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>

---

From: Hans Zandbelt <[email-masked]>
Date: Tue, 18 Feb 2020 22:57:33 +0100

I would also seriously look at the original motivation behind ROPC: I know
it has been deployed and is used in quite a lot of places but I have never
actually come across a use case where it is used for migration purposes and
the migration is actually executed (I know that is statistically not a very
strong argument but I challenge others to come up with one...)
In reality it turned out just to be a one off that people used as an easy
way out to stick to an anti-pattern and still claim to do OAuth 2.0. It is
plain wrong, it is not OAuth and we need to get rid of it.

Hans.

On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki <[email-masked]> wrote:

>> 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

-- 
[email-masked]
ZmartZone IAM - www.zmartzone.eu

---

From: Dick Hardt <[email-masked]>
Date: Wed, 19 Feb 2020 11:35:03 -0800

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:

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

---

From: Neil Madden <[email-masked]>
Date: Wed, 19 Feb 2020 21:03:03 +0000

I very much agree with this with regards to real users. 

The one legitimate use-case for ROPC I’ve seen is for service accounts - where you essentially want something like client_credentials but for whatever reason you need the RO to be a service user rather than an OAuth2 client (typically so that some lower layer of the system can still perform its required permission checks).

There are better grant types for this - e.g. JWT bearer - but they are a bit harder to implement. Having recently converted some code from ROPC to JWT bearer for exactly this use-case, it went from a couple of lines of code to two screens of code. For service to service API calls within a datacenter I’m not convinced this resulted in a material increase in security for the added complexity.

— Neil

> On 18 Feb 2020, at 21:57, Hans Zandbelt <[email-masked]> wrote:
> 
> I would also seriously look at the original motivation behind ROPC: I know it has been deployed and is used in quite a lot of places but I have never actually come across a use case where it is used for migration purposes and the migration is actually executed (I know that is statistically not a very strong argument but I challenge others to come up with one...)
> In reality it turned out just to be a one off that people used as an easy way out to stick to an anti-pattern and still claim to do OAuth 2.0. It is plain wrong, it is not OAuth and we need to get rid of it.
> 
> Hans.
> 
> Agreed. Plus, the Security BCP is already effectively acting as a grace period since it currently says the password grant MUST NOT be used, so in the OAuth 2.0 world that's already a pretty strong signal.
> 
> Aaron
> 
> 
> 
> @aaronpk

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 19 Feb 2020 22:35:17 +0100

Can you explain more in detail why the client credentials grant type isn’t applicable for the kind of use cases you mentioned?

> Am 19.02.2020 um 22:03 schrieb Neil Madden <[email-masked]>:
>

---

From: "Brock Allen" <[email-masked]>
Date: Wed, 19 Feb 2020 16:43:18 -0500

I've seen the same. People have user-centric authorization systems where they have a "service user" that they attach permissions to. In client credentials they don't want to have to special case a client credentials caller (vs. a code flow client) and instead just use the calling "user" to look up permissions.

-Brock

On 2/19/2020 4:35:43 PM, Torsten Lodderstedt <torsten=[email-masked]> wrote:
Can you explain more in detail why the client credentials grant type isn’t applicable for the kind of use cases you mentioned?

> Am 19.02.2020 um 22:03 schrieb Neil Madden :
>
>> On 18 Feb 2020, at 21:57, Hans Zandbelt wrote:
>>
>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki wrote:
>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer wrote:
>>>> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin wrote:
>>>
>>> From: OAuth On Behalf Of Dick Hardt

---

From: Neil Madden <[email-masked]>
Date: Wed, 19 Feb 2020 21:52:45 +0000

OAuth2 clients are often private to the AS - they live in a database that only the AS can access, have attributes specific to their use in OAuth2, and so on. Many existing systems have access controls based on users, roles, permissions and so on and expect all users accessing the system to exist in some user repository, e.g. LDAP, where they can be looked up and appropriate permissions determined. A service account can be created inside such a system as if it was a regular user, managed through the normal account provisioning tools, assigned permissions, roles, etc.

Another reason is that sometimes OAuth is just one authentication option out of many, and so permissions assigned to service accounts are preferred over scopes because they are consistently applied no matter how a request is authenticated. This is often the case when OAuth has been retrofitted to an existing system and they need to preserve compatibility with already deployed clients.

See e.g. Google cloud platform (GCP): https://developers.google.com/identity/protocols/OAuth2ServiceAccount
They use the JWT bearer grant type for service account authentication and assign permissions to those service accounts and typically have very broad scopes. For service-to-service API calls you typically get an access token with a single scope that is effectively “all of GCP” and everything is managed at the level of permissions on the RO service account itself. They only break down fine-grained scopes when you are dealing with user data and will be getting an access token approved by a real user (through a normal auth code flow).

— Neil

> On 19 Feb 2020, at 21:35, Torsten Lodderstedt <[email-masked]> wrote:
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 19 Feb 2020 22:00:52 +0000

An AS can define client IDs that are specific to a service account. I.e., Service Account A has client ID 1234..., Service Account B has client ID 5678.... This appears to be what Google is doing. From there, the AS could implement whatever client authentication mechanism it wants to: client secret, mTLS, JWT bearer, etc.

–
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/

On 2/19/20, 1:54 PM, "OAuth on behalf of Neil Madden" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    — Neil

---

From: Dick Hardt <[email-masked]>
Date: Wed, 19 Feb 2020 14:01:53 -0800

Neil: are you advocating that password grant be preserved in 2.1? Or do you
think that service account developers know enough about what they are doing
to follow what is in 6749?
ᐧ

On Wed, Feb 19, 2020 at 1:52 PM Neil Madden <[email-masked]>
wrote:

> OAuth2 clients are often private to the AS - they live in a database that
> only the AS can access, have attributes specific to their use in OAuth2,
> and so on. Many existing systems have access controls based on users,
> roles, permissions and so on and expect all users accessing the system to
> exist in some user repository, e.g. LDAP, where they can be looked up and
> appropriate permissions determined. A service account can be created inside
> such a system as if it was a regular user, managed through the normal
> account provisioning tools, assigned permissions, roles, etc.
>
> Another reason is that sometimes OAuth is just one authentication option
> out of many, and so permissions assigned to service accounts are preferred
> over scopes because they are consistently applied no matter how a request
> is authenticated. This is often the case when OAuth has been retrofitted to
> an existing system and they need to preserve compatibility with already
> deployed clients.
>
> See e.g. Google cloud platform (GCP):
> https://developers.google.com/identity/protocols/OAuth2ServiceAccount
> They use the JWT bearer grant type for service account authentication and
> assign permissions to those service accounts and typically have very broad
> scopes. For service-to-service API calls you typically get an access token
> with a single scope that is effectively “all of GCP” and everything is
> managed at the level of permissions on the RO service account itself. They
> only break down fine-grained scopes when you are dealing with user data and
> will be getting an access token approved by a real user (through a normal
> auth code flow).
>
> — Neil
>
> > Can you explain more in detail why the client credentials grant type
> isn’t applicable for the kind of use cases you mentioned?
> >
> >> The one legitimate use-case for ROPC I’ve seen is for service accounts
> - where you essentially want something like client_credentials but for
> whatever reason you need the RO to be a service user rather than an OAuth2
> client (typically so that some lower layer of the system can still perform
> its required permission checks).
> >>
> >> There are better grant types for this - e.g. JWT bearer - but they are
> a bit harder to implement. Having recently converted some code from ROPC to
> JWT bearer for exactly this use-case, it went from a couple of lines of
> code to two screens of code. For service to service API calls within a
> datacenter I’m not convinced this resulted in a material increase in
> security for the added complexity.
> >>
> >> — Neil
> >>
> >>> I would also seriously look at the original motivation behind ROPC: I
> know it has been deployed and is used in quite a lot of places but I have
> never actually come across a use case where it is used for migration
> purposes and the migration is actually executed (I know that is
> statistically not a very strong argument but I challenge others to come up
> with one...)
> >>> In reality it turned out just to be a one off that people used as an
> easy way out to stick to an anti-pattern and still claim to do OAuth 2.0.
> It is plain wrong, it is not OAuth and we need to get rid of it.
> >>>
> >>> Hans.
> >>>
> >>> Agreed. Plus, the Security BCP is already effectively acting as a
> grace period since it currently says the password grant MUST NOT be used,
> so in the OAuth 2.0 world that's already a pretty strong signal.
> >>>
> >>> Aaron
> >>>
> >>>
> >>>
> >>> There is no need for a grace period. People using OAuth 2.0 can still
> do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1.
> >>>
> >>> — Justin
> >>>
> >>>> 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.
> >>>>
> >>>> (Once again using the OAuth 2.1 name as a placeholder for the doc
> that Aaron, Torsten, and I are working on)
> >>>>
> >>>> 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

---

From: Neil Madden <[email-masked]>
Date: Wed, 19 Feb 2020 22:41:52 +0000

I have a feeling that if we had more concise JWT libraries and command line tools, where using the JWT Bearer grant became a one-liner again then we wouldn’t be having this conversation. So perhaps removing it is an incentive to make that happen.

> On 19 Feb 2020, at 22:01, Dick Hardt <[email-masked]> wrote:
> 
> Neil: are you advocating that password grant be preserved in 2.1? Or do you think that service account developers know enough about what they are doing to follow what is in 6749?
> ᐧ
> 
> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden <[email-masked]> wrote:

---

From: Matthew De Haast <[email-masked]>
Date: Fri, 21 Feb 2020 15:41:36 +0200

>
> I have a feeling that if we had more concise JWT libraries and command
> line tools, where using the JWT Bearer grant became a one-liner again then
> we wouldn’t be having this conversation. So perhaps removing it is an
> incentive to make that happen.
>

Neil could you elaborate more on this please. What failures are you
currently experiencing/seeing with the JWT Bearer grant?

Matt

On Thu, Feb 20, 2020 at 12:42 AM Neil Madden <[email-masked]>
wrote:

> I have a feeling that if we had more concise JWT libraries and command
> line tools, where using the JWT Bearer grant became a one-liner again then
> we wouldn’t be having this conversation. So perhaps removing it is an
> incentive to make that happen.
>
>
> > Neil: are you advocating that password grant be preserved in 2.1? Or do
> you think that service account developers know enough about what they are
> doing to follow what is in 6749?
> > ᐧ
> >
> > OAuth2 clients are often private to the AS - they live in a database
> that only the AS can access, have attributes specific to their use in
> OAuth2, and so on. Many existing systems have access controls based on
> users, roles, permissions and so on and expect all users accessing the
> system to exist in some user repository, e.g. LDAP, where they can be
> looked up and appropriate permissions determined. A service account can be
> created inside such a system as if it was a regular user, managed through
> the normal account provisioning tools, assigned permissions, roles, etc.
> >
> > They use the JWT bearer grant type for service account authentication
> and assign permissions to those service accounts and typically have very
> broad scopes. For service-to-service API calls you typically get an access
> token with a single scope that is effectively “all of GCP” and everything
> is managed at the level of permissions on the RO service account itself.
> They only break down fine-grained scopes when you are dealing with user
> data and will be getting an access token approved by a real user (through a
> normal auth code flow).
> >
> > — Neil
> >
> > >> Am 19.02.2020 um 22:03 schrieb Neil Madden <[email-masked]
> >:
> > >>
> > >> The one legitimate use-case for ROPC I’ve seen is for service
> accounts - where you essentially want something like client_credentials but
> for whatever reason you need the RO to be a service user rather than an
> OAuth2 client (typically so that some lower layer of the system can still
> perform its required permission checks).
> > >>
> > >> There are better grant types for this - e.g. JWT bearer - but they
> are a bit harder to implement. Having recently converted some code from
> ROPC to JWT bearer for exactly this use-case, it went from a couple of
> lines of code to two screens of code. For service to service API calls
> within a datacenter I’m not convinced this resulted in a material increase
> in security for the added complexity.
> > >>
> > >> — Neil
> > >>
> > >>> I would also seriously look at the original motivation behind ROPC:
> I know it has been deployed and is used in quite a lot of places but I have
> > >>> There is no need for a grace period. People using OAuth 2.0 can
> still do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1.
> > >>>
> > >>> — Justin
> > >>>

---

From: Neil Madden <[email-masked]>
Date: Fri, 21 Feb 2020 14:12:06 +0000

No failures, but it is a much more complex grant type to set up, when you consider everything you have to do:

* work out if the AS even supports JWT bearer and how to turn it on
* work out how to configure the AS to trust my public key(s)
  - do I have to create a new HTTPS endpoint to publish a JWK Set?
* determine the correct settings for issuer, audience, subject, etc. Does the AS impose non-standard requirements? e.g. RFC 7523 says that the JWT MUST contain a “sub” claim, but Google only allows this to be present if your client is doing impersonation of an end-user (which requires additional permissions).
* do I need a unique “jti” claim? (OIDC servers do, plain OAuth ones might not) If I do, can I reuse the JWT or must it be freshly signed for every call?
* locate and evaluate a JWT library for my language of choice. Monitor that new dependency for security advisories.
* choose a suitable signature algorithm (‘ere be dragons)
* figure out how to distribute the private key to my service

Compared to “create a service account and POST the username and password to the token endpoint” it adds a little friction. (It also adds a lot of advantages, but it is undeniably more complex).

— Neil

> On 21 Feb 2020, at 13:41, Matthew De Haast <matt=[email-masked]> wrote:
> 
> Neil could you elaborate more on this please. What failures are you currently experiencing/seeing with the JWT Bearer grant? 
> 
> Matt
> 
> On Thu, Feb 20, 2020 at 12:42 AM Neil Madden <[email-masked]> wrote:
> > >>> Agreed. Plus, the Security BCP is already effectively acting as a grace period since it currently says the password grant MUST NOT be used, so in the OAuth 2.0 world that's already a pretty strong signal..
> > >>> 
> > >>> Aaron
> > >>> 
> > >>> 
> > >>> 
> > >>> There is no need for a grace period. People using OAuth 2..0 can still do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1. 
> > >>> 
> > >>> — Justin
> > >>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 21 Feb 2020 15:20:42 +0100

Have you ever tried the client credentials grant with mTLS? After reading your description it seems to be simpler than JWT Bearer.

* work out if the AS even supports mTLS
* work out how to configure the AS to trust my cert(s)
* Create key pair and cert using openssl
* Register your (self-signed) cert along with your client_id
* Configure the HTTP client to use your key pair for TLS Client Authentication

Works very well for us. 

> On 21. Feb 2020, at 15:12, Neil Madden <[email-masked]> wrote:
>

---

From: Neil Madden <[email-masked]>
Date: Fri, 21 Feb 2020 14:31:34 +0000

Yes, that is great. But mTLS doesn’t support service accounts (!= clients). Maybe it should? Should there be a mTLS *grant type*?

— Neil

> On 21 Feb 2020, at 14:20, Torsten Lodderstedt <[email-masked]> wrote:
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 21 Feb 2020 15:34:36 +0100

I see - we have gone full cycle :-) 

Annabelle’s proposal would solve that. Relate a client id to a service account and obtain the token data from there. 

> On 21. Feb 2020, at 15:31, Neil Madden <[email-masked]> wrote:
>

---

From: Neil Madden <[email-masked]>
Date: Fri, 21 Feb 2020 14:47:22 +0000

Sorry, I missed that message. 

While this may be a solution in specific circumstances, I don’t think it’s a general solution. e.g. an AS may not allow manually choosing the client_id to avoid things like https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.13 or may return different introspection results for client credentials tokens (e.g. with no “sub”) and so on. In practice, this adds even more steps for somebody to migrate from existing ROPC usage.

This is asking people to make fundamental changes to their identity architecture rather than simply switching to a new grant type.

— Neil

> On 21 Feb 2020, at 14:34, Torsten Lodderstedt <[email-masked]> wrote:
>

---

From: Levi Schuck <[email-masked]>
Date: Fri, 21 Feb 2020 08:50:05 -0600

Hello,

I am new to the mailing list.
I support a mTLS grant type.

Client certificate and additional credentials in the request seems
redundant.

While using GCP, the flow seems to be signing a JWT with a private key
known to google, which is then exchanged for a google signed JWT. Beyond
the service account name being included in the JWT, there are no other
credentials exchanged. This flow matches what I read in 7523.

However, the GCP service account JWT exchange also carries the declared
scopes the service account may use. The AS seems to validate these scopes
before issuing a google signed JWT.

Perhaps a mTLS grant exchange can use alg: none as a JWT for a client
assertion, as JWTs already have conventions to include scopes. Or have
another assertion type altogether.

-Levi

On Fri, Feb 21, 2020 at 8:47 AM Neil Madden <[email-masked]>
wrote:

> While this may be a solution in specific circumstances, I don’t think it’s
> a general solution. e.g. an AS may not allow manually choosing the
> client_id to avoid things like
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.13
> or may return different introspection results for client credentials tokens
> (e.g. with no “sub”) and so on. In practice, this adds even more steps for
> somebody to migrate from existing ROPC usage.
>
> This is asking people to make fundamental changes to their identity
> architecture rather than simply switching to a new grant type.
>
> — Neil
>
> > Annabelle’s proposal would solve that. Relate a client id to a service
> account and obtain the token data from there.
> >
> >> Yes, that is great. But mTLS doesn’t support service accounts (!=
> clients). Maybe it should? Should there be a mTLS *grant type*?
> >>
> >> — Neil
> >>
> >>> Have you ever tried the client credentials grant with mTLS? After
> reading your description it seems to be simpler than JWT Bearer.
> >>>
> >>>> * determine the correct settings for issuer, audience, subject, etc.
> Does the AS impose non-standard requirements? e.g. RFC 7523 says that the
> JWT MUST contain a “sub” claim, but Google only allows this to be present
> if your client is doing impersonation of an end-user (which requires
> additional permissions).
> >>>> * do I need a unique “jti” claim? (OIDC servers do, plain OAuth ones
> might not) If I do, can I reuse the JWT or must it be freshly signed for
> every call?
> >>>> * locate and evaluate a JWT library for my language of choice.
> Monitor that new dependency for security advisories.
> >>>> Compared to “create a service account and POST the username and
> password to the token endpoint” it adds a little friction. (It also adds a
> lot of advantages, but it is undeniably more complex).
> >>>>
> >>>> — Neil
> >>>>
> >>>>
> >>>>> I have a feeling that if we had more concise JWT libraries and
> command line tools, where using the JWT Bearer grant became a one-liner
> again then we wouldn’t be having this conversation. So perhaps removing it
> is an incentive to make that happen.
> >>>>>
> >>>>> I have a feeling that if we had more concise JWT libraries and
> command line tools, where using the JWT Bearer grant became a one-liner
> again then we wouldn’t be having this conversation. So perhaps removing it
> is an incentive to make that happen.
> >>>>>
> >>>>>
> >>>>>> Neil: are you advocating that password grant be preserved in 2.1?
> Or do you think that service account developers know enough about what they
> are doing to follow what is in 6749?
> >>>>>> ᐧ
> >>>>>>
> >>>>>> OAuth2 clients are often private to the AS - they live in a
> database that only the AS can access, have attributes specific to their use
> in OAuth2, and so on. Many existing systems have access controls based on
> >>>>>> Another reason is that sometimes OAuth is just one authentication
> option out of many, and so permissions assigned to service accounts are
> preferred over scopes because they are consistently applied no matter how a
> request is authenticated. This is often the case when OAuth has been
> retrofitted to an existing system and they need to preserve compatibility
> with already deployed clients.
> >>>>>>
> >>>>>> They use the JWT bearer grant type for service account
> authentication and assign permissions to those service accounts and
> typically have very broad scopes. For service-to-service API calls you
> typically get an access token with a single scope that is effectively “all
> of GCP” and everything is managed at the level of permissions on the RO
> service account itself. They only break down fine-grained scopes when you
> are dealing with user data and will be getting an access token approved by
> a real user (through a normal auth code flow).
> >>>>>>
> >>>>>> — Neil
> >>>>>>
> >>>>>>> Can you explain more in detail why the client credentials grant
> type isn’t applicable for the kind of use cases you mentioned?
> >>>>>>>
> >>>>>>>> There are better grant types for this - e.g. JWT bearer - but
> they are a bit harder to implement. Having recently converted some code
> from ROPC to JWT bearer for exactly this use-case, it went from a couple of
> >>>>>>>>> I would also seriously look at the original motivation behind
> ROPC: I know it has been deployed and is used in quite a lot of places but
> I have never actually come across a use case where it is used for migration
> >>>>>>>>> In reality it turned out just to be a one off that people used
> as an easy way out to stick to an anti-pattern and still claim to do OAuth
> 2.0. It is plain wrong, it is not OAuth and we need to get rid of it.
> >>>>>>>>>
> >>>>>>>>> Hans.
> >>>>>>>>>
> >>>>>>>>> Agreed. Plus, the Security BCP is already effectively acting as
> a grace period since it currently says the password grant MUST NOT be used,
> so in the OAuth 2.0 world that's already a pretty strong signal..
> >>>>>>>>>
> >>>>>>>>> Aaron
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> There is no need for a grace period. People using OAuth 2..0 can
> >>>>>>>>>> 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.
> >>>>>>>>>>
> >>>>>>>>>> (Once again using the OAuth 2.1 name as a placeholder for the
> doc that Aaron, Torsten, and I are working on)
> >>>>>>>>>>
> >>>>>>>>>> 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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 21 Feb 2020 15:54:53 +0100

> On 21. Feb 2020, at 15:47, Neil Madden <[email-masked]> wrote:
> 

I don’t see this as a fundamental change, it adds another claim/permission source to a client id.

>  https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-4.13

This can be solved by either using the id of the service account as sub or even put the service identity into a dedicated realm. We implemented the later strategy at Deutsche Telekom couple of yrs ago.

---

From: Neil Madden <[email-masked]>
Date: Fri, 21 Feb 2020 15:02:52 +0000

But we’re talking about existing deployments. Are you suggesting that people should bulk rename all of their clients to match the service accounts (or vice-versa)? 

— Neil

> On 21 Feb 2020, at 14:54, Torsten Lodderstedt <[email-masked]> wrote:
> 
> 
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 21 Feb 2020 16:25:07 +0100

It’s difficult to give advise without lot of detailed information. I nevertheless give it a try.

Mechanically, the application would need to use a different grant, credential instead of ROPC. If such an application today already uses a distinct client_id, the AS must be set up to relate this client_id and the service account the same app used before directly. With that the respective deployment is able to leverage all client authentication methods, including mTLS.

> On 21. Feb 2020, at 16:02, Neil Madden <[email-masked]> wrote:
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 21 Feb 2020 20:28:46 +0000

The client IDs can still be opaque identifiers provided by the AS, they just happen to be associated with specific service accounts. Or they could be the opaque IDs that the AS already issued for the service account. Either way, the AS could issue a token with the appropriate subject and other claims for the service account.

If your client identity is bound to a specific service account identity (i.e., the resource owner), then ROPC reduces down to Client Credentials. What's the point in passing two identifiers and two credentials for the same identity?

–

On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    — Neil

---

From: Justin Richer <[email-masked]>
Date: Fri, 21 Feb 2020 16:04:23 -0500

+1. I’ve seen this anti-pattern deployed all over the place, and it’s time to get rid of it and send people toward what they really ought to be doing.

Another thing I’ve seen is using different service accounts to get different sets of access for one client — if you’re doing that, you’ve got a client pretending to do two different things, or your APIs should be using scopes to differentiate access instead of client/user identity. 

 — Justin

> On Feb 21, 2020, at 3:28 PM, Richard Backman, Annabelle <richanna=[email-masked]> wrote:
>

---

From: Neil Madden <[email-masked]>
Date: Fri, 21 Feb 2020 21:52:56 +0000

The AS doesn’t issue the service account IDs, that’s the whole point - integration with existing systems. Lot’s of people don’t have the luxury of rebuilding systems from scratch to fit in with the preferences of the OAuth WG.

ROPC doesn’t require client authentication, or even a client identifier. If you’re using a service account you indeed don’t need to bother issuing client credentials. The same is true when using the JWT bearer grant. If you want to increase security you can use cert-bound access tokens.

> On 21 Feb 2020, at 20:28, Richard Backman, Annabelle <[email-masked]> wrote:
>

---

From: Neil Madden <[email-masked]>
Date: Fri, 21 Feb 2020 22:31:40 +0000

I’m not really sure the WG should be telling people what they “ought to be doing” unless we have concrete security or interoperability reasons for doing so.

I also don’t agree that people doing this are doing anything wrong. I don’t always agree with what our customers do, but I’ve learnt over the years not to second-guess their reasons for doing it.

Are Google wrong for using the JWT bearer grant (not client credentials) and service accounts? They even go so far as to say “scopes are not a security mechanism” [1] and tell people to use service account roles instead. (Precisely because they also support non-OAuth auth methods, which bypass any scopes).

Are we really going to tell them to rewrite it all to use the client credentials grant?

[1]: https://cloud.google.com/compute/docs/access/service-accounts#accesscopesiam

> On 21 Feb 2020, at 21:04, Justin Richer <[email-masked]> wrote:
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Sat, 22 Feb 2020 01:05:20 +0000

ROPC without a client ID or authentication is functionally equivalent to Client Credentials grant with client secret authentication in the request body. You've just renamed "client_id" to "username" and "client_secret" to "password".

The AS simply needs to be able to resolve the client ID to the service account. You could use any of the following strategies, depending on the environment:
* Use service account identifiers as client IDs
* Use encrypted blobs containing service account identifiers as client IDs, so someone can't choose a client ID by creating a service account with a specific identifier
* Use opaque values that the AS can resolve to service account identifiers, e.g., via a database lookup

If the AS needs the service account's password because it's authenticating against a legacy system, then use the service account password as the client secret. Stack mTLS on top, if you want. If the AS just needs to resolve the account so it can put it in tokens that RSes will look at, then you can use whatever client authentication mechanism you want.

Is there a scenario I'm missing here?

–

On 2/21/20, 1:53 PM, "Neil Madden" <[email-masked]> wrote:

---

From: Dick Hardt <[email-masked]>
Date: Fri, 21 Feb 2020 17:41:21 -0800

I'm a little confused on where this thread is going. If we take ROPC out of
OAuth 2.1 then:

1) Existing deployments can keep using ROPC - why break it if it is working.

2) New deployments can use ROPC and be OAuth 2.0 compliant.

3) New deployments that don't need ROPC can be OAuth 2.1 compliant

ᐧ

On Fri, Feb 21, 2020 at 5:05 PM Richard Backman, Annabelle <richanna=
[email-masked]> wrote:

> ROPC without a client ID or authentication is functionally equivalent to
> Client Credentials grant with client secret authentication in the request
> body. You've just renamed "client_id" to "username" and "client_secret" to
> "password".
>
> The AS simply needs to be able to resolve the client ID to the service
> account. You could use any of the following strategies, depending on the
> environment:
> * Use encrypted blobs containing service account identifiers as client
> IDs, so someone can't choose a client ID by creating a service account with
> a specific identifier
> If the AS needs the service account's password because it's authenticating
> against a legacy system, then use the service account password as the
> client secret. Stack mTLS on top, if you want. If the AS just needs to
> resolve the account so it can put it in tokens that RSes will look at, then
> you can use whatever client authentication mechanism you want.
>
>     The AS doesn’t issue the service account IDs, that’s the whole point -
> integration with existing systems. Lot’s of people don’t have the luxury of
> rebuilding systems from scratch to fit in with the preferences of the OAuth
> WG.
>
>     ROPC doesn’t require client authentication, or even a client
> identifier. If you’re using a service account you indeed don’t need to
> bother issuing client credentials. The same is true when using the JWT
> bearer grant. If you want to increase security you can use cert-bound
> access tokens.
>
>     > The client IDs can still be opaque identifiers provided by the AS,
> they just happen to be associated with specific service accounts. Or they
> could be the opaque IDs that the AS already issued for the service account.
> Either way, the AS could issue a token with the appropriate subject and
> other claims for the service account.
>     >
>     > If your client identity is bound to a specific service account
> identity (i.e., the resource owner), then ROPC reduces down to Client
> Credentials. What's the point in passing two identifiers and two
> credentials for the same identity?
>     >
>     > –
>     > On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" <
> [email-masked] on behalf of [email-masked]> wrote:
>     >
>     >    While this may be a solution in specific circumstances, I don’t
> think it’s a general solution. e.g. an AS may not allow manually choosing
> the client_id to avoid things like
>     >    This is asking people to make fundamental changes to their
> identity architecture rather than simply switching to a new grant type.
>     >
>     >    — Neil
>     >
>     >> Annabelle’s proposal would solve that. Relate a client id to a
> service account and obtain the token data from there.
>     >>
>     >>>>> No failures, but it is a much more complex grant type to set up,
> when you consider everything you have to do:
>     >>>>>
>     >>>>> * determine the correct settings for issuer, audience, subject,
> etc. Does the AS impose non-standard requirements? e.g. RFC 7523 says that
> the JWT MUST contain a “sub” claim, but Google only allows this to be
> present if your client is doing impersonation of an end-user (which
> requires additional permissions).
>     >>>>> * do I need a unique “jti” claim? (OIDC servers do, plain OAuth
> ones might not) If I do, can I reuse the JWT or must it be freshly signed
> for every call?
>     >>>>>> Neil could you elaborate more on this please. What failures are
> you currently experiencing/seeing with the JWT Bearer grant?
>     >>>>>>
>     >>>>>> Matt
>     >>>>>>
>     >>>>>>> Neil: are you advocating that password grant be preserved in
> 2.1? Or do you think that service account developers know enough about what
> they are doing to follow what is in 6749?
>     >>>>>>> ᐧ
>     >>>>>>>
>     >>>>>>> Another reason is that sometimes OAuth is just one
> authentication option out of many, and so permissions assigned to service
> accounts are preferred over scopes because they are consistently applied no
> matter how a request is authenticated. This is often the case when OAuth
> has been retrofitted to an existing system and they need to preserve
> compatibility with already deployed clients.
>     >>>>>>>
>     >>>>>>>> Can you explain more in detail why the client credentials
> grant type isn’t applicable for the kind of use cases you mentioned?
>     >>>>>>>>
>     >>>>>>>>> The one legitimate use-case for ROPC I’ve seen is for
> service accounts - where you essentially want something like
> client_credentials but for whatever reason you need the RO to be a service
> user rather than an OAuth2 client (typically so that some lower layer of
> the system can still perform its required permission checks).
>     >>>>>>>>>
>     >>>>>>>>> There are better grant types for this - e.g. JWT bearer -
> but they are a bit harder to implement. Having recently converted some code
>     >>>>>>>>>> I would also seriously look at the original motivation
> behind ROPC: I know it has been deployed and is used in quite a lot of
> places but I have never actually come across a use case where it is used
> for migration purposes and the migration is actually executed (I know that
> is statistically not a very strong argument but I challenge others to come
> up with one...)
>     >>>>>>>>>> In reality it turned out just to be a one off that people
> used as an easy way out to stick to an anti-pattern and still claim to do
> OAuth 2.0. It is plain wrong, it is not OAuth and we need to get rid of it.
>     >>>>>>>>>>
>     >>>>>>>>>> Hans.
>     >>>>>>>>>>
>     >>>>>>>>>> Agreed. Plus, the Security BCP is already effectively
> acting as a grace period since it currently says the password grant MUST
> NOT be used, so in the OAuth 2.0 world that's already a pretty strong
> signal..
>     >>>>>>>>>>
>     >>>>>>>>>> Aaron
>     >>>>>>>>>>
>     >>>>>>>>>>
>     >>>>>>>>>>
>     >>>>>>>>>> There is no need for a grace period. People using OAuth
> 2..0 can still do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1.
>     >>>>>>>>>>
>     >>>>>>>>>> — Justin
>     >>>>>>>>>>
>     >>>>>>>>>>> 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.
>     >>>>>>>>>>>
>     >>>>>>>>>>> (Once again using the OAuth 2.1 name as a placeholder for
> the doc that Aaron, Torsten, and I are working on)
>     >>>>>>>>>>>
>     >>>>>>>>>>> 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

---

From: Phillip Hunt <[email-masked]>
Date: Sat, 22 Feb 2020 07:54:28 -0800

It may be programmatically equiv but from a trust perspective very different. 

Usually client cred flows are from trusted entities and fixed endpoints. 

Phil

> On Feb 21, 2020, at 5:05 PM, Richard Backman, Annabelle <richanna=[email-masked]> wrote:
>

---

From: Neil Madden <[email-masked]>
Date: Mon, 24 Feb 2020 14:49:04 +0000

Well, kinda. People can still theoretically use OAuth 1 too, but the world has moved on - software has dropped support for it, websites don’t support it, and so on.

I’m a bit confused about what OAuth 2.1 is intended to be. If it’s not a new version of OAuth (“obsoletes” the old RFC), then is not just another BCP? If it is a new version and it removes grant types (OAuth 3.0?) then that effectively has the same impact as removing them from OAuth 2.0, unless we’re envisioning some way for a client to negotiate version 2.0 support from an AS?

— Neil

> On 22 Feb 2020, at 01:41, Dick Hardt <[email-masked]> wrote:
> 
> I'm a little confused on where this thread is going. If we take ROPC out of OAuth 2.1 then:
>

---

From: Neil Madden <[email-masked]>
Date: Mon, 24 Feb 2020 15:23:32 +0000

But again, I’m talking about existing deployments. If you have an existing deployment using ROPC with service accounts and you have tens or hundreds of thousands of such accounts, this really sounds like a lot of work to change over. 

I forgot one of the other reasons for preferring a service account over an OAuth 2 client - some features of OAuth/OIDC require client secrets to be recoverable on the AS. For example, if you request an ID token signed with HMAC in an implicit/hybrid OIDC flow then this is signed using the client secret as the HMAC key. This prevents the AS from hashing the client secret, so client_credentials grant introduces security weaknesses compared to an ROPC service account flow. So you’d really want to move both to client_credentials flow and a more secure authentication mechanism - e.g. mTLS, and public key signed/encrypted ID tokens.

(NB: this is not just due to the implicit grant - e.g., CIBA backchannel auth in push mode has the same issue if you use HMAC-signed ID tokens).

— Neil

> On 22 Feb 2020, at 01:05, Richard Backman, Annabelle <[email-masked]> wrote:
>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 24 Feb 2020 10:03:29 -0700

Concur with the sentiment expressed by Neil here.

On Fri, Feb 21, 2020 at 3:32 PM Neil Madden <[email-masked]>
wrote:

> I’m not really sure the WG should be telling people what they “ought to be
> doing” unless we have concrete security or interoperability reasons for
> doing so.
>
> I also don’t agree that people doing this are doing anything wrong. I
> don’t always agree with what our customers do, but I’ve learnt over the
> years not to second-guess their reasons for doing it.
>
> Are Google wrong for using the JWT bearer grant (not client credentials)
> and service accounts? They even go so far as to say “scopes are not a
> security mechanism” [1] and tell people to use service account roles
> instead. (Precisely because they also support non-OAuth auth methods, which
> bypass any scopes).
>
> [1]:
> https://cloud.google.com/compute/docs/access/service-accounts#accesscopesiam
>
> > +1. I’ve seen this anti-pattern deployed all over the place, and it’s
> time to get rid of it and send people toward what they really ought to be
> doing.
> >
> > Another thing I’ve seen is using different service accounts to get
> different sets of access for one client — if you’re doing that, you’ve got
> a client pretending to do two different things, or your APIs should be
> using scopes to differentiate access instead of client/user identity.
> >
> > — Justin
> >
> >> The client IDs can still be opaque identifiers provided by the AS, they
> just happen to be associated with specific service accounts. Or they could
> be the opaque IDs that the AS already issued for the service account.
> >> If your client identity is bound to a specific service account identity
> (i.e., the resource owner), then ROPC reduces down to Client Credentials.
> What's the point in passing two identifiers and two credentials for the
> same identity?
> >>
> >> –
> >>   While this may be a solution in specific circumstances, I don’t think
> it’s a general solution. e.g. an AS may not allow manually choosing the
> >>>>>>>>>>> Agreed. Plus, the Security BCP is already effectively acting
> as a grace period since it currently says the password grant MUST NOT be
> used, so in the OAuth 2.0 world that's already a pretty strong signal..
> >>>>>>>>>>>
> >>>>>>>>>>> Aaron
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> There is no need for a grace period. People using OAuth 2..0
> can still do OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1.
> >>>>>>>>>>>
> >>>>>>>>>>> — Justin
> >>>>>>>>>>>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: William Denniss <[email-masked]>
Date: Mon, 24 Feb 2020 10:50:38 -0800

+1 to drop ROPC from the Security BCP, as it is not the best current
practice.

Speaking generally, the argument that people are currently using it and
will need to change, therefore we shouldn't deprecate anything is actually
antithetical to the goals of a BCP. As has been pointed out, they can
ignore the BCP should they wish and keep doing what they are doing. Really
the question should be: is this the right way to do this? I believe the
answer to that is "no", particularly when reading the original text in RFC
6749 Section 1.3.3 that we're essentially striking out here. If people are
doing different things with this grant type, then that's probably worthy of
it's own grant type.

As you wrote earlier Niel "There are better grant types for this - e.g. JWT
bearer - but they are a bit harder to implement.". Perhaps we can document
the better practice for this use-case to help point people using ROPC for
this in the right direction. Regarding the "harder to implement" concern, I
also don't think that's a reason for not deprecating. When I wrote RFC 8252
everyone was doing native app authorization in web views, and would need to
change what they were doing to adopt the BCP which was actually a lot of
work (but, for the reasons documented, it was really important to change).
This was actually why I wrote that BCP... to justify and help drive that
necessary change.

On Mon, Feb 24, 2020 at 6:49 AM Neil Madden <[email-masked]>
wrote:

> Well, kinda. People can still theoretically use OAuth 1 too, but the world
> has moved on - software has dropped support for it, websites don’t support
> it, and so on.
>
> I’m a bit confused about what OAuth 2.1 is intended to be. If it’s not a
> new version of OAuth (“obsoletes” the old RFC), then is not just another
> BCP? If it is a new version and it removes grant types (OAuth 3.0?) then
> that effectively has the same impact as removing them from OAuth 2.0,
> unless we’re envisioning some way for a client to negotiate version 2.0
> support from an AS?
>
> — Neil
>

---

From: William Denniss <[email-masked]>
Date: Mon, 24 Feb 2020 11:00:21 -0800

On Mon, Feb 24, 2020 at 6:49 AM Neil Madden <[email-masked]>
wrote:

> it, and so on

> BCP? If it is a new version and it removes grant types (OAuth 3.0?)

then that effectively has the same impact as removing them from OAuth 2.0,
> unless we’re envisioning some way for a client to negotiate version 2.0

Many implementations don't support the "password" grant today (and in fact,
never supported it), so it's not like you can rely on its presence for
interop.

If the client needs to negotiate which grant types it can use, then RFC
8414 provides this today with the "grant_types_supported" key.

William

---

From: Aaron Parecki <[email-masked]>
Date: Mon, 24 Feb 2020 16:13:42 -0800

I think we might be going about this discussion the wrong way.

On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell <bcampbell=
[email-masked]> wrote:

>> I’m not really sure the WG should be telling people what they “ought to
>> be doing” unless we have concrete security or interoperability reasons for
>> doing so.
>
>
I 100% agree that the job of a standard is not to tell people "what they
ought to be doing". Instead, a standard is more about documenting the
current state of the art as deployed in existing implementations.

With that in mind, I think that leaves us with two concrete problems with
the password grant:

1) The actual problem with the password grant is end users entering
passwords in applications, which the group (mostly) agrees on
2) People are re-appropriating the password grant for things like service
accounts or backends that are inflexible, not actually using it for end
user credentials

So it seems like there's actually something missing from OAuth which is
leading people to find the password grant and use that because it's the
only thing that most closely fits their existing model. It seems like we'd
be better off defining a new extension that captures the use case people
are actually doing, instead of encouraging the continuing use of the
password grant for this purpose.

----
Aaron Parecki
aaronparecki.com

On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell <bcampbell=
[email-masked]> wrote:

>> I’m not really sure the WG should be telling people what they “ought to
>> be doing” unless we have concrete security or interoperability reasons for
>> doing so.
>>
>> [email-masked] on behalf of [email-masked]
>> <neil.madden@forgerock..com>> wrote:
>> >>
>> architecture rather than simply switching to a new grant type..
>> >>
>> >>   — Neil
>> >>
>> reading your description it seems to be simpler than JWT Bearer..
>> >>>>>
>> can still do OAuth 2.0. People using OAuth 2..1 will do OAuth 2.1.
>> >>>>>>>>>>>
>> >>>>>>>>>>> — Justin
>> >>>>>>>>>>>
>> >>>>>>>>>>> aaronparecki.com <http://aaronparecki..com>
>> >>>>>>>>>>> @aaronpk
>> >>>>>>>>>>>
>> >>>>>>>>>> https://www.ietf..org/mailman/listinfo/oauth
>> <https://www.ietf.org/mailman/listinfo/oauth>
>> >>>>>>>>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited..
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Neil Madden <[email-masked]>
Date: Tue, 25 Feb 2020 11:40:35 +0000

I’d be open to defining a new service_account grant type and removing/deprecating the ROPC grant. I’d also be happy if we just said that service account flows should use the JWT bearer grant, and we document the best practices around that and encourage client libs to implement support for it.

Should there be a dedicated draft for best practices for service-to-service usage?

— Neil

> On 25 Feb 2020, at 00:13, Aaron Parecki <[email-masked]> wrote:
> 
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell <bcampbell=[email-masked]> wrote:
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden <[email-masked]> wrote:
> I 100% agree that the job of a standard is not to tell people "what they ought to be doing". Instead, a standard is more about documenting the current state of the art as deployed in existing implementations.
> 
> With that in mind, I think that leaves us with two concrete problems with the password grant:
> 
> 1) The actual problem with the password grant is end users entering passwords in applications, which the group (mostly) agrees on
> 2) People are re-appropriating the password grant for things like service accounts or backends that are inflexible, not actually using it for end user credentials
> 
> So it seems like there's actually something missing from OAuth which is leading people to find the password grant and use that because it's the only thing that most closely fits their existing model. It seems like we'd be better off defining a new extension that captures the use case people are actually doing, instead of encouraging the continuing use of the password grant for this purpose.
> 
> ----
> Aaron Parecki
> aaronparecki.com
> @aaronpk
> 
> 
> 
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell <bcampbell=[email-masked]> wrote:
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden <[email-masked]> wrote:
> >>   This is asking people to make fundamental changes to their identity architecture rather than simply switching to a new grant type..
> >> 
> >>   — Neil
> >> 
> >>>>> Have you ever tried the client credentials grant with mTLS? After reading your description it seems to be simpler than JWT Bearer..
> >>>>> 
> >>>>>>>>>>> There is no need for a grace period. People using OAuth 2..0 can still do OAuth 2.0. People using OAuth 2..1 will do OAuth 2.1. 
> >>>>>>>>>>> 
> >>>>>>>>>>> — Justin
> >>>>>>>>>>> 
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 25 Feb 2020 23:17:08 +0900

Let us do it then and deprecate ROPC.
There definitely are use-cases that need this pattern around me as well, but we are using JWT bearer grant instead. Standardizing the behavior is good. I am fine with new service_account grant type as well, btw.

Nat

---

From: Dick Hardt <[email-masked]>
Date: Fri, 28 Feb 2020 13:03:24 -0800

It looks like there is consensus to remove ROPC for a user -- but that the
password grant is not a bad practice for service accounts. That leads to
providing clarity on service accounts.

1) add service account grant to the OAuth 2.1 document

2) write an OAuth 2.1 extension for service account grants. (the grant type
could continue to be "password", but now clearly in the context of a
service account in a different document)

With the goal of OAuth 2.1 being a capture of all the best practices, (2)
makes more sense as it could discuss all aspects of service accounts
including mapping a client to a service account.

What do others think?

ᐧ

On Tue, Feb 25, 2020 at 6:17 AM Nat Sakimura <[email-masked]> wrote:

> There definitely are use-cases that need this pattern around me as well,
> but we are using JWT bearer grant instead. Standardizing the behavior is
> good. I am fine with new service_account grant type as well, btw.
>
> Nat
> I’d be open to defining a new service_account grant type and
> removing/deprecating the ROPC grant. I’d also be happy if we just said that
> service account flows should use the JWT bearer grant, and we document the
> best practices around that and encourage client libs to implement support
> for it.
>
> +1. I’ve seen this anti-pattern deployed all over the place, and it’s time
> to get rid of it and send people toward what they really ought to be doing.
>
> Have you ever tried the client credentials grant with mTLS? After reading
> your description it seems to be simpler than JWT Bearer..
>
> * determine the correct settings for issuer, audience, subject, etc. Does
> the AS impose non-standard requirements? e.g. RFC 7523 says that the JWT
> MUST contain a “sub” claim, but Google only allows this to be present if
> your client is doing impersonation of an end-user (which requires
> additional permissions).
> * do I need a unique “jti” claim? (OIDC servers do, plain OAuth ones might
> not) If I do, can I reuse the JWT or must it be freshly signed for every
> call?
> * locate and evaluate a JWT library for my language of choice. Monitor
> that new dependency for security advisories.
> Compared to “create a service account and POST the username and password
> to the token endpoint” it adds a little friction. (It also adds a lot of
> advantages, but it is undeniably more complex).
>
> — Neil
>
>
> On Wed, Feb 19, 2020 at 1:52 PM Neil Madden <neil.madden@forgerock..com>
> wrote:
> Can you explain more in detail why the client credentials grant type isn’t
> applicable for the kind of use cases you mentioned?
>
> The one legitimate use-case for ROPC I’ve seen is for service accounts -
> where you essentially want something like client_credentials but for
> There are better grant types for this - e.g. JWT bearer - but they are a
> bit harder to implement. Having recently converted some code from ROPC to
> the OAuth 2.0 world that's already a pretty strong signal..
>
> Aaron
>
>
>
> There is no need for a grace period. People using OAuth 2..0 can still do
> OAuth 2.0. People using OAuth 2..1 will do OAuth 2.1.
>
> — Justin
>
> to enter their credentials, the anti-pattern OAuth was created to eliminate.
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
> distribution or disclosure by others is strictly prohibited.. If you have
> computer. Thank you._______________________________________________
> OAuth mailing list
> [email-masked]