Re: [OAUTH-WG] Usage of Password Grant

[Beena Santhosh <[e-mail]>]

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 <
[e-mail]> wrote:

> 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 <[e-mail]> 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 <
>> [e-mail]> 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 <[e-mail]> 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
>>>> 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 <
>>>> [e-mail]> 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
>>>>> 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
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>