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

[Justin Richer]

Again — isn’t this just the client credentials grant but with extra steps?

 — Justin

> On Mar 1, 2020, at 11:33 AM, Phillip Hunt  wrote:
> 
> Why not just require service accounts to use mutually acceptable http method 
> of authentication?  Eg instead id/password, service acnt client could use 
> mtls auth or http basic or some other method.  
> 
> AFAIK this is already widely done. 
> 
> Is there so much interop value that specifying only the weakest form of 
> authentication is warranted?
> 
> Phil
> 
>> On Mar 1, 2020, at 4:09 AM, Dominick Baier  wrote:
>> 
>> 
>> 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)
>> 
>> IMHO - if such a thing gets defined, it should be a separate document. Keep 
>> 2.1 as simple as possible.
>> 
>> ———
>> Dominick Baier
>> 
>> On 28. February 2020 at 22:04:10, Dick Hardt (dick.ha...@gmail.com 
>> ) wrote:
>> 
>>> 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 >> > wrote:
>>> 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
>>> 2020年2月25日 20:41 +0900、Neil Madden >> > のメール:
 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  > wrote:
> 
> I think we might be going about this discussion the wrong way.
> 
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell 
>  > wrote:
> Concur with the sentiment expressed by Neil here.
> 
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden  > 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 
> @aaronpk
> 
> 
> 
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell 
>  > wrote:
> Concur with the sentiment expressed by Neil here.
> 
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden  > 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.
>

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

[Dick Hardt]

That sounds like a good addition to a separate document Phil.
ᐧ

On Sun, Mar 1, 2020 at 8:33 AM Phillip Hunt 
wrote:

> Why not just require service accounts to use mutually acceptable http
> method of authentication?  Eg instead id/password, service acnt client
> could use mtls auth or http basic or some other method.
>
> AFAIK this is already widely done.
>
> Is there so much interop value that specifying only the weakest form of
> authentication is warranted?
>
> Phil
>
> On Mar 1, 2020, at 4:09 AM, Dominick Baier 
> wrote:
>
> 
> 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)
>
> IMHO - if such a thing gets defined, it should be a separate document.
> Keep 2.1 as simple as possible.
>
> ———
> Dominick Baier
>
> On 28. February 2020 at 22:04:10, Dick Hardt (dick.ha...@gmail.com) wrote:
>
> 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  wrote:
>
>> 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
>> 2020年2月25日 20:41 +0900、Neil Madden  のメール:
>>
>> 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  wrote:
>>
>> I think we might be going about this discussion the wrong way.
>>
>> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell > 40pingidentity@dmarc.ietf.org> wrote:
>> Concur with the sentiment expressed by Neil here.
>>
>> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden 
>> 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
>> @aaronpk
>>
>>
>>
>> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell > 40pingidentity@dmarc.ietf.org> wrote:
>> Concur with the sentiment expressed by Neil here.
>>
>> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden 
>> 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).
>>
>> Are we really going to tell them to rewrite it

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

[Phillip Hunt]

Why not just require service accounts to use mutually acceptable http method of 
authentication?  Eg instead id/password, service acnt client could use mtls 
auth or http basic or some other method.  

AFAIK this is already widely done. 

Is there so much interop value that specifying only the weakest form of 
authentication is warranted?

Phil

> On Mar 1, 2020, at 4:09 AM, Dominick Baier  wrote:
> 
> 
> 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)
> 
> IMHO - if such a thing gets defined, it should be a separate document. Keep 
> 2.1 as simple as possible.
> 
> ———
> Dominick Baier
> 
>> On 28. February 2020 at 22:04:10, Dick Hardt (dick.ha...@gmail.com) wrote:
>> 
>> 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  wrote:
>>> 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
>>> 2020年2月25日 20:41 +0900、Neil Madden  のメール:
 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  wrote:
