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