I have an AzureAD application registration for my front end SPA. I am using Angular with Microsoft’s #azure/msal-angular v2 authentication library. My app registration has all the necessary redirect URIs and configured for proper OAuth2 OpenID Connect using authorization code flow with PKCE. My app is using the Microsoft Graph API with only the User.Read scope. I can authenticate just fine. If my app, however, is only available for one group of people, defined by an AD group and assigned to the Users and Groups section in Azure, what is the best way to validate the logged in user is authorized? I’ve tried enabling optional group claims for the access token, but those don’t come through for some reason. I then tried adding roles-I have an “admin” role, which is the only one I need. This role is assigned to the AD group I mentioned earlier. The roles claim does come back, and I can use that, but this seems silly when I should be able to just validate if the logged in user is in my AD group. The roles approach does have the nice feature of just assigning users different roles to validate authorization for development purposes, but not sure if there’s a better way.
At some point there will be an API I need to plug in. Would it be best to get the claims from that and use that for validation?
Is there a scope or setting I’m missing? Am I achieving this all wrong? Thank you to all who reply.
At this point, you have a SPA that calls a MS 1st party API, which is MS Graph.
Since you are acquiring an accessToken to MS Graph, this accessToken can not be changed - it is meant to be decoded and validated by MS Graph itself, so you will not be able to add any extra claim on that token since you do not control the resource.
Also, your client should treat the accessToken as an opaque string, you should never rely on any claim from the accessToken on the frontend.
You can read more about it here:
https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens
If you want to do some sort of authorization on the frontend, like deciding which routes your user will have access to, you need to rely on the idToken. For the idToken, you can enable the Groups claim and get a list of groups that the user is a member of.
If, as mentioned, later down the line you need to create a custom API and call it from your SPA, then, on that scenario, you can indeed add the Groups claim to the accessToken, because it will be a resource that you control, and then authorize the requests that hit your API based on that claim
MS has a sample that shows exactly how to use security groups for access control, using an Angular frontend with a .NET Core Web API. Give it a check here:
https://github.com/Azure-Samples/ms-identity-javascript-angular-tutorial/blob/main/5-AccessControl/2-call-api-groups/README.md
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 currently using node.js passport library to authenticate using the OIDC Strategy with an azure registered app using a client ID and secret.
http://login.microsoftonline.com/{org id}/v2.0/.well-known/openid-configuration
I am not having any trouble getting the user profile back of the person who logged in, but I am hitting a wall when trying to get the groups. In my app, I need to authorize the user based on their active directory groups. I am getting back this piece of json:
"_claim_names\":{\"groups\":\"src1\"},\"_claim_sources\":{\"src1\":{\"endpoint\":\"https://graph.windows.net/{org guid}/users/{user guid}/getMemberObjects\"}}
I'm not sure what I need to do using this to get the groups. I tried generating a bearer token, passing that in a header, and getting the groups but it says I am unauthorized using Postman. Do I need certain permissions in the app? Also why is it using graph.windows.net when I'm trying to use graph.microsoft.com?
Is there an easier way to do this once the user has logged in?
Overage indicator claim when user is member of many groups
The claim you're getting back as part of json shared in question is an overage indicator claim.
"_claim_names\":{\"groups\":\"src1\"},\"_claim_sources\":{\"src1\":{\"endpoint\":\"https://graph.windows.net/{org guid}/users/{user guid}/getMemberObjects\"}}
It means that the user is member of many groups and instead of including information about all the groups as part of token (which would make the token too big), you will need to query that information separately.
Read more about it here: Access Tokens Reference
How to get groups information?
Your application needs to make a separate call to Microsoft Graph API to get the groups information for user.
Relevant Microsoft Graph APIs
user: getMemberObjects
user: getMemberGroups
Check member groups
Permissions Required by your application
Each of the API links above mention the required delegated or application permissions that are required as part of documentation.
You will need to update your app registration in Azure AD to require the relevant permissions (and also go through Admin consent, in case the permission required needs admin consent)
Token to call Microsoft Graph API
You mention that you've tried generating a bearer token, passing that in a header, but you got Unauthorized error.
Once you're done with the permission changes for your application, acquire a token specifically for Microsoft Graph API from your application. The bearer token used to access your application may not directly work with Microsoft Graph API.
Also make sure you go through Admin consent in case any of the permissions require Admin consent. If it's a single tenant application, "grant permissions" directly from azure portal by an administrator should work, in case of multi-tenant app you can use the Admin consent endpoint.
Code Sample: Here is a quick tutorial for calling Microsoft Graph using Node.js.. you may find other good ones as well.
Azure AD Graph API (graph.windows.net) vs Microsoft Graph API (graph.microsoft.com)
You have a valid question about the endpoint.. "Also why is it using graph.windows.net when I'm trying to use graph.microsoft.com?"
General recommendation is to use the newer Microsoft Graph API, unless the functionality/information you're looking for isn't available with Microsoft Graph and only Azure AD Graph API can help. Read more about recommendation and comparison here: Microsoft Graph or Azure AD Graph
Since information about groups is available in v1 endpoint for Microsoft Graph already (not beta), you should make use of Microsoft Graph API.
Here are a couple of related SO posts: SO Post 1 and SO Post 2
I have a problem regarding the permission granted to my app by the user showing up as a scope in my JWT.
I want to allow the user to see a list of his tenants (Office 365) on my page. For this I need a token with the https://management.azure.com/user_impersonation scope. I added the permission to the Azure API Permissions. When the user first logs in he sees this:
From this screen I assume my setup works, since the user gets asked to grant my app permission for what I need (Access Azure Service Management as you). But when I paste the JWT on the JWT Debugger I don't see the scope user_impersonation among the scopes.
I get this:
I already tried to remove the app from the test-user's applications (in their Azure Portal) to get it to ask again for consent but it's still the same. Other test users have also the same result.
What I'd need is simply to see user_impersonation among the scopes. That would allow me to call the API endpoint that returns a list of my user's tenants.
You need to acquire the access token for the https://management.azure.com resource.
Or if using v2, request it for the https://management.azure.com/user_impersonation scope.
That looks like an MS Graph API token.
An access token is always only valid for one API, so you need to ask for a token for the Azure Management API.
It works now!
So, I tried to get scopes for both https://management.azure.com/ and https://graph.microsoft.com/ in one single token. As Juunas explained, you have to get a separate token for each API. But can ask consent for both at the same time though.
My flow is this now:
I log the user in while asking him to consent to some permissions (for both API's and on first login only)
I request a token in the background for the Graph API scopes
I request a second token for the Azure Management API scopes
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