> 
> I think we might be going about this discussion the wrong way.
> 
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell 
>  wrote:
> Concur with the sentiment expressed by Neil here.
> 
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden  
> 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
> @aaronpk
> 
> 
> 
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell 
>  wrote:
> Concur with the sentiment expressed by Neil here.
> 
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden  
> 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-OA

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

[Dominick Baier]

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)

IMHO - if such a thing gets defined, it should be a separate document. Keep
2.1 as simple as possible.

———
Dominick Baier

On 28. February 2020 at 22:04:10, Dick Hardt (dick.ha...@gmail.com) wrote:

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

> 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
> 2020年2月25日 20:41 +0900、Neil Madden  のメール:
>
> 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  wrote:
>
> I think we might be going about this discussion the wrong way.
>
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
> Concur with the sentiment expressed by Neil here.
>
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden 
> 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
> @aaronpk
>
>
>
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
> Concur with the sentiment expressed by Neil here.
>
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden 
> 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).
>
> 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  wrote:
>
> +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

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

[Dick Hardt]

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

> 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
> 2020年2月25日 20:41 +0900、Neil Madden  のメール:
>
> 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  wrote:
>
> I think we might be going about this discussion the wrong way.
>
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
> Concur with the sentiment expressed by Neil here.
>
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden 
> 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
> @aaronpk
>
>
>
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
> Concur with the sentiment expressed by Neil here.
>
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden 
> 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).
>
> 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  wrote:
>
> +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  40amazon@dmarc.ietf.org> wrote:
>
> 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 

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

[Nat Sakimura]

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
2020年2月25日 20:41 +0900、Neil Madden  のメール:
> 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  wrote:
> >
> > I think we might be going about this discussion the wrong way.
> >
> > On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell 
> >  wrote:
> > Concur with the sentiment expressed by Neil here.
> >
> > On Fri, Feb 21, 2020 at 3:32 PM Neil Madden  
> > 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
> > @aaronpk
> >
> >
> >
> > On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell 
> >  wrote:
> > Concur with the sentiment expressed by Neil here.
> >
> > On Fri, Feb 21, 2020 at 3:32 PM Neil Madden  
> > 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).
> >
> > 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  wrote:
> > >
> > > +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 
> > > >  wrote:
> > > >
> > > > 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?
> > > >
> > > > –
> > > > Annabelle Backman (she/her)
> > > > AWS Identity
> > > > https://aws.amazon.com/identity/
> > > >
> > > >
> > > > On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" 
> > > >  wrote:
> > > >
> > > > Sorry, I 

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

[Neil Madden]

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  wrote:
> 
> I think we might be going about this discussion the wrong way.
> 
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell 
>  wrote:
> Concur with the sentiment expressed by Neil here. 
> 
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden  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
> @aaronpk
> 
> 
> 
> On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell 
>  wrote:
> Concur with the sentiment expressed by Neil here. 
> 
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden  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).
> 
> 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  wrote:
> > 
> > +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 
> >>  wrote:
> >> 
> >> 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?
> >> 
> >> –
> >> Annabelle Backman (she/her)
> >> AWS Identity
> >> https://aws.amazon.com/identity/
> >> 
> >> 
> >> On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" 
> >>  wrote:
> >> 
> >>   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.
> >> 
> >> 

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

[lanerashaa...@gmail.com]

Sent from my LG Stylo 5+, an AT&T 4G LTE smartphone-- Original 
message--From: Brian CampbellDate: Mon, Feb 24, 2020 9:04 AMTo: Neil 
Madden;Cc: Matthew De Haast;oauth@ietf.org;Richard Backman, 
Annabelle;Subject:Re: [OAUTH-WG] OAuth 2.1: dropping password grantConcur with 
the sentiment expressed by Neil here. On Fri, Feb 21, 2020 at 3:32 PM Neil 
Madden  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).

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  wrote:
> 
> +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 
>> 40amazon@dmarc.ietf.org> wrote:
>> 
>> 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?
>> 
>> –
>> Annabelle Backman (she/her)
>> AWS Identity
>> https://aws.amazon.com/identity/
>> 
>> 
>> On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" 
>>  wrote:
>> 
>>   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  
>>> wrote:
>>> 
>>> 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  wrote:
 
 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  
