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 <aa...@parecki.com> 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 < > beenapurushotha...@gmail.com> 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 <aa...@parecki.com> 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 < >>> 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 >>>> >>>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
