We have a public consumer application for which we use Auth0 as identity platform and through Auth0 we have enabled a couple of social logins to which we now want to add "Login with Microsoft" as an option so that anyone with any type of Microsoft account can login.
Obviously we will need to enable the Microsoft social connection in our Auth0 instance and connect it to a Active Directory Application and Tenant created in Azure.
What I can't seem to find the answer for is which type of tenant we should setup for this, whether we should use a Azure Active Directory tenant with a multi-tenant application or if we should use a Azure Active Directory (B2C) tenant for this?
Thanks for posting your query. As per https://auth0.com/docs/authenticate/identity-providers/enterprise-identity-providers/azure-active-directory/v2#register-your-app-with-azure-ad Azure AD would support for multitenant apps but not with social account (until you plan to send invitation to each user's personal account for Azure AD B2B).
For Microsoft Social accounts Azure B2C would suit your requirement.
On Auth0 Admin Console:
Create a web application in Auth0
Copy the client ID and secret
Add a callback URL from your B2C tenant in given format: https://.b2clogin.com/.onmicrosoft.com/oauth2/authresp
Copy the “OpenID Configuration” URI from advance setting.
On Azure B2C tenant:
Add an Identity provider to B2C, Azure AD B2C > Identity providers > New OpenID Connect Provider
Input “OpenID Configuration” URI you copied in above step to Metadata URL.
Similarly add client ID and Client secret you copied from Auth0.
Complete the claims mapping ref: https://learn.microsoft.com/en-in/azure/active-directory-b2c/identity-provider-generic-openid-connect?pivots=b2c-user-flow#claims-mapping
Hit Save and Auth0 will be saved as IDP in your Azure B2C tenant.
Thanks
I've gathered the following insights since posting my question
Summary
Auth0 Social connection -> Azure Active Directory tenant with an app configured to support "Personal Microsoft accounts"
Auth0 Enterprise connection -> Azure Active Directory tenant with an app configured to support "Accounts in any organisational directory and personal Microsoft accounts"
See guide of different app types here
Details
Since we wanted to support login with any microsoft account (multi tenant + personal) my initial attempt of using an Auth0 Social connection for this was incorrect, since the Social connection will only allow successful logins with personal accounts regardless of how you have setup the App registration in Azure
Auth0 Enterprise connection is the way to go for our case, with an Azure app registation supporting multi tenant + personal accounts. Also when setting the connection up in Auth0, make sure to enable the "Use common endpoint" setting as described here
The Azure Active Directory B2C tenant type is not useful with any of the Auth0 connections as you likely won't be able to get a satisfying consent screen with verified publisher. I'm guessing its just the wrong way of using the B2C tenant, where its supposed to be used the other way around with the Azure tenant being the identity platform optionally integrating applications from Auth0 like in the answer from Mavric20
Related
I am following a tutorial Build Java apps with Microsoft Graph
and after using my personal account for Azure AD to register the application. I am not able to sign in using my personal account but I set the support account as 'Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts. Any help?
Screenshot
You need to change the /tenant id endpoint to the /common endpoint.
The /tenant id endpoint only allows users with work/school accounts
of a specific Azure AD tenant to log in to the application. It does
not support personal accounts.
Only the /common endpoints will allow personal Microsoft accounts to
log in to the application.
I have a requirement to integrate multiple external azure active directories into my application(multitenant). Currently I'm using AD B2C. In brief any client purchases my product, should be able to integrate their organization azure active directory with my application and those AD users should be able to login to application without signing up.
One of the approaches i was trying was to validate external azure active directory users by asking client to create applications in their AD for authentication and authorization. But it seems to be a bit tricky since we already have applications created inside B2C tenant we use and securing API with application in B2C Tenant. With having multiple AD s api will need to be secured with multiple ids.How to do this?
second approach was to read the external azure active directory users using graph api and invite them as guest users. But here any of the guest users created couldn't sign into the application even after changing "guest" to "member" User type. Any idea in implementing this?
UPDATE
I did all the steps as in https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-setup-commonaad-custom but when i try to login using one of my Azure AD Account after entering the credentials it navigates me to a B2C signup page.That is because i don't have that AD account in my B2C tenant. After doing the signup only i will be able to login to the application and get the token. And the AD user is created in our B2C Tenant with the source
Federated Azure Active Directory
Is there anyway to get rid of navigating to signup page after entering credentials and instead login to the application with the tokens at once so that the user will not be created in our B2C Tenant and validate user from client's Azure AD
You are better off federating AAD B2C with the Azure AD Common endpoint. This allows a single option for any user with an O365 account to login to your service from any Azure AD Tenant.
You can then whitelist tenants such that only your clients' Azure AD accounts are able to login via this single option. Clients only need to provide their TenantId to you.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-setup-commonaad-custom
<!-- The key below allows you to specify each of the Azure AD tenants
that can be used to sign in. Update the GUIDs below for each tenant. -->
<Item Key="ValidTokenIssuerPrefixes">https://sts.windows.net/00000000-0000-0000-0000-000000000000,https://sts.windows.net/11111111-1111-1111-1111-111111111111</Item>
Creating separate B2C tenants for individual organizations could be a solution.
You will integrate each Azure AD tenant with the on-premises AD of the organization.
In order to sync both ADs you will need to use Azure AD Connect
(more information here on MSDN: https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/identity/azure-ad#azure-ad-connect-sync-service)
Once ADs are synced your web app will request access and id tokens for individual B2C tenant.
For more information on how to run various user journeys using OIDC read here:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-reference-oidc
Referred the following stack overflow post Azure B2C client credentials grant
We are presently using Azure B2C.
I understand that Azure B2C does not support the client credential flow for now.
We have a requirement where an external application (server Application outside our organization) needs to access our resource (api hosted within our organization)
Is there any way we can do this from Azure AD-B2C or would we need Azure AD-B2B for these type of requirements. ?
Currently, your specific scenario -- where you are needing an access token to be issued for access by a daemon or server app to your API app -- isn't supported, however you can register the API app through the “App Registrations” blade of the Azure AD directory for your Azure AD B2C tenant.
You can upvote support for the client credentials flow by Azure AD B2C at:
https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/18529918-aadb2c-support-oauth-2-0-client-credential-flow
If the API app is to receive tokens from both a web/native app as well as the daemon/server app, then you will have to configure the API app to validate tokens from two token issuers: one being Azure AD B2C and other being the Azure AD directory for your Azure AD B2C tenant.
You should not do this anyway.
Instead, provide a portal for your customers where they can manage api keys.
Implement api keys as a second auth schema in your Api
We get the following error when trying to access an AAD application, which is connected to Azure B2C.
User account 'xxxxx#gmail.com' from identity provider 'live.com' does not exist in tenant 'xxxxxxxx' and cannot access the application 'xxxxxxxxxxx' 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.
The live account shows up in both the B2C and AAD as a live.com user. Manually created accounts can log in. Yet when logging in from a B2C account, I get the above error.
How can I solve this problem?
If your requirement is to accept both personal accounts in addition to corporate accounts, then you should not be using ADAL. ADAL/ADAL.JS is designed only to accept corporate accounts and use the so called Azure AD 'v1' endpoint.
Here are your options:
AppSource only requires corporate accounts sign-ins. If you only need AppSource certification, you can keep using adal.js to sign-in corporate accounts. Then what you need to do is to set your application to be multi-tenant in Azure Portal, so you don't need to add guest accounts. But, again, this option only accepts corporate account sign-ins.
If your requirement is to also accept personal accounts, then you need to use msal.js instead of adal.js - and then register your application in the new portal https://apps.dev.microsoft.com . This new application is known as converged application and uses the Azure AD v2 endpoint. To get started use this guide as a starting point to sign-in users using msal.js.
I am trying to access the Azure AD graph API. I have successfully added users to my test environment (ADFS) and changed their domain to {mytestdomain}.onmicrosoft.com. The password synchronization using Azure AD Connect works.
Now I have setup the production environment (including ADFS) accordingly and I am now synchronizing the users, but obviously can't change the domains to {mydomain}.onmicrosoft.com. The users now have {mydomain}.net and I am synchronizing the users to a verified domain in Azure AD.
When trying to access
https://login.microsoftonline.com/{mydomain}.net/oauth2/token
using the following (yes, I know that grant_type is not recommended, but that's not the point)
grant_type: password
username: {user}#{mydomain}.net
password: XXXX
resource: https://graph.windows.net
client_id: {Guid}
I get:
AADSTS70002: Error validating credentials.
AADSTS50126: Invalid username or password
If I use an administrator like admin#{mydomain}.onmicrosoft.com it works fine.
In the Azure portal I have tried changing the primary domain from {mydomain}.onmicrosoft.com to {mydomain}.net, but it does not make a difference.
It says in the management portal:
"To configure {mydomain} for federated sign-on to your Azure Active Directory, run Azure AD Connect on your local network."
Does that apply when using the graph API as well? Do I have to setup federation on my local network or is there another way around?
In the azure portal I have tried changing the primary domain from
{mydomain}.onmicrosoft.com to {mydomain}.net, but it does not make a
difference.
I'm not clear the details of your Syncing steps. Besides verified you custom domain in Azure AD, you also need some other configurations, like Azure AD sign-in configuration. You can see more details in this document.
Does that apply when using the graph api as well? Do I have to setup
federation on my local network or is there another way around?
Yes, Since you're using ADFS, you need to use Federated SSO (with Active Directory Federation Services (AD FS)) to allows your users to sign in to both cloud and on-premises resources by using the same passwords.
You can also see more details about Azure AD Connect user sign-in options in this official document.
Hope it helps!