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