MSgraph - Application Rights vs Delegated rights - microsoft-graph-api

I'm stuck and need advice.
I have a MSGraph functionality that uses Excel as a calculation motor.
My desktop app accesses an Excel-workbook on OneDrive, inputs some values and read out results.
I've managed to do this with Delegated Rights "Files.ReadWrite" while impersonating a user, to avoid the application asking for permission each time to execute/access the workbook.
But when moving the functionality to a .Net web application I got trouble.
.Net wouldn't allow this functionality:
"Non-interactive request to acquire a security token from the authority, via Username/Password Authentication. Available only on .net desktop and .net core."
So, I've moved the code to a REST service written in .core.
Then I got this:
StatusCode": 500,
"Message": "One or more errors occurred. (AADSTS53003: Access has been blocked by
Conditional Access policies. The access policy does not allow token issuance.
I think I could solve all this if my application had the Application Rights "Files.ReadWrite.All"?
Am I right?
Our IT department think Application Rights are too dangerous.
Is there any middleway, to have these Rights on the app, and limit the accessibility, which objects the app are allowed to access?

I think I could solve all this if my application had the Application
Rights "Files.ReadWrite.All"? Am I right?
According to your prompt message: Non-interactive request to acquire a security token from the authority, via Username/Password Authentication. Available only on .net desktop and .net core.
Obviously you cannot use delegated permissions on .Net web applications, because it is a request without user interaction (that is, no user login), so you cannot use username/password-based authentication to obtain an access token. You need to grant application permissions to the application and then use the client credential flow to obtain an access token.
But can an app with Application Rights "Files.ReadWrite.All" read all
files on all OneDrives in the organization? Is there any middleway,
to have these Rights on the app, and limit the accessibility, which
objects the app are allowed to access?
You can grant appropriate access permissions to the application according to the MS graph api you want to access. I think the Files.ReadWrite.All application permission can read all files on all OneDrive in the organization.
For delegated permissions and application permissions, the essential difference between them is whether there is a user login:
Application permissions allow an application in Azure Active Directory to act as it's own entity, rather than on behalf of a specific user.
Delegated permissions allow an application in Azure Active Directory to perform actions on behalf of a particular user.
Therefore, I think you can use application permissions with confidence.

Related

User Consent to read Outlook/Teams/Sharepoint using Microsoft Graph API

I have to read User emails (particular subfolder), One Drive, Team Channels and Sharepoint after some regular intervals at the background using Microsoft Graph API but not without having the user consent which should be taken only once when they logged in to the web based application first time and not afterwards. I am not sure where to start from and how this can be achieved? Should the token be stored forever in some database securely OR Is it the AAD?
Would really appreciate any pointers/APIs/Libraries/concepts or links which can help in moving towards this direction.
If you want to get the token without user, client credentials flow can be used. The flow permits a web service (confidential client) to use its own credentials, instead of impersonating a user, to authenticate when calling another web service.
In the client credentials flow, permissions are granted directly to the application itself by an administrator. So it is necessary to use the application permissions. You could call Microsoft Graph API with the access token.
For example, call this API to get message:
You need to add one of the application permissions to API permission(navigate to Azure Active Directory-> your application), and click grant for your tenant.

OAuth access to EWS on behalf of a user

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

Registering application in Azure portal using 'POST /applications' Graph endpoint

I am trying come up with a bash script to register an application in Azure AD using the /beta/applications endpoint from Microsoft Graph.
To call /applications, I would need to get an access token.
Is it possible to get an access token for Microsoft Graph using just email address/password (Without a client-id)? I am looking for something like "Resource Owner Password Credentials Grant Flow" mentioned in OAUTH2 spec.
Any other alternative I can look into. I want to write a simple script that would manage application registration and any updates to the application in future.
Yes, there are several means of running a script against the Microsoft Graph API without a user present:
AD supports the resource owner credential grant that you described in your question. This flow doesn't support some new auth features like multifactor auth and you'll have to be very careful about securely storing your credentials.
The other option is to use V2 auth client credential flow. In this case, the tenant admin consents to the application on behalf of the tenant. Afterwards, the application can run without a user present. One benefit of this flow as opposed to the V1 resource owner credential grant is that you pass a client credential which can be revoked and re-generated if needed (rather than dealing with raw user credentials).

Use delegated permissions on a daemon using Microsoft Graph

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.

Office 365 Oauth web api

we're currently using the office 365 api but we're a little bit stuck in the oauth process. On the target platform we have no access to a browser, which cause the main problem using the oauth procedure.
Does Microsoft offer other kinds of authentication like Limited Input Device Authentication like google does? Or are there any alternatives, when no browser is available?
Thanks a lot!
Yes, there are ways to do it without a browser, depending on your scenario. If you're looking to prompt the user yourself for username/password, you can pass those directly via ADAL. For example, here's how to do it using the ADAL for Node.js: https://github.com/AzureAD/azure-activedirectory-library-for-nodejs/blob/master/sample/username-password-sample.js
The trick when you do this is that there must be user consent already recorded in Azure AD. Because this bypasses the user consent screen, it has to be "pre-consented". One way to do this is to have the organizational administrator register the application in their own Azure AD, which by default consents for all users in the org.
Another approach would be to use the client credential flow. In this scenario, the administrator consents once for their entire organization, and the app then has access to all mailboxes in that org.

Resources