-
Notifications
You must be signed in to change notification settings - Fork 202
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding ROPC Support to Confidential Client Applications #294
Comments
Conceptually, Microsoft identity platform chooses to put such a constraint to ROPC: "No web sites/confidential clients - This is not an ADAL limitation, but an AAD setting. You can only use those flows from a native client. A confidential client, such as a web site, cannot use direct user credentials." It is mainly to discourage a server-side confidential client to "hoard" lots of end user passwords, which would present as a security risk. Besides, there are also many other constraints come with ROPC. On the other hand, in your automation use case, "leverage the client secret as well, just to add a bit of extra security", may not really make much difference. You might as well just set that ROPC password with your automation deployment. |
Totally understand that, but per Microsoft ROPC document a client secret should be used if the application is a confidential client. We generally frown upon the use of ROPC, but in the cases stated in my initial post, there are use cases that ROPC is still needed because of the limitations of limiting the scope of application permissions. And because of that I figured I'd raise this feature request on seeing if it could be considered. Worse case we just tell the application team that they can't use MSAL. The little bit of "extra security" is not allowing the a token to be acquired with just simply a username and password. We haven't allowed any public client app registrations to use ROPC in our environments. |
We are discussing this internally. Marked as enhancement. Also exploring when the limitations in more secure flows can be addressed. |
Application permissions give an over reaching amount of permissions. For example if I give the application permission Calendar.Read from MS Graph I have the ability to read everyone's calendar that is within my company. The use of ROPC is still required to have restrictive access in an automated fashion. Back to the example, using ROPC allows the use of some generic account that has only access to some number of calendars so that we're not giving read everyone's calendar level of access. We're aware of the use of the Application Access Policies that can be assigned to app registration that can restrict access, but you can only have 100 of those per tenant (which would be maxed out in a week if we advertised those permissions). Power BI is another that is primarily built on delegated permissions and requires ROPC for doing automated things with it.
We'd like to at least require out developers to have to leverage the client secret as well, just to add a bit of extra security.
The text was updated successfully, but these errors were encountered: