We Keep Coding

ImmutableID of the user missing when trying to acquire a token for MS Graph API (Windows auth)

I'm developing an API that uses the Microsoft Graph Client SDK to make multiples calls to a Sharepoint site.
To authenticate the users making the calls to the API, I'm using the Integrated Windows Provider method, with this very simple code:
var clientApp = PublicClientApplicationBuilder
.Create(_apiSettings.Value.AzureClientId)
.WithTenantId(_apiSettings.Value.AzureTenantId)
.Build();
var token = clientApp.AcquireTokenByIntegratedWindowsAuth(new string[] { _apiSettings.Value.MicrosoftGraphApiScopeUrl })
.ExecuteAsync().Result;
When calling the method containing this code in local, it works flawlessly. But when I deploy the app to our test server, and by using the NTLM authentication with the same user than in local, I'm having this error:
Microsoft.Identity.Client.MsalUiRequiredException: AADSTS90020: The
SAML 1.1 Assertion is missing ImmutableID of the user.
When printing the content of the HttpContext.User, I see that the same user, connected to the same group, is both used on the "online" and the local version.
I already tried adding this header, but it's not doing anything:
var immId = new Dictionary<string, string>();
immId.Add("Prefer", "IdType=\"ImmutableId\"");
var token = clientApp.AcquireTokenByIntegratedWindowsAuth(new string[] { _apiSettings.Value.MicrosoftGraphApiScopeUrl })
.WithExtraHttpHeaders(immId)
.ExecuteAsync().Result;
What can I do ?
Thanks!

If your application don't have the admin to consent to the application.You will get the MsalUiRequiredException.
Try with the adding the admin consent to application .
Or Try with adding tenant admin selected the Grant/revoke admin consent for {tenant domain} button on the API permissions tab of the registration for the application. For more information, see Add permissions to access your web API.
For more details refer this document

Exception in Azure AcquireTokenAsync() accessing_ws_metadata_exchange_failed

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().

Create Microsoft Graph GraphServiceClient with user/password unattended

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.

invalid_grant - type = password: user or admin has not consented to use the application

I am getting a consent error when trying to obtain a token. Because of our application, we can't show an interactive dialog to give consent.
"AADSTS65001: The user or administrator has not consented to use the
application with ID <'my native client app id'>. Send an
interactive authorization request for this user and resource.
AuthenticationContext ctx = new AuthenticationContext(
string.Format("https://login.microsoftonline.com/{0}","mytenant.onmicrosoft.com"));
UserPasswordCredential cred = new UserPasswordCredential("login#mytenant.onmicrosoft.com", "Password");
var result = ctx.AcquireTokenAsync("my api uri", "my native client id", cred);
We are using the grant_type=password and client_id is a Native app id, and resource is the Web API app URI.
Permissions-wise, from the client app, a delegated permission has been given to access the api app and have also tried setting oauth2AllowImplicitFlow : true in the manifest.
All applications have been created in the new preview Azure AD section of the new portal (portal.azure.com)

Unfortunately if your application needs access to certain resources like the Graph API, you will need to prompt for consent at least one time.
Even if your app doesn't have an interactive login experience, you should be able to prompt this once to unblock your scenario in your tenant.
Use the following URL:
https://login.microsoftonline.com/<TenantID>/oauth2/authorize?client_id=<AppID>&response_type=code&redirect_uri=<RedirectURI>&resource=<ResourceURI>&prompt=admin_consent
You can see here we have just simply generated the login URL which would be generated as part of an interactive login experience. You will need to fill out your own specific data like Reply URL, App ID, Resource URI, etc...
Note that we added a final query string at the end where we are forcing a "consent" prompt. This should be done by an Administrator, who would be able to consent on behalf of the whole tenant. Once you have done that, the username/password flow should start working for you.
Also, as an additional note, implicit grant flow has nothing to do with consent.
Please read this section in the OAuth 2 spec:
https://www.rfc-editor.org/rfc/rfc6749#section-1.3.2
You should only use this setting if you are creating a single-page application with something like JavaScript; Otherwise, there are significant security concerns with this setting on applications that should not have it.

Office 365 APIs Microsoft Graph authentication failed

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.