I don't understand how the 'Scopes' in Azure B2C are supposed to be used. They are associated with an API, but not a user. I'm sure I'm missing something, but I see no practical use for something associated with an API. I've used and implemented Claims-based authentication based on a user's role in the database.
For example: ordinary users of an API should not have the authority to delete an object, but administrators should have the authority. Does someone have a practical example of how these B2C 'Scopes' can be used to limit a users access to the API?
They are associated with an API, but not a user.
That is correct. I like to think of the association to the API as defining the 'surface area' of the API. For example, this API defines 2 scopes
read
write
Now, you could define two applications. One application that only has read permissions and one that has read and write permissions.
For the common use case of one Web App and one Web API it adds no value. I've been using a scope of no-op for such cases.
I've used and implemented Claims-based authentication based on a user's role in the database
You can use custom attributes to assign "role(s)" to the user. You can set them via the Azure AD Graph API to keep the setting of them secure. You can also set them during sign-up (this is much more involved though).
When you request an access token for that user, the custom attirbute(s) you defined and set will be readable in the API to check permission(s).
Comment Feedback
If I promote or demote a user, I need to change the endpoints (policies) they access at the client.
No need to change the policies. You would update the custom attribute for that user via the Azure AD Graph API.
My problem is that I'm mystified at the an authentication system that authorizes endpoints ("scopes") instead of users
Yeah, me too! I think it might have to do w/ the purpose of the product. B2C is about self-service sign-up, password reset and federating w/ other IDPs (like FB, Google, etc). Maybe Azure AD is a better solution when you want to control permissions on a user. Not sure, still learning!
I still don't see the practicality of splitting your API into several different parts based on the security. An API should be a collection of functionally related services
You don't split your API. You can split your app(s) that utilize the API. See above.
Documentation Reference: Requesting access tokens, GitHub Issue to improve the documentation.
Roles and scopes provide the two halves for this user access control.
Roles -- such as Administrator, Member, and Guest -- determine whether an authenticated user is permitted to delete objects.
Scopes -- such as read, write, and delete -- determine whether an authorized application can delete objects on behalf of an authorizing/consenting user if this user, through their role assignment/s, is permitted to do so.
Azure AD B2C doesn't have any current support for managing roles and assignments of them to users.
It does, however, have support for managing scopes and assignments of them to applications.
Related
I have created an API that is protected by OAuth using an app registration in Azure.
My app registration does not require assignment, but it exposes a number of roles that the underlying API verifies. To my understanding, this accomplishes almost the same thing as requiring approval.
So far I've only had user/group roles but now I've added an application role intended for integrators, and I want other application owners to be able to request permission to my API. I, as the API owner, would like to review these and either reject or consent to the request. E.g. I don't want everyone to be able to access my API within the tenant without my knowledge, just like all users/groups don't have access with me assigning them to a role.
The Role-based access control for application developers documentation makes it very clear who manages access:
...an application developer defines roles rather than authorizing individual users or groups. An administrator can then assign roles to different users and groups to control who has access to content and functionality.
However, if you create a role with allowed member types set to application, things are not quite as clear and it seems to behave more like a scope, where I give up any access management. Also from my limited understanding, a scope is used when the API needs to request data from the user (e.g. wanting to read their username), whereas a role is used for the application developer to control access to what they are developing.
This is what it looks like when I request access to my API from another app:
This same page mentions the following information:
The "Admin consent required" column shows the default value for an organization. However, user consent can be customized per permission, user, or app. This column may not reflect the value in your organization, or in organizations where this app will be used.
As well as:
Applications are authorized to call APIs when they are granted permissions by users/admins as part of the consent process
However, from my reading, it sounds like this never gives me, as the API owner, any insight into who has access to the API I own. I want to control application access the same way I'd assign a group or user to a role in the enterprise application.
Can this be achieved when it's an application on the other end, not a user? If not, how would I allow applications to integrate in a controlled manner?
I want to explain the feature Azure ad provided to protect web api here.
As you know, we usually use a token in the request header to let the api check if the request had correct permission to visit the api. Such as if the request from an allowed user role, right? So to whole progress should be authentication and authorization. Users sign in first then try to generate an access token to visit an api. Azure AD has similar architecture.
If you had a web application(e.g. web mvc app) you can integrate Azure AD into it then you can allow users use their user1#xx.onmicrosoft.com account to sign in. If you had a web api project, you can also integrate Azure ad and add [Authorize] attribute above the controller so that the incoming request should contain a correct Bearer token which we call it access token.
For Azure AD, we usually have 2 options, verification scopes or app roles. That results from the different flows we used to generate the access token. For example, we use auth code flow to sign in users and generate access token containing scp claim which is granted delegated api permissions. And we use client credential flow to let an application to generate access token containg roles claim which representing it's granted application api permissions. In short, when we set [Authorize] + [RequiredScope(scopeRequiredByApi)] in the controller, it allows requests from a user(user sign in the app and call api), when we set [Authorize(Roles = "roleRequiredByApi")], it allows requests from the application(no user signed in and the app call api by itself).
Here scopeRequiredByApi and roleRequiredByApi is what you exposed and then added to App Registration > Permissions. Just like Integrator you marked in the screenshot, it can be recognized as roleRequiredByApi because its type is Application.
And I'm afraid the roles is not what you want but to be honest what I said is what AAD can do for you... And I think the document I mentioned above about verification scopes or app roles will be a good sample for you.
The App Registration > Permissions section has a great feature for reviewing and limiting the access provided for your app registration:
enter link description here
In addition you should always define the scope of your permissions and limit it to the least required for your app. eg. NEVER set scope at the subscription level! Always set it at the resource group or lower.
Also note that Microsoft now provides Defender for APIs and you can use Sentinel to monitor a lot of the activities related to your app registration. Always always enable logging wherever possible and configure some method of alerting/reporting so you can better understand the activities for your app.
From the documentation it seems that using an application that is in the B2C tenant and thus hosts user accounts that there is no way to directly access Microsoft Graph API via a logged in user per their own context.
I want to establish the use case properly so that the solution is that which makes the most sense.
The use case is that if a user wants to edit claims for example such as permissions they would be able to do so while logged in through Azure B2C.
The flow would be. Logged in user -> can change certain claims information such as address, surname, and other custom policy fields (SEO contact permissions.)
Is the proper way to do this is to build a proxy that will take the application's AD application permissions which are allowed to call out to Microsoft Graph and pass along user context so that the scope will be limited to that user only?
For example. User logs into the app.
The app has AD permissions that are granted admin consent
Create a client secret to prove application identity upon request of a token
Now can access Microsoft Graph api
Ref of Registering an app with Microsoft Graph api
What's not clear here exactly is the next part. My user is logged in with Azure B2C. Should I just pass along their id token which has their claims to the application? How do I put in scope/context of the logged in user of the app permissioned access to Microsoft Graph?
This part is not clear in any documentation.
I don't want a logged in user to have access to everything.
Is a proxy the only way to do this?
If a proxy is the only way to do this what identifier or id is what should be used to pass along to the query to assure only that user is in context?
Am I thinking of this incorrectly and or is there a better way to do this other than a proxy?
The documentation says this.
Apps that have a signed-in user but also call Microsoft Graph with their own identity. For example, to use functionality that requires more elevated privileges than the user has.
That doesn't fit exactly into my use case above or address it really but I think it is related. The functionality should be considered to be an elevated permission but to the scope of the user. This user can change this claim via their own logged in entity. What do you call that and what is the best way to solution this?
Lastly, is there anything that should be known in the MSAL library including Angular and React that would be useful in this process? It seems like I will have to converge the 2 to obtain the access token of the app and of the person and proxy those out to a backend service (the proxy) to then do a body of work.
Am I thinking of this correctly?
This Stack is the closest to relevance but doesn't ask or solution the entire use case as I have here. But is useful for illustrating the confusion.
"Logged in user -> can change certain claims information such as address, surname, and other custom policy fields (SEO contact permissions.)"
Why can't you use the Profile Edit user flow? You can configure what attributes the user can change.
I'm new to Azure ADB2C, and am confused by some of the terminology.
I am building a motorcycle ride monitoring website that I would like users to be able to log in to by verifying a social media identity (Google & Microsoft Account, for now).
But I only want users who are members of the site to be able to use certain features. For example, I'd like everyone who authenticates to be able to apply for membership, read about the benefits of membership, etc., but I only want members to be able to initiate ride monitoring.
Is the recommended approach here to only authorize (rather than authenticate, if I'm understanding the terminology correctly) certain authenticated users (i.e., members) to use the ride monitoring services?
If so, what's the best way to authorize a member? Look up their email (which I require to be returned from the authentication process) in a standalone database and proceed accordingly? If I go that way, what's the simplest way of adding their membership status to their credential, so I can access it throughout the site?
Apologies for not providing code here. I've got a bit of it hanging around :) but this is more of a design question than a coding one.
Azure AD B2C is primarily Authentication as a Service. There are ways in which it can be used for what you are trying to achieve here.
You can use custom (extension) attributes in AADB2C (https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-reference-custom-attr) in combination with AAD Graph apis (https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-devquickstarts-graph-dotnet). So when user authenticates and applies for membership, you can call AAD graph api to set the custom attribute on user object. You can get the extension attribute in a the token after the authentication happens. This token will give you membership of the user.
You can also use AAD Groups instead of custom attributes. In the tenant, create membership groups. Once user authenticates, call AADGraph to set/get user's membership of a group and that will give the authorization information.
You can also do what you described, maintaining the info in a database store of your application. But the first two functionalities provide in-built functionalities for user management.
I have 1 SPA-Application which uses another WebApi. (ASP.NET Core) Both are running in Azure and I am able to authenticate the user against Azure AD B2C with OAuth 2.0 Implicit Flow
Now I am asking myself how I can control the permissions of a single user. (Delete, Read, etc.) Do I have to work with claims? Do I have to leverage the graph API on the server side to check if a user has a certain permission? Can I use scopes? Where can I set the User <--> Scope relationship?
I have found several questions on SO, but I don't get the idea of how it should be done the right way? My current understanding is that I ask the authentication provider for certain scopes and I will get a token with this scopes which then can be checked by the API. But how do I manage which user can ask for which scopes?
I really have a problem to wrap my head around OAuth2 and permissions. Hope one can help me here.
Unfortunately, for one specific user, you cannot assign permissions/scopes to the user.
Because Azure AD B2C doesn't support Application Role. Generally, Azure AD B2C is for all users to access your App wit their account. Even Azure AD B2C can let you store and manage users, but it cannot assign different scopes/permissions to different users. Multiple scopes are the permissions granted to the resource. Multiple granted permissions will be separated by space.It's not for users access assignment.
If this important to you, you can upvote this idea in this Uservoice Page. Azure Team will review it.
Hope this helps!
You can implement this by creating a custom attribute of type String that stores a comma- or space-separated list of roles for a user.
You can then issue this custom attribute in the ID and access tokens or read it using the Azure AD Graph API.
We have a multi-tenant single page app (and backend) that uses Azure AD for authenticating users. We'd like do queries to customer's Azure AD for retrieving groups but make it an opt-in behavior for customers (tenants). The reasoning behind that is that not all customers necessary need the functionality and would rather not grant us access to their AAD unnecessarily.
Is there some way of implementing this with Azure AD?
I've been trying to test with different OAuth /authorize calls with resource IDs and scopes but mostly I end up with "AADSTS65001: The user or administrator has not consented to use the application with ID ''. Send an interactive authorization request for this user and resource." error. Configuring the web app or backend to require the permission would surely fix the error but that will also make the approval of it mandatory for all users of the app.
Is there a way of using the authorize/consent API to request access to a new application on-demand?
An ugly work-around that should work would be to have 2 client IDs and 2 backend IDs with different permissions but ADAL.js doesn't seem to be designed to work with multiple Client IDs (it's singleton, for starters). Also Application Permissions should of course work but I'm not sure how much of those are required to search for groups.
Is there a way of using the authorize/consent API to request access to
a new application on-demand?
Do take a look at Azure AD v2.0. With their incremental & dynamic consent model, it is possible to do so though I am not sure if this specific functionality (managing groups) is available there.
I had a discussion with Azure AD team member recently about this (as we are also facing the same problem) and he suggested that we take a look at this.
Essentially the way things work in Azure AD v2.0 is that you start with basic set of permissions (like sign in, read profile etc.). Then when some tenant need specific permission, you essentially ask them to grant those permissions to your application at that time only. What this means is that different users in your application have granted different permissions to your application.
If you are using MSAL, and looking for a way to dynamically change your scopes before authenticating, have a look at this: https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-angular/docs/v2-docs/configuration.md#msalguard---dynamic-auth-request
More here: https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-angular/docs/v2-docs/configuration.md#platformbrowserdynamic