Subject: [OAUTH-WG] Usage of Password Grant

From: Beena Santhosh <[email-masked]>
Date: Sun, 10 May 2020 15:33:21 +0530

Hi,

We have a product with client server architecture where our server manages
thousands of devices. Each device has a client-piece that talks to the
server over SOAP/REST. The client currently uses a HTTP Basic
Authentication (unique id and a secret string) for all the calls. The
secret string is created when the device enrolls to the server. It is
available at the server as well as stored securely on the device. For the
rest calls it is the device that is getting authenticated.

 Sending the credentials every time is less than ideal and we want to move
to some tokenized device authentication. We evaluated OpendID Connect based
on the general recommendation of SSO solution, but the issue is we do not
have any user interaction and hence there is no Grant flow that is fitting.
Hence we evaluated OAuth grant type of which we found Password Grant and
Client Credentials Grant is matching our requirement.

 In order to use Client Credentials in our use case, we need to do dynamic
registration for the thousands of devices managed by the server, if IoT
comes into picture the number is going to be even higher, which is highly
cumbersome to manage.  Also, as per  RFC7591 on dynamic client
registration, using access token for registering client is optional too.
Even though the Password grant is highly discouraged by the spec, we found
it to be highly matching with our requirements.

But as per the Oauth 2.1 proposal, password grant is going to be removed. Can
you suggest the way forward for us? I believe we are not a one-off case.

Thank You,

Beena

---

From: Aaron Parecki <[email-masked]>
Date: Sun, 10 May 2020 07:20:39 -0700

Hi Beena,

This sounds like a great use of the client credentials grant. The password
grant is being removed from OAuth 2.0 by the Security Best Current
Practice. Can you clarify what you've found useful about the password grant
that the client credentials grant doesn't solve?

Aaron Parecki

On Sun, May 10, 2020 at 3:18 AM Beena Santhosh <[email-masked]>
wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Beena Santhosh <[email-masked]>
Date: Tue, 12 May 2020 12:40:10 +0530

Hi Aaron,

What we are planning to build is a Public first party client. As per the
spec the client secret is optional for Password Grant. Hence we choose to
use a common client_id across all the devices. The first party client on
every device  will get the  common client_id through our proprietary API.
We found this as a difference between Password Grant and Client credentials
grant. We could be wrong but this is our interpretation.  This way we could
make use of the rest of the benefits that OAuth provides around access
tokens

Thank You,

Beena

On Mon, May 11, 2020 at 11:15 PM Aaron Parecki <[email-masked]> wrote:

> With the password grant you'd then need to register 50,000+ user accounts,
> right? How is that different from registering that many clients?
>
> On Mon, May 11, 2020 at 10:39 AM Beena Santhosh <
> [email-masked]> wrote:
>
>> Hi Aaron,
>>
>> Thank You for the quick response.
>>
>> We do support  1, 50, 000+ devices and that means we need to register
>> those many devices dynamically,  the provider we have evaluated  is not
>> supporting that scale . Once we  incorporate IoT, we need to support
>> millions of devices. With Password Grant as we need only one client_id it
>> is easy to manage. Also our client is First Party client.
>>
>>
>> Thank You,
>>
>> Beena
>>
>> On Sun, May 10, 2020 at 7:50 PM Aaron Parecki <[email-masked]> wrote:
>>
>>> Hi Beena,
>>>
>>> This sounds like a great use of the client credentials grant. The
>>> password grant is being removed from OAuth 2.0 by the Security Best Current
>>> On Sun, May 10, 2020 at 3:18 AM Beena Santhosh <
>>> [email-masked]> wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>> We have a product with client server architecture where our server
>>>> manages thousands of devices. Each device has a client-piece that talks to
>>>> the server over SOAP/REST. The client currently uses a HTTP Basic
>>>>  Sending the credentials every time is less than ideal and we want to
>>>> move to some tokenized device authentication. We evaluated OpendID Connect
>>>> based on the general recommendation of SSO solution, but the issue is we do
>>>> not have any user interaction and hence there is no Grant flow that is
>>>> fitting. Hence we evaluated OAuth grant type of which we found Password
>>>> Grant and Client Credentials Grant is matching our requirement.
>>>>
>>>>
>>>>
>>>>  In order to use Client Credentials in our use case, we need to do
>>>> dynamic registration for the thousands of devices managed by the server, if
>>>> IoT comes into picture the number is going to be even higher, which is
>>>> highly cumbersome to manage.  Also, as per  RFC7591 on dynamic client
>>>> But as per the Oauth 2.1 proposal, password grant is going to be removed.
>>>> Can you suggest the way forward for us? I believe we are not a one-off
>>>> case.
>>>>
>>>>
>>>> Thank You,
>>>>
>>>> Beena

---

From: Evert Pot <[email-masked]>
Date: Thu, 14 May 2020 01:03:05 -0400

On 2020-05-10 10:20 a.m., Aaron Parecki wrote:

> password grant is being removed from OAuth 2.0 by the Security Best
> Current Practice. Can you clarify what you've found useful about the
> password grant that the client credentials grant doesn't solve?

One nice benefit of the password grant, is that client_id is a nice,
general way to trace what application did the log in. Handy for audit
logs and if we ever find a security issue we could hypothetically
invalidate all passwords used by the client_id that introduced the issue.

The alternative is to introduce a custom parameter, but this is unlikely
to work easily with existing OAuth2 implementations.

So, I will miss "password".

Evert

---

From: Beena Santhosh <[email-masked]>
Date: Fri, 15 May 2020 21:43:24 +0530

Hi Aaron,

I had a re-look at this and the difference I still see is that I am able to
use a common client_id with Password Grant, which does not seem possible
using Credentials Grant. Without Password grant I don't see a way to
achieve this.

Thank You,
Beena

On Tue, May 12, 2020 at 12:40 PM Beena Santhosh <
[email-masked]> wrote:

>> With the password grant you'd then need to register 50,000+ user
>> accounts, right? How is that different from registering that many clients?
>>
>>>>> But as per the Oauth 2.1 proposal, password grant is going to be
>>>>> removed. Can you suggest the way forward for us? I believe we are not
>>>>> a one-off case.
>>>>>
>>>>>
>>>>> Thank You,
>>>>>
>>>>> Beena

---

From: Mohamed Seada <[email-masked]>
Date: Fri, 15 May 2020 19:44:01 +0200

Hi,

If the client credential is being used by the first-party client, you can
use a generic token that could access any resource.
The need for a password grant here is to identify the resource owner with
his credentials, as this is just for first-party, you don't need his secret
just id.
I think (not in spec.) this could be achieved by adding a new optional
parameter for client credentials resource_owner_id.

Thanks,

On Fri, 15 May 2020, 6:13 pm Beena Santhosh, <[email-masked]>
wrote:

> Hi Aaron,
>
> I had a re-look at this and the difference I still see is that I am able
> to use a common client_id with Password Grant, which does not seem possible
>> spec the client secret is optional for Password Grant. Hence we choose
>> to use a common client_id across all the devices. The first party client on
>>> beenapurushothaman@gmail..com <[email-masked]>> wrote:
>>>
>>>> Hi Aaron,
>>>>
>>>>>> removed. Can you suggest the way forward for us? I believe we are
>>>>>> not a one-off case.
>>>>>>
>>>>>>
>>>>>> Thank You,
>>>>>>
>>>>>> Beena