I am building an app where anybody in my organization can create planner task under a specified plan.
I am using Azure AD v2 endpoints for getting access token:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize
https://login.microsoftonline.com/common/oauth2/v2.0/token
And using that access token to make POST request to following endpoint:
https://graph.microsoft.com/v1.0/planner/tasks
I have registered my App on: https://apps.dev.microsoft.com
And given necessary delegated and application permissions EDIT: ie Group.ReadWrite.All
(along with many others)
I am(having admin rights) able to create planner tasks using the API calls but no one else in the organization can. User gets this error message:
Need admin approval
Planner Task App
Planner Task App needs permission to access resources in your organization that
only an admin can grant. Please ask an admin to grant permission to this
app before you can use it.
I know that this user account has required permissions (because when using graph explorer api calls with same account, it works) so the problem lies in App permissions.
Any help is highly appreciated.
EDIT:
Bearer token for Admin (where app successfully creates a planner task):
eyJ0eXAiOiJKV1QiLCJub25jZSI6IkFRQUJBQUFBQUFCSGg0a21TX2FLVDVYcmp6eFJBdEh6MmtUREpfbzduN3lETXJvVzhkUjR1YWZVZ050OEctbmhuNm5HalpvN1p5SDNqNEl0a3E5N3lFX091cEI2eEdITVVpcWpfeFVkdkFWdmx2SVgtV3FlSmlBQSIsImFsZyI6IlJTMjU2IiwieDV0IjoiRlNpbXVGckZOb0Mwc0pYR212MTNuTlpjZURjIiwia2lkIjoiRlNpbXVGckZOb0Mwc0pYR212MTNuTlpjZURjIn0.eyJhdWQiOiJodHRwczovL2dyYXBoLm1pY3Jvc29mdC5jb20iLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC9jZDc3NzI5NS0xN2IwLTQ0YjMtYjUxNC02YzJlMzE2ZjI5YzcvIiwiaWF0IjoxNTIzMzg5MjcwLCJuYmYiOjE1MjMzODkyNzAsImV4cCI6MTUyMzM5MzE3MCwiYWNyIjoiMSIsImFpbyI6IlkyTmdZTEQ2WUp2WDlEZlR4dTNLMUNVdTd4YWEzVkZNRnphd3NpN2NGTGplL01ianVjSUEiLCJhbXIiOlsicHdkIl0sImFwcF9kaXNwbGF5bmFtZSI6IlBsYW5uZXIgVGFzayBBcHAiLCJhcHBpZCI6IjQ4NzQ3NmM5LWM2OTctNDhhMC1hODViLWUzYjdkMTEyMTU0MyIsImFwcGlkYWNyIjoiMSIsImZhbWlseV9uYW1lIjoiUmFnaGF2IiwiZ2l2ZW5fbmFtZSI6Ik5pdGluIiwiaXBhZGRyIjoiNjcuNzEuMjI3LjE2MiIsIm5hbWUiOiJOaXRpbiBSYWdoYXYiLCJvaWQiOiJlN2JhOTVkNi1jMGIzLTQwYTEtOTU5MS0zOWYwN2YzZWZlMDUiLCJvbnByZW1fc2lkIjoiUy0xLTUtMjEtMTA2Mjg4Nzk2MS0zOTczMjgyMzc2LTE4NTU2ODk4MjEtMTQ3MSIsInBsYXRmIjoiMyIsInB1aWQiOiIxMDAzM0ZGRkE4MUEyMzBBIiwic2NwIjoiR3JvdXAuUmVhZC5BbGwgR3JvdXAuUmVhZFdyaXRlLkFsbCBNYWlsLlNlbmQgVGFza3MuUmVhZCBUYXNrcy5SZWFkLlNoYXJlZCBUYXNrcy5SZWFkV3JpdGUgVGFza3MuUmVhZFdyaXRlLlNoYXJlZCBVc2VyLlJlYWQgVXNlci5SZWFkLkFsbCIsInNpZ25pbl9zdGF0ZSI6WyJrbXNpIl0sInN1YiI6IjB6RkdKeVA5Ym8yeDdYdlNqRVNIbnkwUXZ1Ym03YTJsVXRLcHpoVEtzclEiLCJ0aWQiOiJjZDc3NzI5NS0xN2IwLTQ0YjMtYjUxNC02YzJlMzE2ZjI5YzciLCJ1bmlxdWVfbmFtZSI6Im5pdGluLnJhZ2hhdkBhbWZyZWRlcmlja3MuY29tIiwidXBuIjoibml0aW4ucmFnaGF2QGFtZnJlZGVyaWNrcy5jb20iLCJ1dGkiOiJOZlR1U2RyeFYwYVQzdlk0ckZwSkFBIiwidmVyIjoiMS4wIiwid2lkcyI6WyI2MmU5MDM5NC02OWY1LTQyMzctOTE5MC0wMTIxNzcxNDVlMTAiXX0.T50Ae8vFtdobi4GFHL4o-rqU9sbNYqhhV0KRcA7HYzUI-4M4Latma8kJ7ssqx4djdQigPnjJTCVOg9oFBXE_iSWRPbZbRGbfuvwj9iPePCtzCERZwWn0bHOltk0o0LFWW1UoplUsMJJgxoZyeMlruWBxOIQXOQxRnHlnmMLzU-Nwr2Ex87hAMnFPBN7uD9x7WIJtc3vO-sIecKLmwKgchfbI8vIXMOgs1DsVByWBljHSN-DJ9FwxklS_r-Hco9x6g5SPJ_gXfANL8KXXK51D1Xnc7TKd3IebnjermycCKw5t-ViNPlX0r-og4iKsT2oo_k1UTi5-TO2mMIKPXMjirQ
Even after Admin has given consent to the app using (https://login.microsoftonline.com/common/adminconsent?client_id=my-app-id&state=12345&redirect_uri=https://localhost/myapp), non-admin user gets this:
As you have mentioned that you are adding planner task not just reading data, you have to grant permission Group.ReadWrite.All accordingly. Please check the permission and confirm about this.
ref: https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/api/planner_post_tasks
In order to use Group.ReadWrite.All you need the consent of a tenant Admin. To obtain this you need to have an Admin on the tenant execute the Admin Consent process.
I have a walkthrough that might help you here:
v2 Endpoint & Consent (explains the various consent workflows involved)
v2 Endpoint & Admin Consent (explains how to obtain Admin Consent)
Related
I have created a microsoft chat bot, and have set up the /adminconsent workflow, where another application has given admin consent to my bot to act on behalf of them.
#shawn-tabrizi wrote a great article about how to remove my own bot's access to their application from the UI, but I can't find a way to remove access using Microsoft Graph.
Any help would be appreciated!
I believe you're looking for Delete an appRoleAssignment granted to a service principal:
App roles which are assigned to service principals are also known as application permissions. Deleting an app role assignment for a service principal is equivalent to revoking the app-only permission grant.
I have had success using OAuth 2.0 with EWS when using admin permission. Now I am trying to set it up so that an individual user can log in and grant access for himself. So I start a browser with this URL:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=f3f92d23-29dd-4465-828e-35300884ef61&redirect_uri=https%3A%2F%2Flogin.microsoftonline.com%2Fcommon%2Foauth2%2Fnativeclient&response_type=code&scope=offline_access%20Calendars.ReadWrite.All%20Contacts.ReadWrite.All%20Mail.ReadWrite.All%20Tasks.ReadWrite%20User.ReadBasic.All
The browser allows me to log in to my test account, but then this error is returned:
error=invalid client
description=AADSTS650053 The application 'my app name' asked for scope 'Calendars.ReadWrite.All' that
doesn't exist on the resource '00000003-0000-0000-c000-000000000000'
In Azure, when looking at the API permissions for my application, I have 11 Exchange permissions, including both Application and Delegated permissions for Calendars.ReadWrite.All, in addition to all of the others that I requested.
What's going on here?
Because EWS is a legacy API it doesn't implement the more restrictive permission model that the Graph and Outlook REST API uses. The only permission that will work for Delegate access is EWS.AccessAsUser.All (Scope https://outlook.office.com/EWS.AccessAsUser.All). This gives full access to every folder in a Mailbox (and any mailboxes the user has been granted access to).It looks like you application registration already includes that permission so
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=f3f92d23-29dd-4465-828e-35300884ef61&redirect_uri=https%3A%2F%2Flogin.microsoftonline.com%2Fcommon%2Foauth2%2Fnativeclient&response_type=code&scope=offline_access%20https%3A%2F%2Foutlook.office.com%2FEWS.AccessAsUser.All
should work
I am integrating my SPA web app with Microsoft 365. I have got a question regarding permissions which were granted while integrating with M365.
After successful integration and approving the permissions by admin in pop-up login window experience i would like to reach the resource to graph api to query for permissions that were granted by administrator in order to enumerate them on front end to show our user which permissions were requested and which are granted.
I know there are resources to check granted permissions but those are for example for drives, share-point user groups. I was unsuccessful in finding any kind of resources that i could reach and call Graph Api to give me all permissions granted for application itself. It is important for me to get this information because user can log in to M365 Azure Active Directory and remove one of granted permission. In such a case my app will not be notified anyhow about that change and reaching out for - lets say User's Message resource without signed in user will not be possible.
Thanks in advance for any help
You can use:
List oauth2PermissionGrants: all delegated (user) permissions granted.
List appRoleAssignments granted to a service principal: application permissions granted to other applications trough their service principals.
List oauth2PermissionGrants: delegated (user) permissions granted for a specific application trought its service principal.
2 and 3 use the beta endpoint with is subject to change and not supported in production applications.
We are developing an Office Add-in that authenticates with an organisational account to Azure AD. The Add-in needs administrative consent. So if an administrator is logged on, he should be guided to express his administrativ consent.
We are using OAuth to authenticate:
https://login.microsoftonline.com/common/oauth2/authorize?response_type=id_token&client_id=<clientId>&redirect_uri=<redirectUri>
and we request admin consent by appending &prompt=admin_consent to that URL
Question 1. How can we test if that admin consent has already been successfully given, so we only need to ask the administrator to give consent if he didn't previously?
Question 2. How can we check if an updated version of the Add-in possibly now needs more permissions and inform users and administrator about that new requirements?
tl;dr
Yes, you can do this. You'll want to call this MS Graph endpoint, and inspect the oAuth2PermissionGrant object for the consentType field being set to AllPrincipals.
Some Background
Using the Microsoft Graph, you can identify if admin consent was granted. When Admin Consent is granted, there are OAuth2.0 permission grants written on the app.
Inside each permission grant, there's a field that indicates the permission level of the grant. For Admin Consent, you would be looking for AllPrincipals.
Detailed Steps
Wire up your app to call the Microsoft Graph. Make sure it's requesting all the required permissions to call the required endpoint. This is different in the case of a delegated (on behalf of the end user) or an app role.
App Role: Directory.Read.All & Directory.ReadWrite.All
Delegated Permission: Diretory.Read.All, Directory.ReadWrite.All, or Directory.AccessAsUser.All in order of least to most privileged.
Call the GET /oAuth2PermissionGrant endpoint of MS Graph.
This returns back an oAuth2PermissionGrant object with the details you're looking for.
Inspect the response for the consentType field. You may need to enumerate all the grants looking for the value AllPrincipals.
IMHO, the custom implementation would be a better choice for your usecase
The steps could be the following
User Logs in for the 1st time
Your App / Add-in checks the consent in the internal memory / db
No Consent will be found, which will redirect the user to the consent page in Azure AD
After the user approves of his admin access, we typically get the status in the response back from Azure AD like the one below,
GET http://localhost/myapp/permissions?tenant=a8990e1f-ff32-408a-9f8e-78d3b9139b95&state=12345&admin_consent=True
The App now stores the admin consent grant status in the DB.
In case in later point of time, the app / add-in needs more permissions, just flush out the stored value for the consent and the users so that the next login takes care to ensure that they agree to the new consent. The new consent request will be sending additional scopes to the AD which will in turn be shown to the user in the consent page.
In case of reading more about the steps, please click here
Tool: postman
Created azure ad app, granted app-only permission Group.ReadWrite.All for Microsoft Graph app, the app has standard delegation permissions as "Sign-in and read user profile on" "Windows Azure Active Directory" app.
Requested token for AzureAD graph api at endpoint https://login.windows.net/ with resource parameter "https://graph.windows.net", using client credential grant flows;
Got token back
Used the token and did a GET on a User OK
Did a PATCH on a user ( modification went successfully with http code 204 back);
This looks very strange to me, why an app was able to do patch on a user in azure ad when app is only granted Group.ReadWrite.All on Microsoft Graph API?
We are working on an experience in the new Azure portal to "consent/approve" the app in your tenant. Until then, you'll need to follow the final step in the instructions that go with this sample app (to consent the app): https://github.com/Azure-Samples/active-directory-dotnet-graphapi-console.
After doing so, you should see a "roles" claim in the access token (containing Group.ReadWrite.All).
The other issue you are reporting (it looks like your app has been added to the Directory Writers role, enabling your app to be able to perform more than just group manipulation) - this will require some more investigation, as this should not be happening. Will report back.
Hope this helps,
There are two issues here;
Issue #1) Wrong documentaiton for Add Owner graph.microsoft.io/en-us/docs/api-reference/v1.0/api/… (One of the following scopes is required to execute this API: Group.ReadWrite.All or Directory.ReadWrite.All or Directory.AccessAsUser.All), It requires both Directory.ReadWrite.All AND Group.ReadWrite.All ,
Issue #2) Azure AD portal does not remove Application service principal from Directory Writer Role if you remove "Read and write directory data" permission from Windowes AzureAD App