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

[Matthew De Haast <[e-mail]>]

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