> wrote:
> 
> 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  wrote:
>> 
>> 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 
>> prese

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

[Aaron Parecki]

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

On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell  wrote:

> Concur with the sentiment expressed by Neil here.
>
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden 
> 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
@aaronpk 



On Mon, Feb 24, 2020 at 9:04 AM Brian Campbell  wrote:

> Concur with the sentiment expressed by Neil here.
>
> On Fri, Feb 21, 2020 at 3:32 PM Neil Madden 
> 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).
>>
>> 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  wrote:
>> >
>> > +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 > 40amazon@dmarc.ietf.org> wrote:
>> >>
>> >> 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?
>> >>
>> >> –
>> >> Annabelle Backman (she/her)
>> >> AWS Identity
>> >> https://aws.amazon.com/identity/
>> >>
>> >>
>> >> On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" <
>> oauth-boun...@ietf.org on behalf of neil.mad...@forgerock.com
>> > wrote:
>> >>
>> >>   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 <
>> tors...@lodderstedt.net> wrote:
>> >>>
>> >>> 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 da

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

[William Denniss]

On Mon, Feb 24, 2020 at 6:49 AM Neil Madden 
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?
>

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



>
> — Neil
>
> > On 22 Feb 2020, at 01:41, Dick Hardt  wrote:
> >
> > 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
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Brian Campbell]

Concur with the sentiment expressed by Neil here.

On Fri, Feb 21, 2020 at 3:32 PM Neil Madden 
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).
>
> 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  wrote:
> >
> > +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  40amazon@dmarc.ietf.org> wrote:
> >>
> >> 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?
> >>
> >> –
> >> Annabelle Backman (she/her)
> >> AWS Identity
> >> https://aws.amazon.com/identity/
> >>
> >>
> >> On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" <
> oauth-boun...@ietf.org on behalf of neil.mad...@forgerock.com> wrote:
> >>
> >>   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 
> wrote:
> >>>
> >>> 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 
> wrote:
> 
>  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 <
> tors...@lodderstedt.net> wrote:
> >
> > 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 
> wrote:
> >>
> >> 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”

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

[Neil Madden]

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  
> 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 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?
> 
> –
> Annabelle Backman (she/her)
> AWS Identity
> https://aws.amazon.com/identity/
> 
> 
> On 2/21/20, 1:53 PM, "Neil Madden"  wrote:
> 
>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  
>> wrote:
>> 
>> 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?
>> 
>> –
>> Annabelle Backman (she/her)
>> AWS Identity
>> https://aws.amazon.com/identity/
>> 
>> 
>> On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" 
>>  wrote:
>> 
>>   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  
>>> wrote:
>>> 
>>> 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  wrote:
 
 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 Lod

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

[Neil Madden]

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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Phillip Hunt]

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 
>  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 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?
> 
> –
> Annabelle Backman (she/her)
> AWS Identity
> https://aws.amazon.com/identity/
> 
> 
> On 2/21/20, 1:53 PM, "Neil Madden"  wrote:
> 
>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  
>> wrote:
>> 
>> 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?
>> 
>> –
>> Annabelle Backman (she/her)
>> AWS Identity
>> https://aws.amazon.com/identity/
>> 
>> 
>> On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" 
>>  wrote:
>> 
>>   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  
 wrote:
>>> 
>>> 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  wrote:
 
 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  
> wrote:
> 
> 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  wrote:
>> 
>> 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

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

