I'm developing a background application (no user interaction will be possible) and I want to automate getting all emails from certain mail boxes using the Graph API. I am facing some issues though:
If I use application permissions I get access to every mailbox in the organization which is not a good solution. Is it possible to limit the access to certain mailboxes? We are using On-premise Exchange and not Exchange Online so this link is not relevant (https://learn.microsoft.com/en-us/graph/auth-limit-mailbox-access).
It I use delegated permissions the app will need user interaction (as far as I can tell) but that will not be possible as it should run in the background. I am looking at the different flows for authentication but none of them really fit my need. Maybe it can be done with the Refresh Token Flow but it seems vulnerable. Is it possible to use delegated permissions without user interaction? If yes, what is the best approach?
Best regards
J
First, you couldn't use delegated permissions without user. Delegated permissions are used by apps that have a signed-in user present.
It seems Resource Owner Password Credentials(ropc) flow which allows an application to sign in the user by directly handling their password is the best choice for you. But it carries risks, please see the Important in the article to make sure you can use it. You should only use this flow when other more secure flows can't be used.
POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded
client_id=<client_id>
&scope=user.read%20openid%20profile%20offline_access
&username=MyUsername#myTenant.onmicrosoft.com
&password=<password>
&grant_type=password
Related
Ive been researching the MS Graph API lately, and I'm running into a problem. My use case is that I want to read a certain mailbox's mail, and send mail for that mailbox. The mailbox is a non user related box, and is used as a service account for emails.
Ive found 2 possible flows for getting into that mailbox. The user authenticated flow, and the application (and admin consented) flow. For the application, I want to read the emails in the background in a NodeJS app, without user interaction.
When I look into the user consented flow, I find that to make it work the user HAS to log in atleast once, by hand, and consent to some stuff I want to do. I found this page, on how this works, and made it work in my NodeJS app. The problem is, when using this flow, I have to login BY HAND atleast once after starting my NodeJS app. Afterwards I can use the refresh token to refresh the access token, but I dont want to do the login by hand.
The second option, and most suitable option for my NodeJS app, is the application flow. I found this tutorial on how to do that, and I made it all work. I fetch a token, and that token grants me access to the box via the Graph API.
But using the application flow, I found that I have to have the roles (i.e.): "User.ReadAll, Mail.Read, Mail.Send". This gives my application rights to read and send mail FOR ALL users in the account.. Which is WAY too much overkill for my situation.
Now my question; Is there a way for me to use MS Graph, with the application authentication flow, but without having access to all users' mailboxes, only to my specific account I want to read?
Thanks in advance,
Caspar
While linking the documentation reference, I saw that I read over the most important footnote:
Important Administrators can configure application access policy to limit app access to specific mailboxes and not to all the mailboxes in the organization, even if the app has been granted the application permissions of Mail.Read, Mail.ReadWrite, Mail.Send, MailboxSettings.Read, or MailboxSettings.ReadWrite.
So it is possible using the application access policies.
We are about to use Dynamics 365 CRM online and we are new in this area.
...User is logged in using SSO.
Now to my questions...
Alternative 1
Our solution architect want us to use a LogicApp, triggered by create/update on the contact entity, to pick up the loggedin users user access token and send it as Authorization header with the call to our onprem rest service.
As far as I can see this is not possible as the LogicApp is running in its own process (kind of as a windows service). Am I wrong?
We have been looking into other different options instead;
Alternative 2
We have been looking at using a Plugin but fails to get hold of the user access token. It is possible, though, to get hold of the application access token but that is not good enough for my client. Is it even possible? If possible, does anyone have an example of how it is done?
Alternative 3
We have been looking at using Javascript to trigger a LogicApp using HTTP request but fails on CORS. Would the user access token magically be sent with the call? Is it even possible? If possible, does anyone have an example of how it is done?
Alternative 4
We have been looking at using JavaScript but fails to get hold of the user access token. Is it even possible to do? If possible, does anyone have an example of how it is done?
We know how to get the user access token in a console application after logging in with SSO. And we know how to get the user access token in an ASPNET MVC application. But now... this is Dynamics 365 CRM online.
We need the user access token because we want the user information to be sent to API.
Are there any other options? We have been looking into this for a week or so...
In case there is anyone else that is looking into picking up the users access token from D365 online to send it along with calls to an onprem rest service I can now confirm that it is not possible (at least not for the moment).
Also, I have found out that what my customer really want to do is a mix of authentication/authorization and tracing.
Could you give a try by including powerapp which will call onpremAPI
I am trying to create workflow using Microsoft Flow. Some of my steps are executing HTTP Requests using Microsoft Graph API. Problem I am encountering is that some API do not support Application Permission type, but rather Delegated. I am attempting to Create plan in Microsoft Planner (see this link). In this scenario I have created service account that will execute specific workflow and on the Azure AD application side I have granted permissions on behalf of user as administrator.
Because I have to execute certain HTTP Requests as "user" I am attempting to retrieve user authorization token there are two steps here:
Retrieve Authorization code
Retrieve Token based on authorization code
I cannot pass Step 1. I am following this documentation: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow and every time I attempt to execute following HTTP request:
GET https://login.microsoftonline.com/{my-tenant-id}/oauth2/v2.0/authorize?
client_id={my-client-id}
&response_type=code
&redirect_uri=https%3A%2F%2Flogin.microsoftonline.com%2Fcommon%2Foauth2%2Fnativeclient
&response_mode=query
&scope=Group.ReadWrite.All
I am using basic authentication by passing username and password. But I am getting response that "We can't sign you in, your browser is currently set to block cookies". Well there is no browser it is service account. Am I missing something or what I am trying to achieve is not possible and I have to have web application? Microsoft made connectors that use Planner API, but they made everything but connector to make plan in planner...
EDIT:
I am aware that issue is similar to this topic here, but answer in this topic says to use "App authorization" which is specifically pointed out by Microsoft in their documentation that in this scenario you cannot. I am aware of that I need actual user permissions as only type of permission allowed is
Delegated (work or school account)
this is why particular topic does not answer my question since that answer is pointing out to Application permission that is not supported in this scenario.
I think you're running into an issue because Authorization code grant flow is meant to work with user interaction, i.e. user gets redirected to login page to enter credentials interactively. You can read more about it in this related SO Post OAuth2 - Authorize with no user interaction (it's not specific to Azure AD but about OAuth 2.0 Authorization Code Grant flow in general.
Alternatives
Client Credentials Grant Flow
This would have been ideal and the best choice for any background/daemon process, but it will work with application permissions. Unfortunately the API you're trying to use only works with Delegated permissions as you have mentioned, so this grant won't work.
Resource Owner Password Grant Flow (this could work but violates security best practices and has functional issues)
ROPC works directly with user credentials (i.e. your code has direct access to username as well as password, which isn't a good practice by any means), and it doesn't require explicit interaction. Even though this could work out, please know that this grant violates many security best practices and it has functional limitations too (like doesn't work with Multi Factor Authentication, or with Personal accounts).
See this related SO Post where I have covered these in a little more detail. Normally I would refrain from mentioning this grant, but I don't see any other grant working in your case and that's the only reason to include it.
Sample request
// Line breaks and spaces are for legibility only.
POST {tenant}/oauth2/v2.0/token
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&scope=user.read%20openid%20profile%20offline_access
&username=MyUsername#myTenant.com
&password=SuperS3cret
&grant_type=password
Using Refresh Token (could work but it's also fragile and more like a workaround)
In this approach you could acquire a refresh token using service account first. You will need to do this separate from general working of the application, say as part of initial setup and with user interaction.
Then going ahead you can acquire token based on this refresh token. Refresh tokens can get revoked or expire. So you need to be aware of how long is refresh token valid for and events where it could become invalid. An event like password change could also make existing refresh token invalid. Also, you will need to secure the refresh tokens like a sensitive information (almost like a password itself)
So AFAIK, I'm only suggesting a couple of bad options, i.e. 2 and 3. Unfortunately API not supporting Application permissions takes out the good option.
I am creating this post after doing quite a lot of research on OpenID Connect myself including reading the specs and the more I read the more questions come up. I hope that someone is able to help me and clear my confusion.
The OpenID Connect specs are good but only contain very basic examples that do not match my usecase. Please let me try to explain my situation and then ask my question:
I try to use OIDC in conjuction with SharePoint Online and two applications. One is a webservice (back-end) that is supposed to interact with SharePoint and the other one is a simple single page application (front-end) running in the browser of the user that allows him to interact with the webservice. My IdentityProvider is Active Directory. The task of the webservice is to do some actions in user context on SharePoint but it is also supposed to allow the user to execute a limited set of actions that only an administrator of SharePoint would be allowed to do (e.g. I want to allow the user to create a SiteCollection but not delete it) For that reason I managed to register the webservice with SharePoint so that it receives a Special access_token which grants it admin access in SharePoint.
My thoughts so far:
1) If the user logs into SharePoint he receives an id_token and an access_token from the AD. He can use the id_token to log to SharePoint and interact with it directly. (I got this working)
2) I also want to authenticate the user in the front-end single page application because some users should not be able to make certain calls to the webservice and I want to hide these buttons from them in my application. For that I could use the id_token from step 1).
3) If my webservice should do something in the context of a user I can just pass the access_token that was created for that given user in step 1) to the webservice and then forward it to SharePoint.
4) If my webservice should execute a privileged function that the user is not allowed to do on his own, I want to use the Special access_token that the webservice already pocesses to make the call. In that case I have to authenticate the user at my webservice with his id_token from step 1) to make sure that I want to allow this request of his.
My question:
Does every client have to make a request for his own id/access_token? (These different flows are described in the OIDC and OAuth specs here and here) and will this still be Single-Sign-On?
Or can I just generate a single id_token and access_token for a user in step 1) and then pass these on to all clients that need them?
Thank you very much in advance!!
I want to create a envelope on DocuSign by integrating my application.
I know about the SOBO concept but due to some limitation, can't create a generic account.
So what i am asking here "Is it possible that with, only sender username + certified integration key info, the application can make an API call to create envelopes?"
One more thing, DocuSign production SSO is enabled for all the users I want. So is there a way that I can get any help from SSO?
Any help around this is greatly appreciated.
Yes, you can use the new DocuSign OAuth support to enable your app's users to authorize your app to make API calls on their behalf.
DocuSign OAuth docs
Some notes about this:
Each of your users will need to authorize your app to make API calls on their behalf.
There are different ways to set up the OAuth capability depending on whether your app is a local/mobile app or a server-based app. The latter can protect its client secret, the former can't. Both are supported. See the docs for more info.
The new OAuth capability is not yet available for a "system account" that autonomously makes API calls on its own behalf (this doesn't apply to your question.)
Also, you say there is "some limitation" preventing you from setting up a generic (system) account to use the API on behalf of the account holders (this is the SOBO use case). I suggest that you push a little on the "limitation." Trying to get 10 or 10,000 individuals to separately authorize an app to act on their behalf is not easy. The goal of SOBO is to make it easy for authorized system apps to send on behalf of others.