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.
Related
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
I read a lot about OAuth 2.0 and OpenId Connect and in theory I understand both concepts now.
But if I go into practice, some things are still confusing for me and I hope you can enlighten me in some way...
First thing is, that in all code samples how to secure a .net core API in an AAD-environment I find lines like this in the configure-section:
app.UseAuthentication()
and lines like this in the ConfigureServices section:
services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
.AddJwtBearer(options =>
{
options.Authority = "https://login.microsoftonline.com/xxxxxxxx";
options.Audience = "xxxx-xxx-xxx-xxx-xxxx";
});
However, to access my API I am not using an ID token, but an access token what is Authorization, not "Authentication" like in the code samples.
This works - but I do not understand it 100%.
So my first question is:
Is the access token also "authenticating" in some way?
The second thing:
I read that access tokens have no standardized format. They can be JWT or not, can have an audience or not etc. For this reason you could even put user information in the token like microsoft does. The access tokens contain claims like a "family name" or "given name" etc.
Id tokens in contrast have a standardized format to ensure that authentication is done in the same way by everyone.
If people are accessing my apis with an access token, I can read their name or e-mail address with "user.identity.name" for example. This value I can use to store the information who edited something or who inserted something.
So I am fetching information about the user with access tokens!
So my second question is:
Am I doing the right thing here? Or should this be done in another way.
and:
Should access tokens ever contain information about the user?
Is the access token also "authenticating" in some way?
Yes.
Your API is validating the access token when it receives it.
This is the authentication part, when your API verifies that the token signature is valid, came from the Azure AD tenant that you trust, that it is meant for your API and that it has not expired.
The authorization is when you check what permissions the token contains.
Your API can define different permissions that are given to client applications, allowing them different levels of access.
A valid token can pass authentication, but it might not pass authorization if it lacks the necessary permissions.
Am I doing the right thing here? Or should this be done in another way.
Fundamentally your are doing the correct thing.
The token tells you who the user is that is using the client application, and if you need to know who it was who did something, that's the info you use.
However, if you really want to connect an action to a user, I suggest you use their object identifier / object id / oid instead of their name / username as those can change.
Unless you just want their display name.
Should access tokens ever contain information about the user?
In the context of Azure AD, an access token will always contain info about the user if a client application is accessing an API on behalf of a user.
This includes authentication flows like authorization code, device code, implicit, and on-behalf-of.
They all use delegated permissions aka scopes to call APIs on behalf of the user.
Thus the token contains info about the calling app and the user.
If an app acquires an access token using the client credentials flow where a user is not involved, there will be no user info in the token.
In this case, application permissions are used instead of delegated permissions in Azure AD.
An application acts as itself, not on behalf of any user.
If your API supports both of these scenarios, sometimes the tokens contain user info and sometimes not.
The part about token formats is basically correct from a specification standpoint.
OAuth doesn't define a strict format for access tokens, while OpenID Connect does define one for ID tokens.
Using an access token to call your API is definitely correct.
The ID token is only meant for the app that initiated the user authentication, not for any APIs that it calls.
That's what access tokens are for.
if you check here: https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens
in the newer access tokens, by default it follows the standard of not having any personal information about the user. which is what the standards suggest, Access tokens should not contain much or any information About the user. rather just information for authorization (things that user can access).
However you can always add the optional claims (and azure lets you do it) for personal info, but best practice suggests you shouldn't.
in terms of the addauthentication: Authentication is basically proving who you say you are. addauthentication(), basically calls microsoft azure ad to perform this task, saying hey aad please ask this person who he is, azure then checks and says ya this is a real person, but i won't tell you anything about him other than an id, and they have access to your api/application. So from your snippit, it's fine.
at this point, your serverside shouldn't have any personal information about the user, just that they have access and what scopes/roles. If it wants info about the user, it should then take that authorization (access token) and request it from whatever endpoint that token has access to (graph)
here's a great read about it: https://auth0.com/blog/why-should-use-accesstokens-to-secure-an-api/
Hopefully this helped clarify somewhat, and not add more confusion to the issue.
One of the steps to authorize our application to access our DocuSign account requires a human to navigate to the oauth service (https://account-d.docusign.com/oauth/auth?response_type=code&scope=signature%20impersonation&client_id=...) then login to the account, and grant it access.
I've seen some references throughout the developer portal about this being something that will need done multiple times, and I've also seen it written on the same site that it only needs to be done once (the site is actually fraught with contradicting information).
Does anyone know if this step will need to be done more than once? It makes sense to me that it should NOT.
Much appreciated!
Chris
You are referring to https://docs.docusign.com/esign/guide/authentication/oa2_auth_code.html and it is a correct place for documentation for DocuSign. Now with above flow, you get two types of tokens i.e AccessToken and Refresh Token. If Access Token expires then you can use refresh token to get new set of access and refresh token and it does not need any consent from the user or a human action, it can be done using DocuSign OAUTH API from backend. But if the response to the refresh operation is an error, or if the new access token’s expires_in value is less than your threshold, you will need to repeat the initial authentication flow. So you need to do proper exception/error handling before taking user back to the consent/OAuth login page.
I would like to upload a given file to Sharepoint. I'm using the Microsoft Graph API.
The documentation follows this workflow:
1. If no token, redirect the user to the Microsoft signin page.
2. The user is then redirected to the application, with an access token
3. Use access token to have an authorization bearer
4. Do what you gotta do...
My problem is the sign-in part. I don't want my users to be redirected to the Microsoft signin page. I want my application to connect and get the access token in the background (with cURL or whatever).
How can I do that? Why is the "open in browser" necessary?
I tried to replicate the sign-in process, but all I get back is the HTML response from the signin page.
Thanks in advance.
Your application act as a single-tenant service or daemon app.
The documentation about this scenario is here : https://developer.microsoft.com/en-us/graph/docs/authorization/app_only
The application must be registered in the AzureAD directory corresponding to the Office365 tenant
A first request is made by passing the application unique identifier and secret key as registered in the directory. This request returns an access token
The access token can now be used in the Authorization header of the following request to the Microsoft Graph API.
This method (of using Client ID and Secret) works well but there are other ways which may be better suited for similar scenarios.
The one major thing which is missing in access token generated this way is a user, meaning the token only contains the identity of the OAuth application (client) which called it but is not associated with any user for the request.
This could have a couple of implications:
Since the token is not associated with a specific user you will not know who performed the operation. In your example, you would not know who uploaded the file (and other similar information may be missing).
Access token without users will not work at all for some methods. For those, you need a delegated token.
Creating a delegated token requires some effort, if you are interested you can find the details in my article:
Getting Access Token for Microsoft Graph Using OAuth REST API
I don't need Microsoft Login screen.
If I am already having username and password with me ,
can't I just pass them using Http client and get the authentication token.
Is it possible , please suggest.
The Azure AD supports various flow about OAuth 2.0. To acquire the access token with username and password directly, we can interact with resource owner password credential flow. However this scenario should be used carefully since it may leak the password. You can refer this flow about specification from rfc6749#page-37.
And to implement this flow using C#, you can refer this blog.
The short answer is, it is possible but not recommended (See comments from Philippe below).
The ability to get a token when you have a user name and password is extremely limited.
You might be able to do this in rare scenarios when your device is not able to prompt the AAD Auth page, or in cases when it is a native app/automation tests and etc.
Please see this post for the limitations and workarounds:
http://www.cloudidentity.com/blog/2014/07/08/using-adal-net-to-authenticate-users-via-usernamepassword/
Also look at this answer from me here, where I made it to work for our automation tests, but Vibronet has comments that, this solution will stop working, but not sure it has happened yet or not.
How to acquire a user based token from Azure Graph API