[Dick Hardt]

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  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 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?
>
> –
> Annabelle Backman (she/her)
> AWS Identity
> https://aws.amazon.com/identity/
>
>
> On 2/21/20, 1:53 PM, "Neil Madden"  wrote:
>
> 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 <
> richa...@amazon.com> wrote:
> >
> > 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?
> >
> > –
> > Annabelle Backman (she/her)
> > AWS Identity
> > https://aws.amazon.com/identity/
> >
> >
> > On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" <
> oauth-boun...@ietf.org on behalf of neil.mad...@forgerock.com> wrote:
> >
> >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 <
> tors...@lodderstedt.net> wrote:
> >>
> >> 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 
> wrote:
> >>>
> >>> 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 <
> tors...@lodderstedt.net> wrote:
> 
>  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

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

[Richard Backman, Annabelle]

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?

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

On 2/21/20, 1:53 PM, "Neil Madden"  wrote:

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 
 wrote:
> 
> 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?
> 
> –
> Annabelle Backman (she/her)
> AWS Identity
> https://aws.amazon.com/identity/
> 
> 
> On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" 
 wrote:
> 
>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  
wrote:
>> 
>> 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  
wrote:
>>> 
>>> 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 
 wrote:
 
 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  
wrote:
> 
> 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 

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

[Neil Madden]

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  wrote:
> 
> +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 
>>  wrote:
>> 
>> 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?
>> 
>> –
>> Annabelle Backman (she/her)
>> AWS Identity
>> https://aws.amazon.com/identity/
>> 
>> 
>> On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" 
>>  wrote:
>> 
>>   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  
>>> wrote:
>>> 
>>> 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  wrote:
 
 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  
> wrote:
> 
> 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  wrote:
>> 
>> 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 secu

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

[Neil Madden]

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  
> wrote:
> 
> 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?
> 
> –
> Annabelle Backman (she/her)
> AWS Identity
> https://aws.amazon.com/identity/
> 
> 
> On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" 
>  wrote:
> 
>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  
>> wrote:
>> 
>> 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  wrote:
>>> 
>>> 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  
 wrote:
 
 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  wrote:
> 
> 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 
>>  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 could you elaborate more on this please. What failures are you 
>> currently experiencing/seeing with the JWT Bearer grant? 
>> 
>> Matt
>> 

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

[Justin Richer]

+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 
>  wrote:
> 
> 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?
> 
> –
> Annabelle Backman (she/her)
> AWS Identity
> https://aws.amazon.com/identity/
> 
> 
> On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden" 
>  wrote:
> 
>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  
>> wrote:
>> 
>> 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  wrote:
>>> 
>>> 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  
 wrote:
 
 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  wrote:
> 
> 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 
>>  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 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  
>> wrote:

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

[Richard Backman, Annabelle]

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?

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

On 2/21/20, 6:48 AM, "OAuth on behalf of Neil Madden"  wrote:

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  
wrote:
> 
> 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  wrote:
>> 
>> 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  
wrote:
>>> 
>>> 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  
wrote:
 
 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 
 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 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 
 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.
> 
> 
>> On 19 Feb 2020, at 22:01, Dick Hardt  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?
>

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

[Torsten Lodderstedt]

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  wrote:
> 
> 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  
>> wrote:
>> 
>> 
>> 
>>> On 21. Feb 2020, at 15:47, Neil Madden  wrote:
>>> 
>>> 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.
>> 
>> 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.
>> 
>>> 
>>> — Neil
>>> 
 On 21 Feb 2020, at 14:34, Torsten Lodderstedt  
 wrote:
 
 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  wrote:
> 
> 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  
>> wrote:
>> 
>> 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  
>>> wrote:
>>> 
>>> 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 
  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 could you elaborate more on this please. What failures are you 
 curren

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

[Neil Madden]

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  wrote:
> 
> 
> 
>> On 21. Feb 2020, at 15:47, Neil Madden  wrote:
>> 
>> 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.
> 
> 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.
> 
>> 
>> — Neil
>> 
>>> On 21 Feb 2020, at 14:34, Torsten Lodderstedt  
>>> wrote:
>>> 
>>> 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  wrote:
 
 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  
