I'm trying to get an application using EWS to work against O365 with OAuth. I've managed to get it working in the case where I register the app in AAD, and grant it full_access_as_app (Use Exchange Web Services with full access to all mailboxes) in the portal. The code looks like this:
string tokenUri = "https://login.microsoftonline.com/TENANTID/oauth2/v2.0/token";
string resource = "https://outlook.office365.com";
string appId = "APPID_FROM_AAD";
var context = new AuthenticationContext(tokenUri);
X509Certificate2 cert = GetLocalCertificate(THUMBPRINT);
ClientAssertionCertificate c = new ClientAssertionCertificate(appId, cert);
AuthenticationResult authenticationResult = context.AcquireTokenAsync(resource, c).ConfigureAwait(false).GetAwaiter().GetResult();
m_exchangeService.Credentials = new OAuthCredentials(authenticationResult.AccessToken);
//all the autodiscover URIs for O365 are the same
m_exchangeService.Url = new Uri(#"https://outlook.office365.com/EWS/Exchange.asmx");
m_exchangeService.ImpersonatedUserId = new ImpersonatedUserId(ConnectingIdType.SmtpAddress, m_emailAddress);
This seemed a little extreme though. The application is a back end service, and only needs access to one mailbox (the impersonated user id), so I wanted to change it over to full_access_as_user permissions (Access mailboxes as the signed-in user via Exchange Web Services). I added the permission to the app, and then added the application to the user, but I got a 401 anytime I tried to operate on the mailbox after impersonation. I checked the JWT, and while with the original permission I had "full_access_as_app" in the roles, I didn't have any roles assigned this time.
Is there a way I can modify this so that I can have an admin add EWS access to one or more mailboxes in a tenant, or is the only way to get this to work to give an app access to every mailbox on the service?
Yes, OAuth authentication for EWS is only available in Exchange as part of Office 365. EWS applications require the "Full access to user's mailbox" permission.
Reference - Authenticate an EWS application by using OAuth
Related
Regarding adding external Gmail users to the Azure Active Directory Group, I have invited a Gmail user from the azure portal and the Gmail user has granted the consent to access the Application registered in Azure Enterprise Application.
When the Gmail user tried to Sign In into my Single Sign-On page, Azure validation is throwing the exception, when I am trying to acquire token by AcquireTokenAsync() Method
accessing_ws_metadata_exchange_failed
Response status code does not indicate success: 406 (NotAcceptable).
Below is my C# code to validate the users against Azure Active Directory.
var authority = string.Format(CultureInfo.InvariantCulture, "https://login.windows.net/{0}", tenantId);
var authenticationcontext = new AuthenticationContext(authority);
var upc = new UserPasswordCredential(username, password); //gmailusername and password
authenticationResult = authenticationcontext.AcquireTokenAsync("https://graph.windows.net", clientId, upc).Result;
The login flow you are using doesn't really work well with federated users (like these Guests).
Resource Owner Password Credentials (ROPC) grant flow that you are using here is only really meant to be a legacy upgrade path and isn't really modern authentication.
By the way, that login flow also does not support users with Multi-Factor Authentication or an expired password.
You could use Authorization code flow to login(back-end web app/native app).
In the case of a back-end Web app,
authorization code flow works by you redirecting the user to login,
getting a code back which you exchange for tokens.
In native apps it can be used by showing a pop-up of the login page to the user.
It can be used through different overloads of AcquireTokenAsync().
I am creating a console application that connects to Microsoft Graph using the Microsoft Graph API (as shown in https://github.com/microsoftgraph/console-csharp-connect-sample).
Everything is working fine, but I wonder if there is a way where I can authenticate a user (when I already know their user/password) without them needing to manually enter their credentials on the "Sing in to your account" window rendered on the desktop.
The idea is basically to run the application unattended, so there is no need for the user to be entering their credentials when the application starts. I can´t find any relevant information on the subject.
Is that even possible?
EDIT
After following the link #DanSilver posted about geting access without a user, I tried the sample suggested in that link (https://github.com/Azure-Samples/active-directory-dotnet-daemon-v2). Although that is an MVC application that forces users to authenticate (precisely what I wanted to avoid) I have managed to use part of the authentication code in that sample with my console application. After giving authorization to the application manually through a request to https://login.microsoftonline.com/myTenantId/adminconsent I can create a GraphServiceClient in my console app that connects to Graph without user interaction. So I mark the answer as valid.
Just in case someone is in the same situation, the GraphServiceclient is created as:
GraphServiceClient graphServiceClientApplication = new GraphServiceClient("https://graph.microsoft.com/v1.0", new DelegateAuthenticationProvider(
async (requestMessage) =>
{
string clientId = "yourClientApplicationId";
string authorityFormat = "https://login.microsoftonline.com/{0}/v2.0";
string tenantId = "yourTenantId";
string msGraphScope = "https://graph.microsoft.com/.default";
string redirectUri = "msalXXXXXX://auth"; // Custom Redirect URI asigned in the Application Registration Portal in the native Application Platform
string clientSecret = "passwordGenerated";
ConfidentialClientApplication daemonClient = new ConfidentialClientApplication(clientId, String.Format(authorityFormat, tenantId), redirectUri, new ClientCredential(clientSecret), null, new TokenCache());
AuthenticationResult authResult = await daemonClient.AcquireTokenForClientAsync(new string[] { msGraphScope });
string token = authResult.AccessToken;
requestMessage.Headers.Authorization = new AuthenticationHeaderValue("bearer", token);
}
));
One idea is using the "app only" authorization flow. The idea is that you can have long running apps access the Microsoft Graph without user authentication. The main difference is instead of the access token granting access to a particular user, it grants your app access to resources that you've consented to in advance. There will be no user login dialog and you can programmatically fetch access tokens to call the Graph API.
To reiterate that these tokens aren't for a particular user, consider making a GET request to 'https://graph.microsoft.com/v1.0/me'. This will return an error since the access token isn't for a particular user and "me" doesn't mean anything. Requests should be sent with full user ids "like graph.microsoft.com/users/someuser#contosos.com".
More information on this can be found at the Get access without a user documentation page.
Another idea is to let the user authenticate the first time they use your app and then store a refresh token. These tokens live longer (a few months IIRC) and then you won't need to prompt for user consent each time the app runs. Refresh tokens can be exchanged for access tokens that live 60 minutes and those can be used to call Graph API on behalf of users.
More info on refresh tokens: https://developer.microsoft.com/en-us/graph/docs/concepts/auth_v2_user#5-use-the-refresh-token-to-get-a-new-access-token
I did want to come back out here and share, since I ran into this problem yesterday, and the idea of granting read/write mailbox access for my application... to EVERYONE'S EMAIL BOX IN THE ENTIRE ORGANIZATION... was way over the top for my needs. (And that is exactly what happens when you start talking about granting Application level permissions instead of delegated permissions to your registered app).
It's a simple use case: I had a nightly process that needed to automate sending of emails from a shared mailbox using a traditional AD service account.
Thankfully... even though they are on the march to eliminate passwords (lol)... someone at Microsoft still recognizes my use case, and it's lack of apples-to-apples alternatives in Azure AD. There is still an extension method we can lean on to get the job done:
private AuthenticationContext authContext = null;
authContext = new AuthenticationContext("https://login.microsoftonline.com/ourmail.onmicrosoft.com",
new TokenCache());
result = authContext.AcquireTokenAsync("https://graph.microsoft.com/",
"12345678-1234-1234-1234-1234567890",
new UserPasswordCredential(
Environment.GetEnvironmentVariable("UID", EnvironmentVariableTarget.User),
Environment.GetEnvironmentVariable("UPD", EnvironmentVariableTarget.User)
)).Result;
You can replace those GetEnvironmentVariable calls with your Username (UID) and Password (UPD). I just stuff them in the environment variables of the service account so I didn't have to check anything into source control.
AcquireTokenAsync is an extension method made available from the Microsoft.IdentityModel.Clients.ActiveDirectory namespace. From there, it's a simple business to fire up a GraphClient.
string sToken = result.AccessToken;
Microsoft.Graph.GraphServiceClient oGraphClient = new GraphServiceClient(
new DelegateAuthenticationProvider((requestMessage) => {
requestMessage
.Headers
.Authorization = new AuthenticationHeaderValue("bearer", sToken);
return Task.FromResult(0);
}));
The last bit of magic was to add these permissions to Application registration I created in Azure AD (where that GUID came from). The application has be defined as a Public client (there's a radio button for that towards the bottom of the authentication tab). I added the following 5 DELEGATED permissions (NOT application permissions):
Microsoft Graph
1. Mail.ReadWrite.Shared
2. Mail.Send.Shared
3. User.Read
4. email
5. openid
Since user consents are actually blocked in our organization, another permissions admin had to review my application definition and then do an admin level grant of those rights, but once he did, everything lit up and worked like I needed: limited access by a service account to a single shared mailbox, with the actual security of that access being managed in Office 365 and not Azure AD.
I trying to read user data from their Microsoft live account. I have written code as below:
public void GetUserData(){
var authContext = new AuthenticationContext("https://login.microsoftonline.com/common/");
var result = _authenticationContext
.AcquireTokenAsync("https://graph.microsoft.com", "<my client/app ID>", "<redirect URI>", new PlatformParameters(PromptBehavior.RefreshSession))
.Result;
var accessToken = result.AccessToken;
var httpClient = new HttpClient();
httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer",accessToken);
var userResponse = httpClient.GetStringAsync("https://graph.microsoft.com/beta/me/").Result;
//DO SOMTHING WITH DATA
}
my code is working fine when I used my AAD credentials, but when I used my personal account it is giving the following error.
AADSTS50020: User account 'XXXX#outlook.com' from identity provider
'live.com' does not exist in tenant 'Default Directory' and cannot
access the application 'XXXXXXXXXXXXXXXXX' in that
tenant. The account needs to be added as an external user in the
tenant first. Sign out and sign in again with a different Azure Active
Directory user account.
Here is the screenshot:
It's similar to this question. could someone help me out?
v1 endpoints require that the user is a member in a directory.
You should probably use the v2.0 endpoints for this: https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-appmodel-v2-overview
If you expect only consumer MS accounts to login, you can specify the authorize URL as:
https://login.microsoftonline.com/consumers/oauth2/v2.0/authorize
First, for the error massage in your question, you need to add the live account into your directory first and then try to use Azure AD v2 endpoint to authenticate. You can not sign in the app with the external account which was not in that directory.
I assume that you want any Microsoft live account can use your app.
Based on this requirement, I suggest you can use Azure AD B2C to achieve this. Azure AD B2C can enables your application to authenticate with any Microsoft account. You can add Microsoft Account as a social identity providers. So that any live accounts can sign up and sign in your App through Azure AD B2C.
You can see more details about Providing sign-up and sign-in to consumers with Microsoft accounts in this official document.
Hope this helps.
Using the office 365 Outlook REST API (version 2), I have a web application managing outlook subscriptions to specific mail boxes. I've been able to use the examples to obtain a token and call the API using the authorization code flow, successfully.
But now, I want to use a client credential flow and get a token using Azure AD authentication via delegate permissions (I gave the application all possible delegate permissions under office 365 exchange online). Similar to what I've seen here: Get Office 365 API access token without user interaction
I've registered my application and gotten my tenant ID, client ID & secret. I've been able to get a token but when I try to use it, I get 401, unauthorized back.
Here's how I'm getting the token:
AuthenticationContext authContext = new AuthenticationContext($"{authority}{tenantId}");
clientCredential = new ClientCredential(client_Id, secret);
authResult = await authContext.AcquireTokenAsync(resource, clientCredential);
authResult.AccessToken;
And here's how I'm trying to use the API (trying to delete the subscription using REST sharp in this code):
var token = await GetOtherToken(account);
rc = new RestClient("https://outlook.office.com/api/v2.0");
rc.AddDefaultHeader("Authorization", $"Bearer {token}");
request = new RestRequest($"me/subscriptions('{restSubId}')", Method.DELETE);
request.AddHeader("Content-Length", "0");
request.AddHeader("Content-Type", "multipart/form-data");
Looks like this is not possible. Please, someone, drop some knowledge. Thanks for reading.
When using client credential flow to acquire a token for resource , you are using application identity instead of as a user's identity. So you should assign application permission for your app(not delegate permissions) . In addition , since you are using app identity instead of user's identity , api can't recognize me(https://outlook.office.com/api/v2.0/me) . Please click here for how to build service and daemon apps in Office 365 .
I registered sample app from Microsoft graph sample app
And standard login is working but when I try to make it simplier by using this code:
var authContext = new AuthenticationContext(Settings.AzureADAuthority);
var token = authContext.AcquireToken(Settings.O365UnifiedAPIResource, new ClientCredential(Settings.ClientId, Settings.ClientSecret)).AccessToken;
I get the following error: Application with identifier '[ClientId here]' was not found in the directory microsoft.com
Setting.O365UnifiedAPIResource = #"https://graph.microsoft.com/";
Settings.AzureADAuthority = #"https://login.microsoftonline.com/common";
Does anyone know what can be the problem?
Settings.AzureADAuthority = #"https://login.microsoftonline.com/{tenant_id or tenant_name}";
When acquiring the token by using the client credential (client id + client secret). You should specify the tenant explicitly.
For example:
https://login.microsoftonline.com/{tenant_id}
or
https://login.microsoftonline.com/{your_domain.onmicrosoft.com}
BTW, as this registration will be for the sample app, it will only have the Mail.Send permission which is delegated permission. To acquire the app token, you also need to grant the app level permission in Azure AD since your are acquiring the app token rather than the user token.