I have a SPA React application which use MSAL for logging users in and acquiring tokens for querying MS Graph. Currently, when the user is created he/she can have two different roles, namely:
Administrator
Viewer
As is, every user is allowed to get the same scopes from AAD - Regardless of whether they are one or the other role.
This presents a problem - Because any of the users potentially have the same permissions when calling MS Graph, i.e. they could acquire the token themselves and request graph with full scopes.
The viewer role should only be able to have the [User.Read] scope, while the administrator should be able to alter every aspect of Azure AD.
Additionally, the administrator should be able to perform actions in MS graph that isn't supported by delegated permissions, i.e. creating new users.
The following makes me think that I may need to rethink the way that users are requesting resources from MS graph - which lead me to thinking that the on-behalf-of flow would be an interesting option.
As I imagine, the flow would work as follows (from when a user logs in, and requests to create a new user in my SPA)
User logs in with MSAL in my SPA
User gets the least privileged scope, i.e. [user.Read]
User creates a new user
SPA sends a request to my Web API with the users' token as bearer
Web API validates the user token with AAD
Web API validates that the user has a role of "Administrator"
Web API gets a token with ["User.ReadWrite.All", "Directory.ReadWrite.All"] scopes
Web API calls graph with the fetched application scopes on behalf of the user
Web API returns the data to my SPA
Since I'm fairly new to this world - I'm wondering if my way of thinking makes sense. In particular, I'm curious if it's really possible to request elevated permissions ["User.ReadWrite.All", "Directory.ReadWrite.All"] on behalf of a user with only the [user.Read] scope from my Web API.
Additionally, I'm of cause open for any suggestions for alternative ways to solve the above issue.
Scopes (delegated permissions) apply to an application, not a user.
Fundamentally, no matter what scopes the user gets in their token, they cannot do anything they were not already able to do.
Microsoft Graph API checks the scopes to check the application's permissions, and then checks the user's permissions to see if they are also able to do the operation.
Thus a user can never elevate their permissions through scopes.
If you have any of your own APIs, you should also handle authorization in a similar way.
If scopes are used, also check the user's permissions.
In case of application permissions (app roles with member type application), there isn't a user so your API would only check these permissions.
This is why you need to be extra careful with authorization if your back-end uses application permissions instead of on-behalf-of flow; since they don't include the user, it could allow them to elevate their privileges through your application.
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 ideally want to be able to have an admin grant application permissions for my app and login to said app in the same flow. Is this possible?
I currently use the code grant flow for authentication.
I then use the client credentials flow for authorisation.
Is it possible to combine the two into a single flow?
I have the first redirected immediately to the second if the client token has not be granted before, but it isn't the most appealing flow from a UX perspective.
If I could add an ID token to the the client grant response that'd be perfect (I just need the UPN of the admin that is consenting), but this doesn't seem to be possible.
A key requirement is the application permissions as my app makes changes to the entire org - obtaining the grantee's ID in the same flow is just a UX optimisation.
Perhaps this is possible with the OpenID Connect flow?
Is it possible to combine the two into a single flow?
No, these are two different authentication flow.
For the authorization code flow, It's used to perform authentication and authorization in the majority of app types, including single page apps, web apps, and natively installed apps. The flow enables apps to securely acquire access_tokens that can be used to access resources secured by the Microsoft identity platform endpoint, as well as refresh tokens to get additional access_tokens, and ID tokens for the signed in user. This flow is usually used in scenarios with user interaction.
For client credential flow, it is that the administrator directly grants permissions to the application itself. When an application provides a token to a resource, the resource will force the application itself to have the permission to perform operations. This type of grant is usually used for server-to-server interactions that must run in the background and do not require immediate interaction with the user. This is generally used in daemons, which can only obtain access_token for accessing resources.
Perhaps this is possible with the OpenID Connect flow?
This is where a user is logged in. Generally, delegated permissions are used, so it is impossible.
So, in summary, you cannot obtain ID tokens when using the client credential flow because there is no user interaction in the flow.
I need to write a backend app to read & write one company emailbox.
I have registered Active Directory Application and granted Delegated permissions (read and write to user mailbox).
Question is how to get the token needed for authenticate the graph api calls(for example ListMessages).
From the document I coundn't find any working example for backend app aquiring token and make api calls.
There are two endpoint versions:
Azure AD and Azure AD v2.0 endpoints;
And two authentication method:
1. Get access on behalf of a user
https://developer.microsoft.com/en-us/graph/docs/concepts/auth_v2_user
2. Get access without a user
https://developer.microsoft.com/en-us/graph/docs/concepts/auth_v2_service
What shoud I use ? Really confused.
Thanks all.
According to your description, I assume you want to get an access token without user login page.
Based on my test, we can get an access token that run as a background services or daemons.
It requires administrator to grant the access permission once, then user will not see login popup window anymore.
For more detail, we can refer to this official document.
Sounds like you are looking for Resource Owner Password Credentials grant flow.
However its usage is not recommended.
It does not work in these scenarios:
User has MFA
User password has expired
User is federated (MS account/Google/on-prem AD)
The only scenario that I can think of where this flow is okay is integration tests of APIs where you need to test scenarios where you call your API on behalf of a user.
Here is a better way to do what you want:
Require an application permission to access user emails and have the admin grant it. Now you can use client credentials grant flow to get a token anytime you need one.
Use delegated permissions, have the user sign in once with Authorization Code grant flow. Then exchange the code for an access token and a refresh token. Store at least the refresh token somewhere secure. Use refresh token whenever you need a new token.
The first approach is more reliable but requires broader permissions.
The second has tighter security (only users who have authorized access can have their email read), but has slightly less reliability.
Refresh tokens can be invalidated, in which case you'll need the user to login again.
I am using Azure v2.0 for user authentication. The access token that I receive is used to fetch onenote content using microsoft graph api. And I do store refresh token at my end to access content on behalf of user at any time. Now user opt's out of my system I want to revoke the permissions given by user to my app.
How I can revoke the access without depending on user for that. User may not manually go and revoke the permissions. Is there any api provided for same purpose.
Is there any api provided by Azurev2.0 for the same
Sorry for the delayed response here. Unfortunately we don't have a specific revocation API. And while this is theoretically possible through existing APIs, where the oauth2Permission resource type holds the consent grant (see https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/api/oauth2permissiongrant_delete), your app will need to be granted a privileged permission to perform this action. Contrary to the linked topic, I don't believe that the Directory.ReadWrite.All application permissions actually allows this operation.
Please create a UserVoice request to ask for this API.
Hope this helps,