> wrote:
> 
> 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  wrote:
>> 
>> 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 
>>>  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 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 
>>>  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.
>>> 
>>> 
 On 19 Feb 2020, at 22:01, Dick Hardt  wrote:
 
 Neil: are you advocating that password grant be preserved in 2.1? Or 
 do you think that service account developers kn

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

[Torsten Lodderstedt]

> On 21. Feb 2020, at 15:47, Neil Madden  wrote:
> 
> 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.

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.

> 
> — Neil
> 
>> On 21 Feb 2020, at 14:34, Torsten Lodderstedt  
>> wrote:
>> 
>> 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  wrote:
>>> 
>>> 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  
 wrote:
 
 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  wrote:
> 
> 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 
>>  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 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  
>> 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.
>> 
>> 
>>> On 19 Feb 2020, at 22:01, Dick Hardt  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  
>>> 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

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

[Levi Schuck]

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

> 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 
> wrote:
> >
> > 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 
> wrote:
> >>
> >> 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 
> wrote:
> >>>
> >>> 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 
> wrote:
> 
>  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  40coil@dmarc.ietf.org> 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 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 <
> neil.mad...@forgerock.com> 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.
> >
> >
> >> On 19 Feb 2020, at 22:01, Dick Hardt  wrote:
> >>
> >> Neil: are you advocating that password grant be preserved in 2.1?
> Or do you think that service account developers know enou

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

[Neil Madden]

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  wrote:
> 
> 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  wrote:
>> 
>> 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  
>>> wrote:
>>> 
>>> 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  wrote:
 
 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 
>  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 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  
> 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.
> 
> 
>> On 19 Feb 2020, at 22:01, Dick Hardt  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  
>> 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

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

[Torsten Lodderstedt]

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  wrote:
> 
> 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  
>> wrote:
>> 
>> 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  wrote:
>>> 
>>> 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 
  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 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  
 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.
 
 
> On 19 Feb 2020, at 22:01, Dick Hardt  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  
> 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

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

[Neil Madden]

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  wrote:
> 
> 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  wrote:
>> 
>> 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  
>>> 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 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  
>>> 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.
>>> 
>>> 
 On 19 Feb 2020, at 22:01, Dick Hardt  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  
 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
 
> On 19 Feb 2020, at 21:35, Torsten Lodderstedt 

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

[Torsten Lodderstedt]

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  wrote:
> 
> 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  
>> 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 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  
>> 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.
>> 
>> 
>>> On 19 Feb 2020, at 22:01, Dick Hardt  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  
>>> 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
>>> 
 On 19 Feb 2020, at 21:35, Torsten Lodderstedt  
 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 :
> 
> I very much agree with this with regards to real users. 
> 
> The one legi

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

[Neil Madden]

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  
> 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 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  
> 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.
> 
> 
> > On 19 Feb 2020, at 22:01, Dick Hardt  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  
> > 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
> > 
> > > On 19 Feb 2020, at 21:35, Torsten Lodderstedt  
> > > 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 :
> > >> 
> > >> 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 th

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

[Matthew De Haast]

>
> 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 
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.
>
>
> > On 19 Feb 2020, at 22:01, Dick Hardt  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 
> 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
> >
> > > On 19 Feb 2020, at 21:35, Torsten Lodderstedt 
> 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  >:
> > >>
> > >> 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 
> 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.
> > >>>
> > >>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki 
> 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
> > >>>
> > >>>
> > >>>
> > >>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer 
> wrote:
> > >>> There is no need for a grace period. People using OAuth 2.0 can
> still

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

