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