I'm trying to use the Microsoft Graph API through the OAUTH2 Authentication however I'm struggling to work out how to use Delegated Permissions and not require a user to login.
I'm happy to authenticate the app with myself once, but this will be running on a daemon/service and won't be interacted with via a user. Because of this I can't use the way Microsoft describes Delegated Permissions as that uses /authorize first and then a call can be made to /token.
I know you can use secret keys for /token but it seems that only is using the Application Permissions and not Delegated - which is what I have access to.
Is there a way to authenticate using Delegated Permissions as if I was a user but without a user having to use a sign in page every time?
I needed to do something similar in a daemon app, but application permissions weren't available for the resource to which I needed access (Planner). I was able to accomplish it using the Resource Owner Password Credentials flow and supplying credentials for a service account instead of an actual user.
https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth-ropc
This isn't possible. The term "delegated" is very intentional here in that it means "the user has delegated their permissions to your application so you can operate on behalf of that user". Application permissions are not delegated because there is no user in context to delegate their access rights to you.
Authorization Code = Delegated Permission Scopes
Implicit Grants == Delegated Permission Scopes
Client Credential Grants == Delegated Permission Scopes
Much of the Microsoft Graph functionality works with both Application and Delegated scopes so in many cases you can still execute the same scenarios. There are some caveats such as using the shorthand /me which doesn't exist when there isn't a user authenticated (instead you need to use /users[{id}]). There are however some cases where there isn't an equivalent Application scope and these are regularly looked at in an effort to close the gap.
Related
My question is, does Microsoft Graph work without User.Read scope ? I am not able to request the email profile openid permissions directly.
It throws AccessDenied error. So is User.Read pre requisite for email profile or openid ?
User.Read is just the delegated permission for getting the user profile using MS Graph Get User. If your app does not need to read the user profile you don't need this permission but in most cases you do because you app is acting on behalf of the user.
Does Microsoft Graph work without User.Read scope ?
No, but in most cases, you need the scope to read user profile and call /me endpoints.
You should check the api document to see if calling that api required User.Read permission.
For instance: I wanna call this api to list emails, and we can see that this api provides 2 kinds of permissions, one is for delegate, another is for application(this means client credential flow is supported). All the api permissions are listed here and we need to go to azure ad portal to add the api permission to your azure ad application which used to generate access token.
After generating the access token, you can user jwt decode tool to check if your access token contains correct scopes(for delegate permission) or roles(for application permission). Using a correct token to call the api will not lead to AccessDenied error. By the way, newly added permission may be deferrable to take effect.
Would it be possible for a background service to use identity of specific shared mail box user in conjunction with the delegated access permissions without actually requiring an end user to authenticate ?
How would this be achieved in office365 exchange services with OAUTH 2.0 ?
Regards
Would it be possible for a background service to use identity of specific shared mail box user in conjunction with the delegated access permissions without actually requiring an end user to authenticate ?
If you use the client credentials flow https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow so you service is then getting an Access token using a SSL certificate of client secret. It can then impersonate (so it not delegate access) any Mailbox in your tenant and send as that user.
If your on Office365 then you may want to look at the Graph API instead that allows you to have a much tighter set of permissions (eg you could for instance just grant your app/service SendAs rights) when compared to EWS which only allows full Mailbox access.
I am building an app which authenticates via microsoft and needs various that predominantly uses Delegated permissions. I use the v2 auth endpoints to do incremental authentication, only asking for additional scopes when the user needs them.
This has worked well for the many delegated permissions I have so far. In many cases I need admin approval for these permissions, but I have a flow for that which works well.
One of the scopes I have used as a delegated permission is "User.Read.All", I now need the same scope on the application permission level. But I am struggling to work out if there is a way to do incremental authentication for application permissions. The docs say to use the generic endpoint where you don't specify scopes, but this then asks for all the scopes I have on my application registration rather than just passing in the scopes as a param.
It has nothing do with the endpoint and the scopes you specified. Since you use Delegated permissions in your original job, so I consider you use auth code flow or username/passord flow. If we use auth code flow or username/password flow, we can't get application permission when we do authentication although you have assign the application permissions to your registered app. If you want to get application permission when do authentication, you need to use client credential flow instead.
It is not possible to do this unfortunately the consent flow allows either a dynamic set of delegated scopes to be submitted or /.default which acts like the v1 endpoints and requests all scopes for that client. See these docs
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 have a JavaScript app that requires a user to login and hit a button then it runs a report, posts data to Excel, and sends an email. I want to automate this so a user does not have to log in and push a button.
I started with this project code: https://github.com/microsoftgraph/nodejs-apponlytoken-rest-sample
I followed the instructions and am able to get an access token but then my api call fails with 401 unauthorized. As a test, I am trying to send an email as myself and I have the Application type Mail.Send permission granted by the company admin.
I have spent many hours reading docs and blogs but have not found a solution. This document summarizes best what I am troubleshooting: https://blogs.technet.microsoft.com/sharepointdevelopersupport/2018/03/15/troubleshooting-assistance-with-microsoft-graph-api-development/.
The token I get back does not have any Roles in it as seen when I decode it with JWT. This is the only discrepancy I have found so far.
Any advise would be greatly appreciated. How can I ensure that my token has Roles defined or what else can I try? How is it that I can get a token successfully but can't use it for anything?
Thank you!
I am not a Node expert, so helping you out with a few pointers that might help.
Microsoft Graph has two types of permissions, Delegated and Application. So some things to know of and check..
Delegated permissions require a user to be present, they would show up in the scp claim in the access token. These are obtained by web applications using the implicit_grant flow, Authorization code grant or on-behalf-of flow (usually).
Application Permissions, require an admin to consent and will be provided to you in the roles claim in the access token. This requires, the app to obtain an access token via the client credentials grant. Note that, these are also present when the user is assigned a role as explained in this sample, but this scenario might not be applicable for in your case.
Does you app has the grant provided as you expect? You can check these via the Graph Explorer using the following two rest calls. There would be a OAuth2PermissionGrant entry with the expected role in it.
https://graph.microsoft.com/beta/OAuth2PermissionGrants
https://graph.microsoft.com/beta/kalyankrishna.net/OAuth2PermissionGrants
It'd help more if you can explain the flow that you have been using to obtain the access token. For example, the implicit_grant_flow does not work with application permissions.
In my case, the problem had to do with the endpoint and my tenant. I had been using the common tenant make api calls for tokens because that is what was listed in AzureAD for my app. I found that for the Application client permissions I must use my specific tenant id like 'https://login.microsoftonline.com/tenant_id/oauth2/token' when getting tokens with the proper roles.