[Neil Madden]

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  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  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
> 
> > On 19 Feb 2020, at 21:35, Torsten Lodderstedt  
> > 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 :
> >> 
> >> 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  
> >>> 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.
> >>> 
> >>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki  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
> >>> 
> >>> 
> >>> 
> >>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer  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 
> >  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  On B

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

[Dick Hardt]

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 
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
>
> > On 19 Feb 2020, at 21:35, Torsten Lodderstedt 
> 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 :
> >>
> >> 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 
> 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.
> >>>
> >>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki 
> 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
> >>>
> >>>
> >>>
> >>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer  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  40microsoft@dmarc.ietf.org> 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  On Behalf Of Dick Hardt
>  Sent: Tuesday, February 18, 2020 12:37 PM
>  To: oauth@ietf.org
>  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#sectio

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

[Richard Backman, Annabelle]

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

> On 19 Feb 2020, at 21:35, Torsten Lodderstedt  
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 :
>> 
>> 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  
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.
>>> 
>>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki  
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
>>> 
>>> 
>>> 
>>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer  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 
 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  On Behalf Of Dick Hardt
 Sent: Tuesday, February 18, 2020 12:37 PM
 To: oauth@ietf.org
 Subject: [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password

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

[Neil Madden]

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  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 :
>> 
>> 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  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.
>>> 
>>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki  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
>>> 
>>> 
>>> 
>>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer  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 
>  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  On Behalf Of Dick Hardt
 Sent: Tuesday, February 18, 2020 12:37 PM
 To: oauth@ietf.org
 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
 
 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 

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

[Brock Allen]

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 
 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 :
>
> 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 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.
>>
>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki 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
>>
>>
>>
>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer 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 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 On Behalf Of Dick Hardt
>>> Sent: Tuesday, February 18, 2020 12:37 PM
>>> To: oauth@ietf.org
>>> 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
>>>
>>> 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
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> --
>> 
>> Aaron Parecki
>> aaronparecki.com
>> @aaronpk
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> --
>> hans.zandb...@zmartzone.eu
>> ZmartZone IAM - www.zmartzone.eu
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Torsten Lodderstedt]

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 :
> 
> 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  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.
>> 
>> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki  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
>> 
>> 
>> 
>> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer  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 
  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  On Behalf Of Dick Hardt
>>> Sent: Tuesday, February 18, 2020 12:37 PM
>>> To: oauth@ietf.org
>>> 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
>>> 
>>> 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
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> -- 
>> 
>> Aaron Parecki
>> aaronparecki.com
>> @aaronpk
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> -- 
>> hans.zandb...@zmartzone.eu
>> ZmartZone IAM - www.zmartzone.eu
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Neil Madden]

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  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.
> 
> On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki  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
> 
> 
> 
> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer  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 
>>  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  On Behalf Of Dick Hardt
>> Sent: Tuesday, February 18, 2020 12:37 PM
>> To: oauth@ietf.org
>> 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
>>  
>> 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
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> -- 
> 
> Aaron Parecki
> aaronparecki.com
> @aaronpk
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> -- 
> hans.zandb...@zmartzone.eu
> ZmartZone IAM - www.zmartzone.eu
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Hans Zandbelt]

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  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
>
>
>
> On Tue, Feb 18, 2020 at 4:16 PM Justin Richer  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=40microsoft@dmarc.ietf.org> 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  *On Behalf Of *Dick Hardt
>> *Sent:* Tuesday, February 18, 2020 12:37 PM
>> *To:* oauth@ietf.org
>> *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
>> 
>>
>> 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
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> --
> 
> Aaron Parecki
> aaronparecki.com
> @aaronpk 
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
hans.zandb...@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Aaron Parecki]

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  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=40microsoft@dmarc.ietf.org> 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  *On Behalf Of *Dick Hardt
> *Sent:* Tuesday, February 18, 2020 12:37 PM
> *To:* oauth@ietf.org
> *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
> 
>
> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 

Aaron Parecki
aaronparecki.com
@aaronpk 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth