Re: [OAUTH-WG] Usage of Password Grant

[Mohamed Seada <[e-mail]>]

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