I tried using the code provided here: https://github.com/Azure-Samples/active-directory-javascript-singlepageapp-dotnet-webapi-v2
It works for both MSA and Azure AD authentication. I need to know whether the email address entered was MSA or Azure AD. Is there a way to find that out from the response?
In the id_token you get back, there's a iss (issuer) claim.
This claim contains the user's tenant.
If the user used a Microsoft Account (MSA), their issuer claims will contain the following GUID for the MSA tenant: 9188040d-6c67-4c5b-b112-36a304b66dad
The full value of the issuer will be:
https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0
Any other GUID indicates that the user signed in using Azure AD and the GUID value will represent their Azure AD tenant.
For more information check out the id_token section of the Token Reference documentation.
Related
As an example, I have added an Azure AD external identity provider to Azure B2C using OpenIDConnect.
I am interested in accessing claims from the external identity provider (Azure AD) that aren't present in the ID Token Azure B2C returns to my app. For instance, I know that there is an amr claim from the external identity provider. If I configure Azure B2C to pass thru the Access Token obtained from the external IDP like this:
<OutputClaim ClaimTypeReferenceId="identityProviderAccessToken" PartnerClaimType="{oauth2:access_token}" />
Then my application can see the Access Token, and if I decode it, I can see the claims I'm looking for are present.
However, I want to process these claims within Azure B2C to change it's behavior based on these claims. For instance, I would like to look at the amr claim and determine if multi-factor authentication should be enforced or not.
Is there any mechanism through which Azure B2C can handle the claims that are returned in the Access Token from the external identity provider? Some type of syntax that references a claim in the Access Token that Azure B2C retrieves from the IDP? The closest thing I can find might be to change from OpenIdConnect protocol to Oauth2 protocol in the claimsprovider configuration. But, I've seen mixed messages about this.
This is a generalized concept question concerning obtaining information of the user in the bot chat. Preferably this would be through OpenID and to start with using Microsoft Accounts. We would want to be able to read User Display Name, User Email address, User Group Membership, etc. What is the best way to obtain this information in Azure Bot Framework? In MVC using OpenID to obtain ClaimsPrincipal is easy, but can this concept be used in Azure Bot Framework and are there any examples of this process?
There was a lot that went into this, but essentially I used an OAuth Connection on the Bot service to send the user to AADv2 endpoint to obtain the token. I then used that token to send to the GraphServiceClient method (part of Nuget package Microsoft.Graph) to obtain User information. This was granted by giving the app in Azure AD MS Graph User.Read API permissions.
I am migrating my asp net core MVC web app hosted in Azure App service with Azure AD IAM from v1 to v2. When a user logs in I create/update a local user account in my database which contains the user email. The problem I have is the email claim which is now an optional claim in v2 is null so my I cannot insert a new user record in my local database.
I have been through the MS documentation and configured my optional claims in app registration manifest etc but it does not work. I have tried all 3 claim variations (email, verified_primary_email, verified_secondary_email) but nothing comes through. However the optional claims for given_name and family_name are working as expected so the configuration must be right. How can I get email to work?
Below is my configuration and result.
App Registration Manifest
App Registration Permissions
User Profile Setup (email configuration for directly assigned member)
Returned Claims
Startup Config (adding email scope)
services.AddAuthentication(AzureADDefaults.AuthenticationScheme)
.AddAzureAD(options => Configuration.Bind("AzureAd", options));
services.Configure<OpenIdConnectOptions>(AzureADDefaults.OpenIdScheme, options =>
{
options.Authority += "/v2.0/";
options.Scope.Add("email");
options.TokenValidationParameters.ValidateIssuer = true;
// Set the nameClaimType to be preferred_username.
// This change is needed because certain token claims from Azure AD v1.0 endpoint
// (on which the original .NET core template is based) are different in Microsoft identity platform endpoint.
// For more details see [ID Tokens](https://learn.microsoft.com/azure/active-directory/develop/id-tokens)
// and [Access Tokens](https://learn.microsoft.com/azure/active-directory/develop/access-tokens)
options.TokenValidationParameters.NameClaimType = "preferred_username";
}
Signin Request (including email scope)
https://login.microsoftonline.com/28f6d551-***-7f402200e732/oauth2/v2.0/authorize
?client_id=08fde457-***-7b0eebc5e4e2
&redirect_uri=https%3A%2F%2Flocalhost%3A44308%2Fsignin-oidc
&response_type=id_token
&scope=openid%20profile%20email
&response_mode=form_post
&nonce=637023698441049167.ZWZlMGQ1MzctZDVmMi00OGZlLTg5YzYtMjczOWIxNzlhYjI0MzdiNGI2YzMtZTFjYi00MDMxLWFkODItNmExNDlmZTQ2MWE1&state=CfDJ8Em5zZW9XwdJkjHAUddTGuvClgDAA0NFafwsZBlTbau2qhMPcRBM36vSSzFEw7GME28L57BSQyGo8WNNzd61_bciTunD0R15oC__96_tXlWaPmk3jZkOpA2VUoiwG9XrZjfDOTQIWAzS2IuqUu5gXWU8dgK7YEfyAuRwVmCQlWqlt94HPUwMSsSJpMsdlB6HD3Tb0DaPCspo2BiYga-5LWDQ5FBnFCpxPAdLNa6LTHHNtKjUbG7YNX4oEKUBhWtxQ0Kh1CakChUFCpmMzAmBgyN5Hh_-nk3BrO3V6PrgbvDsGO6QNip5hCwiDd92gexrLYwS_UeKruPKCQMZBWZ9LnSRaNnTDN1483Abk75JiH19XPJwexmQ5aMa1KZwcde4axF-tb2cmnwWY8O4NGhRiQDSISZJAuXmHWBtAeNhnLHN659vbeiW8mo5aWD65NcfhLtio2odxvLFh3JZGoRwHCtKzu9fq8v4w7IN2f1bNb8zPdo7Lw_GREiYKs1twibIh305tja30MMRS3oAE1hKQE20A4wtmxVACuPZ201SRkFg8OHl-Iz6e4Pa41P4gT-F2jpzL1zqklDw0tzaYq68uVlqmeCY5T9vo2qkfvRuIdpyyTGu8pdi-Z6sVvIpIxPllQ
&x-client-SKU=ID_NETSTANDARD2_0
&x-client-ver=5.3.0.0
Returned Token (email claim still missing)
UPDATE 2019-08-26
I suspect the issue is with the user account instead. As a directory administrator I create the user accounts within AAD and enter the Email and Alternate Email values. However when I log in to AAD as the end user and view my profile I can see that Email field is blank and only Alternate Email field is populated as shown below. I'm not sure why the user profile is not picking up the set email address but it's a problem and I now have to find a way of getting the Alternate Email into the ID Token instead. How can this be done?
Email Addresses in AAD
Email Addresses in User Profile
Just some findings and suggestions, might not be a exact answer.
Based on the documentation(optional claims) from Microsoft:
A. The claim's name is email.
B. As you were migrating from V1 to V2, I just tested the V2 (For convenience, I tested with a REST API tool). By adding the openid and email scopes, I can get the email claim in id token.
C. Analyze the id token in jwt.io, I can get the email claim:
I did not modify the manifest, just added openid and email scopes. You can have a try.
I need help integrating Azure AD B2C and Google APIs. Briefly, I created a tenant on Azure AD B2C, policies and a Native App. Users can register to my app and sign in without any problems. Now I need to use Google APIs to access the logged-in account's information and manage some information (Google MyBusiness data). How can I achieve that. Is that possible ?
Furthermore, even if that is not connected to Azure AD B2C, how can I request to the user to accept that my app to view MyBusiness data?
UPDATE: I understand that I need to authorize my app to https://www.googleapis.com/auth/plus.business.manage Google scopes. Is it possible to request that scope during Google SignIn application authorization process?
Thanks everyone.
As part of the authentication exchange between Azure AD B2C and Google (as well as other identity providers), an access token is issued by Google for use by (and only by) Azure AD B2C, where this access token is used by Azure AD B2C to access the authorized information for the authenticated end-user.
Currently, Azure AD B2C does not pass this access token through to the relying party application (i.e. your native client application), therefore applications can't access the information for the end-user.
UPDATE on 20 June 2019
Using a custom policy, you can pass the access token from the external identity provider through Azure AD B2C to your relying party application.
From the official Azure AD B2C FAQ:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-faqs
Can I configure scopes to gather more information about consumers from various social identity providers?
No, but this feature is on our roadmap. The default scopes used for our supported set of social identity providers are:
Facebook: email
Google+: email
Microsoft account: openid email profile
Amazon: profile
LinkedIn: r_emailaddress, r_basicprofile
We are currently using Azure Access Control Services (***.accesscontrol.windows.net) to allow customers with personally-managed Microsoft Accounts (Identity Provider) to sign in to our customer self-service portals (Relying Party Applications), which are Angular apps powered by Web API services. In our Access Control Services we are currently passing through the nameidentifier http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier claim from Windows Live ID to the relying party APIs, which match that token to an identity in our applications.
We are looking to support both Enterprise and Personal Microsoft Accounts with the Azure AD v2.0 service, but do not understand how to migrate our existing users to the new system. The code examples suggest that the OWIN middleware returns the NameIdentifier claim from the user's Identity Provider, but if that Identity Provider is the same Microsoft Account (aka Windows Live ID), will that be the same NameIdentifier we are currently receiving via Access Control Services pass-through?
Any help and/or documentation that clarifies how this transition is intended to work would be appreciated.
If the nameidentifier coming out of ACS is the randomly generated value then you're kind of stuck because that value is unique to the ACS/RP/User. If it's returning the actual Live ID then it'll obviously only match if the Azure AD user has the same email address.
I don't know if any documentation out there that describes how to handle this situation. My recommendation is to just require a one-time authentication from each source within the same session and marry the two results. That would basically mean
authenticate to Azure AD
Your app: Hey you don't have any user details, do you want to associate a Live ID?
Authenticate Live ID
Associate Live ID with Azure AD
Then if they want to sign in with either accounts in the future you have a link between the two.