I'm a little confused on where this thread is going. If we take ROPC out of OAuth 2.1 then:
1) Existing deployments can keep using ROPC - why break it if it is working.. 2) New deployments can use ROPC and be OAuth 2.0 compliant. 3) New deployments that don't need ROPC can be OAuth 2.1 compliant ᐧ On Fri, Feb 21, 2020 at 5:05 PM Richard Backman, Annabelle <richanna= 40amazon....@dmarc.ietf.org> 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" <neil.mad...@forgerock.com> 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 <neil.mad...@forgerock.com> > 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 < > neil.mad...@forgerock.com> 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 <matt= > 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 <dick.ha...@gmail.com> > 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 < > neil.mad...@forgerock.com> 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 < > tors...@lodderstedt.net> 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 < > neil.mad...@forgerock.com>: > >>>>>>>>> > >>>>>>>>> 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 < > hans.zandb...@zmartzone.eu> 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 < > aa...@parecki.com> 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 < > jric...@mit.edu> 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 <oauth-boun...@ietf.org> 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 > >>>>>> _______________________________________________ > >>>>>> 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
