AADB2C: Support OAuth 2.0 client credential flow
As mentioned in the B2C limitations:
Our daemons / server-side applications need this feature as part of our security implementation in order to grant access to our web apis.
Currently, you can use “App Registration” blade in the Azure Portal (outside of the Azure AD B2C blades) to register an apps that define application permission and the register apps that use client credentials to request these. The caveat is that this is done using the same mechanism that you’d use in regular Azure AD.
Ideally we’d have a first class experience for this in the Azure AD B2C blades or at least have an Azure doc that walks you through the experience I just summarized, so I’m leaving this feature ask open.
It would be great if you guys can add comments with your feedback. What scenarios areyou trying to achieve? Does the approach above help you achieve what you want to achieve? Does the experience to do so work for you guys and if not, what would you like to see?
Felix Müller commented
We would like to allow our users to grant access to their data to third-party applications using a standard protocol, OAuth2 Client Credentials flow would be the most popular choice.
Using a regular AD App registration is cumbersome, because
1. We would need to provide dynamic access to the underlying tenant's application registrations, also granting API access for every requested client.
2. Issuer validation in the back-end applications becomes more difficult.
Using resource owner password credentials flow is not secure, and the application would be tied to a specific user.
Ideally, we would like to dynamically register a B2C client (different issue in this feedback forum), and provide a custom policy for "headless" use, that can be activated for the client-credentials flow. This would also allow use to include custom claims in the client's access token.
Maulik Modi commented
Maulik Modi commented
Custom Scopes are Essential to govern desired APIs to be made accessible to caller.
Look at how IdentityServer allows this, https://identitymodel.readthedocs.io/en/latest/aspnetcore/worker.html
One more example is from Auth 0, that allows defining custom permissions and then creating clients with specific api permissions.
Patrick Heinzelmann commented
The usage of the "App Registration" for Client Credential flow works technically, but the problem is that you can't really specify any custom scopes as you have to use the default scope ".../.default" to successfully authenticate.
This solution is not really working for apis, where a developer have to define permissions of the client via the scopes.
Clarino, Jude Daryl commented
This has been in limbo for quite some time, any updates on this?
Joe Smith commented
login.microsoftonline.com is only deprecated for flow based accesses. Using it for client credentials does and will continue to work, because that part is part of the shared codebase with normal AzureAD tenants.
Direct logins against the underlying AzureAD tenant is a bad idea (except as an internal part of a Custom Policy) since it has major limitations, does not properly support social logins, etc.
I will admit that using the underlying Azure AD tenant for client credential tokens for accessing your own services is less than ideal. That workaround is an OK solution for things like accessing the Graph API, since in that case your own code does not need to parse the access token at all.
I suppose the issue here is that the existing policy system is all about generating claims for a user from potentially multiple sources, with transformations and validations throughout the process and is not really set up for just providing access tokens for client credentials.
Our organization has been using B2C as our IDP and although using the AD mechanism works for client creds ( login.microsoft.com ), it would be nice to authenticate against b2c so that it returns the same issuer.
issuer through AD: login.microsoft.com/tenantId
Issuer through B2C: tenant.b2clogin.com/tenantId
Note that these are for APIs that provide endpoints for both UI ( auth code / implicit ) and for services ( client creds )
Georgy Grigoryev commented
When it's going to be implemented? there's no real solution of the problem and all the workarounds are just using another your product instead of sticking to one.
Raphael Schnaitl commented
Can anyone pick up on this again, it is basically not possible to use Azure B2C as replacement for Auth0 or AWS Cognito. The "workaround" is no solution, it generates a different token that is not valid without backend changes. Which is not what People want to achieve if they use OAuth 2.0.
Have to stick with Auth0 for the moment.
Umair Butt commented
I would also ask the same question as @ZigZag59. What happens when login.microsoftonline.com retires for b2c?
All our services are protected by Azure AD B2C. Currently, we use "b2clogin.com" to authenticate users and "login.microsoftonline.com" with the "client credentials" flow.
The "client credentials" flow is used in two scenarios :
1. service to service communication without user context
2. save calculation results from a scheduled job every nights.
On 04 December 2020, "login.microsoftonline.com" will be unavailable to access Azure AD B2C tenants. What will be the solution if you don't support client credential flow ?
Hossam Barakat commented
I had to use Client Credentials grant flow with Azure AD B2C and ASP.NET Core API and some steps were not straightforward hence I have written down all the details in this post: https://www.hossambarakat.net/2020/08/14/azure-b2c-client-credentials/
Lars Kemmann commented
This is a duplicate & should be merged with the following idea:
Tim Clyburn commented
It seems that it is over three years since a microsoft said that they would "at least have an azure doc that walks you through the experience" yet there isn't one. This really is a limitation in B2C with the lack of support for all oauth flows.
Any chance of an update or a doc that provides details on how to do this in the suggested way?
If nothing more please update the early pages of the documentation to clearly state this missing feature. I only discovered it after several hours of study and implementing the examples.
> It would be great if you guys can add comments with your feedback. What scenarios are you trying to achieve?
All the scenarios this functionality is designed to address.
PAILLASSE SYLVAIN commented
Hi, seems like it can be achieved using ROPC:
I was able to make it work using Postman at least.
any one got the workaround to work?
Dinesh Kumar Sarangapani commented
Few use cases where we cannot use Azure AD and we need this to be supported by Azure AD b2c blades,
1. Token returned will have b2c as issuer
2. Token returned will not be singed by the token singningKey
3. Add additional claims to the access token using the IEF.
In OAuth2 the authorization server which issues the token MUST issue the same kind of tokens issued with different grant types like Authorization Code or Implicit.
With the workaround, this is defeated. So it is essential to have the token issued by the B2C with the flexibility to change the mentioned.
Antero Karttunen commented
I would say this is workaround for daemons / server-side apps ( when using ad b2c only )
You can get access token without prompt & then your code can call your secured api :)
Alexander Mason commented
ISV desire to use same base custom policy logic for its customers to enforce concerns such as tenancy and customer entitlements, etc. for both user and browser-less authentication