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

[Levi Schuck <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]>
> 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 <[e-mail]>
> 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 <[e-mail]>
> 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 <[e-mail]>
> 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=
> [e-mail]> 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 <
> [e-mail]> 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 <[e-mail]> 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 <
> [e-mail]> 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 <
> [e-mail]> 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 <
> [e-mail]>:
> >>>>>>>>
> >>>>>>>> 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 <
> [e-mail]> 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 <
> [e-mail]> 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 <[e-mail]>
> 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=
> [e-mail]> 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 <[e-mail]> On Behalf Of Dick Hardt
> >>>>>>>>>> Sent: Tuesday, February 18, 2020 12:37 PM
> >>>>>>>>>> To: [e-mail]
> >>>>>>>>>> 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
> >>>>>>>>>> [e-mail]
> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> OAuth mailing list
> >>>>>>>>> [e-mail]
> >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>>>>> --
> >>>>>>>>> ----
> >>>>>>>>> Aaron Parecki
> >>>>>>>>> aaronparecki.com
> >>>>>>>>> @aaronpk
> >>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> OAuth mailing list
> >>>>>>>>> [e-mail]
> >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> [e-mail]
> >>>>>>>>> ZmartZone IAM - www.zmartzone.eu
> >>>>>>>>> _______________________________________________
> >>>>>>>>> OAuth mailing list
> >>>>>>>>> [e-mail]
> >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> OAuth mailing list
> >>>>>>>> [e-mail]
> >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> OAuth mailing list
> >>>>>> [e-mail]
> >>>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>>
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>> _______________________________________________
> >>>>> OAuth mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>
> >>>> _______________________________________________
> >>>> OAuth mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>
> >>
> >
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>