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.
Related
I understand that for an app to access Office365 mailboxes I need a registered app with Application Permissions, e.g. Mail.Read which - according to its description - "allows the app to read mail in all mailboxes without signed-in user".
This is exactly what I need except I don't need and I am not allowed to read all mailboxes within the organisation.
In order to restrict this further I can of course set a ApplicationAccessPolicy which allows to restrict the access to a specific mailbox or generally a PolicyScopeGroupId.
My issue is that when this policy is not active, changed or deleted for whatever reason an app has full access to all of organization's mailboxes which sounds very risky in a bigger enterprise.
Isn't there really any other way to handle that vice versa, so that by default no mailbox can be accessed except a set of defined ones?
The other way around can be,There is a separate Mail.Read permission for both Application and Delegated permissions.
The difference between "App-only vs. delegated permissions"
Permission scopes can be either app-only or delegated. App-only scopes (also known as app roles) grant the app the full set of privileges offered by the scope. App-only scopes are typically used by apps that run as a service without a signed-in user being present.
Delegated permission scopes are for apps that act on behalf of a user. These scopes delegate the privileges of the signed-in user, allowing the app to act as the user. The actual privileges granted to the app will be the least privileged combination (the intersection) of the privileges granted by the scope and those possessed by the signed-in user. For example, if the permission scope grants delegated privileges to write all directory objects, but the signed-in user has privileges only to update their own user profile, the app will only be able to write the signed-in user's profile but no other objects.
"Permissions not requiring administrator's consent" are delegated permissions, while "App-only permissions requiring administrator's consent" are the app-only permissions, which is why it shows up twice.
If you want to access the mail for all the user's in your tenant, then you must have a user account that has that level of access or you need to use an App Only token which grants that scope of access.
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 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)
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