I have an app registered in Azure AD with the following approved permissions:
Microsoft Graph: Files.ReadWrite.All, Sites.ReadWrite.All, Sites.Selected, User.Read
and
SharePoint: Sites.ReadWrite.All, Sites.Selected
Yet a request to load a folder at / fails with 403 Forbidden (the same C# application that uses a different, registered earlier, Azure AD application works fine - I just can't figure out what the differences are, and how to get second app's permissions to work like the first app does).
Which permissions do I need to read a folder?
Are there logs that can give me more information?
This depends on which authentication flow you use, because you are only granting application permissions, which are only supported in the client credentials flow. So if you're using the client credentials flow, your permissions are sufficient. However, if you are using auth code flow or ROPC flow, you also need to grant Files.ReadWrite.All and Sites.ReadWrite.All delegated permissions.
It turned out, I needed Sites.Selected permission (which I did). However, I had to use the PowerShell PnP module to explicitly grant write permission to my app for each site I need to access. From what I figured out as of today there is no GUI way to do that configuration (I suspect sites could have been configured when the application's permission request was initially granted, but I am not the one who approved those requests).
Related
I created an application named MyApp in my Tenant A with multitenant access. Also, I didn't add any API permissions to it in Azure Portal. I also removed default User.Read permission.
After that, I implement a backend project with using msal4j library. In backend code, I sent harcoded scope Directory.ReadWrite.All.
After that, I run the backend project. The project showed Microsoft sign in pop up in the browser. I provided the credentials of admin of another tenant named B(Tenant B have 16 users). After the successful sign in, the Permission Requested pop-up showed, It was written a description about the Directory.ReadWrite.All. This was normal since I was add Directory.ReadWrite.All as a scope in my backend code.
After approving that requested permission as an admin of Tenant B. I can list the 16 users of the Tenant B with GET /users endpoint of the Microsoft Graph API. So, the MyApp which was created in Tenant A could access the users of Tenant B.
However, how it was possible? Because I didn't add any API permission to my MyApp in the Azure Portal. You can see above screnshot that is empty. I expected to get an error like "Insufficient privilege" when accessing the GET /users endpoint. But I didn't. I can successfully access the all 16 users although I didn't add the Directory.ReadWrite.All API permission in the Azure Portal into MyApp.
If sending Directory.ReadWrite.All as scope from backend project is enough to access to GET /users endpoint. Why we want to use API permissions in the Azure Portal?
The Azure portal permissions are what we call static permissions.
You use them with the ".default" special scope, e.g. https://graph.microsoft.com/.default.
When you specify a scope in the authentication request, that is a dynamic permission.
It is a feature of the newer v2 endpoint that allows you to request the needed permissions at runtime instead of ahead of time.
It's pretty nice for multi-tenant apps since updating permissions can be done more easily, and you can implement optional features better (that require additional permissions).
Docs: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent and https://learn.microsoft.com/en-us/azure/active-directory/develop/consent-framework
My multi-tenant Azure application requires only the app-level EWS legacy permission full_access_as_app to run. This app-level permission can only be consented to by an administrator---it's extremely powerful because it gives the app read and write permissions over every EWS mailbox in a tenancy.
If I, as an admin for my Azure tenancy, grant my application only this single permission behind the scenes in AAD configuration, everything works fine when I run the application for my tenancy.
However when you create a new app in Azure, Azure always assumes you will want the user-level Graph API User.Read permission automatically. When you try to remove the permission you get this ominous warning:
And in the case when I leave it out, interactive OAuth consent forms don't work. The error message looks like this.
The client has not listed any permissions for 'AAD Graph' in the requested permissions in the client's application registration. Or, The admin has not consented in the tenant. Or, Check the application identifier in the request to ensure it matches the configured client application identifier. Please contact your admin to fix the configuration or consent on behalf of the tenant.
In other words, it appears that the application won't be able to run for anyone else's tenancy because their admins can't consent to it.
My hypothesis is that this is because Azure is using the User.Read permission to check whether the person signing in through the OAuth form is an administrator. In other words this permission is needed just this one time, before the application is ever run for the admin's tenancy.
Looking at the actual OAuth consent form, this does appear to be the case.The app wants to sign in and read my profile, to check if I am admin... or so it seems to me.
Am I right about this? Documentation I have been able to find is rather scanty.
I have set up a Azure Active Directory App so that I can access the Microsoft Graph API with MSAL. However, I want to perform API calls without a user (https://learn.microsoft.com/en-us/graph/auth-v2-service) and as such I have added a few permissions that require "Admin consent" to my app. However, I cannot find a way to grant my app these permissions.
I've tried looking around the Azure portal for a way to grant these permissions but without success. I have also tried using the https://login.microsoftonline.com/{tenant}/adminconsent&... link to grant permissions, but unsucessfully so.
The response I received was
AADSTS500201: We are unable to issue tokens from this API version for
a Microsoft account. Please contact the application vendor as they
need to use version 2.0 of the protocol to support this.
I do not have an Azure subscription (not even the free one), but seeing as I was able to add apps to Azure AD as well as get access tokens and then make API calls on behalf of the authorized users I assumed I might not need a subscription.
I just made another app and now I have the grant consent button when I open the API Permissions view.
I use Azure apps to sign users in to a web app and a desktop app. I also query for user information via Microsoft Graphs /user/ endpoint.
So we have to apps registered in Azure; one is a web app / api with permissions to sign users in and read all user profiles from graph. The other is a native app with permissions to the first app, and permissions to sign users in.
In one tenant, this works fine. However in the other tenant the web api har permissions to sign users in, but Graph declines access to the /users/ endpoint due to insufficient privileges. The error is: Authorization_RequestDenied, Insufficient privileges to complete the operation.
However the exact same privileges work fine in another tenant. In the faulty tenant we get a token from graph but when we use the token on the user endpoint it throws the insufficient priv. error.
Signing in users via the desktop app (we use owin) works in one tenant but in the faulty one it sais that app tenant.onmicrosoft.com/guid does not exist in tenant.onmicrosoft.com
The app uri is correct in the settings and the app has the same privileges in both tenants.
We tried recreating the apps since this has solved similiar issues when developing things like this before. This time it doesnt seem to work however. Now I'm at my wits end here. Could there be some other issue blocking here?
The faulty tenant is part of a multi-tenant. However we only poll for users in one tenant as of now.
The apps have also been given consent by an admin via the azure portal. What am I missing here? How should i proceed with trying to fix this error?
Edit: I added a new directory in my tenant and it does not work in this new directory. Same error as with our clients tenant.
Working token for directory A:
eyJ0eXAiOiJKV1QiLCJub25jZSI6IkFRQUJBQUFBQUFDNXVuYTBFVUZnVElGOEVsYXh0V2pUQkVOV21GUUgtZjRGS0VjYlIwU3Y1NndrdzhvSjhjbDIwX3JtZEJBc2h6eDhKT2VNZjFEbVFjNm1GUUdxZ2VSRFJZMTEzNXE3ZXJkTjlHTFZ6T3NycnlBQSIsImFsZyI6IlJTMjU2IiwieDV0IjoiaTZsR2szRlp6eFJjVWIyQzNuRVE3c3lISmxZIiwia2lkIjoiaTZsR2szRlp6eFJjVWIyQzNuRVE3c3lISmxZIn0.eyJhdWQiOiJodHRwczovL2dyYXBoLm1pY3Jvc29mdC5jb20iLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83NTYzNTY2OC03OGNlLTQzNDMtODMzYy0xOWM5ODkzNTRkZWYvIiwiaWF0IjoxNTM5NjExMjk2LCJuYmYiOjE1Mzk2MTEyOTYsImV4cCI6MTUzOTYxNTE5NiwiYWlvIjoiNDJSZ1lNaWExaldMdTJqUmkvWjlQenU4bHZkUEJRQT0iLCJhcHBfZGlzcGxheW5hbWUiOiJLRVlPMzY1IiwiYXBwaWQiOiI1MmQwMTdmZi1lY2ZjLTQ2NjgtYjZkZi0zZDNlZGYwZDFjNjIiLCJhcHBpZGFjciI6IjEiLCJpZHAiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83NTYzNTY2OC03OGNlLTQzNDMtODMzYy0xOWM5ODkzNTRkZWYvIiwib2lkIjoiMjM0ZDhmZTctNmYwZC00NmEwLWI1YmYtNzg1MWY0ZmFmNmMyIiwic3ViIjoiMjM0ZDhmZTctNmYwZC00NmEwLWI1YmYtNzg1MWY0ZmFmNmMyIiwidGlkIjoiNzU2MzU2NjgtNzhjZS00MzQzLTgzM2MtMTljOTg5MzU0ZGVmIiwidXRpIjoiUDNvc0hHdHQyMFdRTXhkLVFxcWNBQSIsInZlciI6IjEuMCIsInhtc190Y2R0IjoxNDQ3MDYyNTMyfQ.prmIaq8PzXfeovQPeIYS20xvZqpjPH-DvZNwQ3v08KOhTnfFaiCkxtw2wh1B37QQDbOveYqCWRi2CE6Uwpb6zg3-tFh1ma852HDqnJHYCKPajxeW9oIewAnCagB5FzOLQRT_EbX-lEREQVcPUHSZpRNmAWEM2MOZjDnkWun_aqohf_1op7Cy40Ol_PkRzoEgmA7pbXeI28IMPW3S4a5M_hBo_MZzRbVdxuG8YQKkVMWX0wAhpLHAYbdF1Rv5sITEpBP-KHdgJkTswLs3xvIRLyXxrXobG1aVQihr7LHFoCIU0NAcCUQLS2xkePuYGRB09k7hFQsbSNxoJSywBZWk7w
non working token for directory B:
eyJ0eXAiOiJKV1QiLCJub25jZSI6IkFRQUJBQUFBQUFDNXVuYTBFVUZnVElGOEVsYXh0V2pUUS1NMnBUdmVjYTgzUXFuVmlBWWpJX0dLNHZrMTBMYVF2dGF5SGQ0WmZDVlRySm0wSmtOVDU2UlJSU0NuUlFPU0k0aVNHdXZZZ1cxelpaTE9KTkJTVHlBQSIsImFsZyI6IlJTMjU2IiwieDV0IjoiaTZsR2szRlp6eFJjVWIyQzNuRVE3c3lISmxZIiwia2lkIjoiaTZsR2szRlp6eFJjVWIyQzNuRVE3c3lISmxZIn0.eyJhdWQiOiJodHRwczovL2dyYXBoLm1pY3Jvc29mdC5jb20iLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC84MTFjNjA2OS1kZDE4LTRmN2UtOTlhMy1lNjA2YzMyYjhhMjAvIiwiaWF0IjoxNTM5NjExMjI1LCJuYmYiOjE1Mzk2MTEyMjUsImV4cCI6MTUzOTYxNTEyNSwiYWlvIjoiNDJSZ1lPZzlraUZYR3BxNCtVMko1NHAvL2N2M0FRQT0iLCJhcHBfZGlzcGxheW5hbWUiOiJGZXRjaGluZ1VzZXJzQXBwIiwiYXBwaWQiOiJiNDAyZjI5Ni05OTAxLTRjNmMtYjA2MC1hNGI1M2VjNmMzMDQiLCJhcHBpZGFjciI6IjEiLCJpZHAiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC84MTFjNjA2OS1kZDE4LTRmN2UtOTlhMy1lNjA2YzMyYjhhMjAvIiwib2lkIjoiYzIyZWJmNmEtZDNkYS00ZGRjLWIzZTYtOWFhY2VmZWY3MmE4Iiwic3ViIjoiYzIyZWJmNmEtZDNkYS00ZGRjLWIzZTYtOWFhY2VmZWY3MmE4IiwidGlkIjoiODExYzYwNjktZGQxOC00ZjdlLTk5YTMtZTYwNmMzMmI4YTIwIiwidXRpIjoiNk4xRnBkRVZEMGFvRnM0UndVRGZBQSIsInZlciI6IjEuMCIsInhtc190Y2R0IjoxNTM5MTU0MTkxfQ.l_7qgXkco5FWR7pbX5rQzAtvnrb1e6xOr5byrvkYDcyNa85KmCu5b6ArfjxTmeDR82XTmYw51n2YAbWl2q8R58dqELOguddwnKkBBCiMwKsD_UvG2oX_M9ZMy-Lc8lERduolyST7D0BZSoYCNe9f0j85AXIOgXr_yMA5MrVz7qSVFKZ1if2BR9YvvMCphW2uQCrebEJAnchyxHiCb5refnhm2sfsDBRJqd5NWwK0-a956a6dC2zg59JbW55-3wezQOfXKYzC5ybzO7l1hV41EnJ4atBW6EvR2er7WyCAFb1Y1hSB_wgZSo7pC4LnQRRm9KXq-x2aSRKiUSg265K0RQ
You need to receive Admin Consent for an administrator of the tenant. I'm assuming that because this happens when hitting /users, you've requested either User.Read.All or User.ReadWrite.All. Both of these require Admin Consent before a normal user can authenticate and provide User Consent.
I wrote an article a while back that you might find this helpful here: User vs Admin Consent. The examples target the v2 Endpoint while it sounds like you're using v1. That said, the same consent models and workflow apply to both v1 and v2.
I've created a sample web application calling a Web API and using oAuth code grant flow against Azure AD.Application is registered in Azure AD and I have given required permission as well through Azure portal. Everything seems working as expected.
There are two option for permission
Delegate Permission
Application Permission
Is it recommended to use mix kind of permission set (App + delegate) for your application?
If I give similar kind of permission to my API on both Delegate and Application,which permission set will take precedence? Will it depend on oAuth flow e.g. Code grant or Implicit ?
In my code how can I differentiate these permission sets while accessing the same resource.I want to call on user context only even same type of application permission is already there?
Application Permissions and Delegated Permissions are completely independent of one another.
Application Permissions apply when you follow the Client Credential Flow (also known as App Only Flow). When you follow this flow, AAD will try to grant permissions to the client application based on the Application Permissions it has predefined in the app registration. These permissions will appear in an App Only Token in the role claim.
In nearly every other flow, where a user is involved (On-Behalf-Of, Authorization Code Grant Flow, Implicit Grant Flow, etc...) AAD will try to grant permissions to the client based on the Delegated Permissions it has predefined. These permissions will appear in App+User tokens in the scp (scope) claim.
You can control the kinds of permissions your app is granted by adjusting the authentication method when getting an access token to a resource.