For a native app you can have one clientID and no secret (same as having one secret for all of them) or you can use dynamic client registration to give each one a separate client_id and secret.
The middle ground is to use PKCE and no client secret. The client generates a pkce challenge in the authorization request and then presents the verifier. You can then use that verifier to place a identifier for that app instance in the refresh/access tokens. That would allow the RS to differentiate between two clients with the same user on different devices. That gets you more or less equivalent security, but binds the client instance to a user/device as part of the authorization flow, rather than by creating separate client_id for each instance and managing that. It is up to more of a deployer preference on what way to go. I prefer the PKCE route personally, that requires a real user to be involved in the flow before the AS needs to store state. In open dynamic client registration you can face a denial of service attack by creating unlimited clients, that is harder to manage. One thing that will be coming up at the WG meeting today is the possibility of extending PKCE verification to refresh tokens as well as there current use with code. That would move the PKCE and client registration security even closer together. John B. > On Nov 5, 2015, at 1:01 AM, Sergey Beryozkin <sberyoz...@gmail.com> wrote: > > Hi All > > I'm having a discussion with my colleagues on the pros and cons of sharing a > client_id. > > For example, say we have N number of public mobile applications (the same > application package, an application instance on an individual phone), and one > approach is for each of these applications to have the same client_id. > > I've been trying to analyze why it can be bad and the only thing I can come > up with is that there will be no (easy) way to track which application > instance actually accessed a given RS. > > Can someone please explain what the pros and cons are of having the same > client_id shared between public client applications. > > And what about multiple confidential clients being set up with the same > id/secret. I suspect it is a bad idea but what is main line why it is a bad > idea, lets say it is all done in the protected network, no chance of the bad > clients interfering... > > > > Thanks, Sergey > > _______________________________________________ > 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
