> In the password grant flow, the device holds the password and is not
involved in any interaction with the AS. This keeps the device use case
simple.
I'm not sure what you mean by this. If you're suggesting that the client
never interacts with the AS and sends the password directly to the resource
server, that's never been part of OAuth. That's specifically the situation
OAuth was created to avoid.
The password grant gave the client a way to exchange the password for an
access token by sending it first to the AS. As such, the difference between
the password grant and the client credentials grant is the presence of two
additional parameters in the request to the AS:
POST /token
grant_type=client_credentials
&client_id=X
&client_secret=Y
vs
POST /token
grant_type=password
&client_id=X
&client_secret=Y
&username=Z
&password=Q
The response of both of these is an access token, which the client then
sends to the resource server.
> 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
Regardless of which of these two methods you use, the client's credentials
(either client ID/secret or username/password) needs to be enrolled at the
AS in order to get an access token. That's why I'm saying there isn't a
functional difference and trying to clarify why you think the password
grant is a better fit for your situation. In reality for your use case it
seems it is only adding complexity to the situation compared to just using
a client ID and secret.
Aaron Parecki
On Mon, May 11, 2020 at 7:11 PM Francis Pouatcha <fpo=
40adorsys...@dmarc.ietf.org> wrote:
> Hi Aaron,
>
>>
>>
>> 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?
>>
> Beena could use the Dynamic Client Registration to have all those devices
> registered as oAuth Clients. But this seems to be inconvenient as he
> describes.
>
> In the password grant flow, the device holds the password and is not
> involved in any interaction with the AS. This keeps the device use case
> simple.
>
>
>>
>> Aaron Parecki
>>
>>
>> On Sun, May 10, 2020 at 3:18 AM Beena Santhosh <
>> beenapurushotha...@gmail.com>
>> 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
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20200510/8873117a/attachment.html
>> >
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> ------------------------------
>>
>> End of OAuth Digest, Vol 139, Issue 45
>> **************************************
>>
>
>
> --
> Francis Pouatcha
> Co-Founder and Technical Lead at adorys
> https://adorsys-platform.de/solutions/
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
