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

[lanerashaa...@gmail.com]

Sent from my LG Stylo 5+, an AT 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 
>> 

Re: [OAUTH-WG] Fwd: [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object

[Nat Sakimura]

So, where should we take it to?
Just add back client_id as it used to be?

On Fri, Jan 24, 2020 at 6:55 AM John Bradley  wrote:

>
> -- Forwarded message -
> From: John Bradley 
> Date: Sat, Jan 18, 2020, 9:31 PM
> Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request
> (JAR) vs OIDC request object
> To: Benjamin Kaduk 
>
>
> If you put the iss in the JWE header it is integrity protected, as JWE
> only supports AAD encryption algs.
>
> It is more of a problem when the client is sending a requestURI in that
> case having the clientID in the GET to the Authorization endpoint is useful.
>
> I think there is a argument for explicitly allowing the clientID as long
> as it exactly matches the clientID in the JAR.
>
> John B.
>
> On Fri, Jan 17, 2020 at 11:53 PM Benjamin Kaduk  wrote:
>
>> On Fri, Jan 17, 2020 at 08:44:18AM -0500, Justin Richer wrote:
>> > I don’t agree with this stance from a security or implementation
>> perspective.
>> >
>> > If there’s a clear order of precedence for the information, it’s not
>> particularly problematic. Everything inside the request object is to be
>> taken over things outside the request object. We have the exact same
>> semantics and process with dynamic registration, where the software
>> statement is carried alongside plain JSON claims, and the two are mixed
>> with a very simple algorithm:
>> >
>> >  - If a field is inside the signed payload, use that value and ignore
>> any copy of it on the outside
>> >  - If a field is not inside the signed payload and is outside the
>> signed payload, use the outside value
>> >
>> > Can someone please point out a concrete security issue with this
>> algorithm? This is the extent of the “merge” semantics that we need here,
>> and it would solve not only the ability to use this for use cases that call
>> for a more static request object (perhaps signed by a third party and not
>> the client) along side the plain parameters that can vary, but also the
>> backwards compatibility issue that’s been discussed. With this algorithm in
>> place, you could have OIDC clients actually be compliant with the spec,
>> since OIDC requires replication of the values inside the request object on
>> the outside with exact matches. An OIDC server wouldn’t be fully compliant
>> with the new spec since it would reject some compliant JAR requests that
>> are missing the external parameters, but that’s fairly easy logic to add on
>> the OIDC side. And in that case you get a matrix of compatibility like:
>>
>> I agree that the merge algorithm is simple and fairly straightforward to
>> implement.  But, as Joseph has been alluding, it's only simple if you've
>> already made the decision to use all the parameters, both from inside and
>> from outside the signed payload.  The security risk lies about having to
>> make the trust decision twice, more than the mundane details of actually
>> doing the merge.  (Though there is still some latent risk, given that
>> we've
>> seen some really crazy quality of implementation out there.)
>>
>> It's certainly *possible* that things end up fine in many well-deliniated
>> cases where merging can be used.  But it's more complicated to reason
>> about, and I don't remmber seeing much previous discussion about the
>> specifics of the double trust decision.
>>
>> -Ben
>>
>> >
>> >   JAR Server | OIDC Server  |
>> > ++--+
>> > JAR Client  | YES|  NO  |
>> > OIDC Client | YES| YES  |
>> >
>> > Breaking one out of the four possible combinations in a very
>> predictable way is, I think, the best way to handle backwards compatibility
>> here.
>> >
>> > But between this issue and JAR’s problematic call for the value of a
>> request_uri to always be a JWT and be fetchable by the AS (neither of which
>> are true in the case of PAR) makes me think we need to pull this back and
>> rework those things, in a push back to the IESG’s comments.
>> >
>> >  — Justin
>> >
>> >
>> > > On Jan 16, 2020, at 7:38 PM, Joseph Heenan 
>> wrote:
>> > >
>> > > I agree with this, particularly the security concerns of merging. If
>> we merge, we can much guarantee there will eventually be a security issue
>> where an attacker is able to gain an advantage by adding a parameter to the
>> url query (which the server would then happily process if that parameter
>> isn’t found inside the request object). Ruling out that case makes security
>> analysis (particularly when creating new OAuth2 parameters) significantly
>> simpler.
>> > >
>> > > Putting the iss in the JWE header and having the client_id duplicated
>> outside the request object seem to address all the concerns I’ve seen
>> raised.
>> > >
>> > > (It seems like it may be unnecessary to have the client_id duplicated
>> outside if the request_uri is a PAR one though.)
>> > >
>> > > Joseph
>> > >
>> > >
>> > >
>> > >> On 16 Jan 2020, at 22:40, John Bradley  wrote:
>> > >>
>> > >> I agree with 

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

[Bruno Brito]

> a standard is more about documenting the current state of the art as
deployed in existing implementations.

For those whose still keep their ROPC grants working whats the problem
about be OAuth 2.0 compliant?
And those who changes their implememntations, they will be OAuth 2.1
compliant, isn't simple?

Afterall the show must go on.

On Mon, Feb 24, 2020 at 9:14 PM  wrote:

> Send OAuth mailing list submissions to
> oauth@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
> oauth-requ...@ietf.org
>
> You can reach the person managing the list at
> oauth-ow...@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
> Today's Topics:
>
>1. Re: OAuth 2.1: dropping password grant (Aaron Parecki)
>
>
>
> -- Forwarded message --
> From: Aaron Parecki 
> To: Brian Campbell 
> Cc: Neil Madden , Matthew De Haast  40coil@dmarc.ietf.org>, "oauth@ietf.org" , "Richard
> Backman, Annabelle" 
> Bcc:
> Date: Mon, 24 Feb 2020 16:13:42 -0800
> Subject: Re: [OAUTH-WG] OAuth 2.1: dropping password grant
> 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 the service account.
>>> >>
>>> >> If your client 

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 

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 

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 

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