I've been working on authentication and authorization within ASPNET Core. I'm familiar with setting up OpenID Connect on my own Azure tenant (such as this this example).
I'm also aware of how to register an client ID and secret on platforms such as Google (such as this example).
But what's confusing to me is that is how to setup OpenID connect to allow for a user to sign in with their own Microsoft account, regardless of whether they're created their own account through https://signup.live.com/ or signing in from their own Office365 subscription.
Is this possible? Or is OpenID Connect (for Microsoft) registrations only supported separately in each Azure AD tenant?
When you register the Azure AD app, select Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox).
Keep common as the "TenantId" in your appsettings.json file, which will allow both AAD account/O365 account and personal Microsoft account to sign in.
Related
I have Auth0 configured with Social Connections > Microsoft Account.
This is linked through Client ID/secret to a Microsoft Azure Active Directory tenant in my Microsoft organisation, with an App Registration set to allow:
Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox)
All users with a work or school, or personal Microsoft account can use your application or API. This includes Office 365 subscribers.
When I log in through my app, I can authenticate successfully using my personal account eg. blah.blah#gmail.com
However, when I try to authenticate with my work account blah.blah#myawesomecompany.ai, which is managed with an Azure Active Directory, it fails with
"That Microsoft account doesn’t exist. Enter a different account or get a new one.":
I thought given the Microsoft settings it would allow it connect.
How can I make Auth0 allow Microsoft authentication with other company's existing Azure Active Directory?
Also - can I configure it to limit that feature to specific companies AAD eg. those I have specifically nominated?
Is there a way to configure this without having to upgrade to Auth0 Enterprise?
I tried to reproduce the same in my environment and got the results like below:
I created an Azure AD Application:
Note that: Make sure to use common endpoint for Multi-Tenant and Microsoft accounts.
For sample I used the below endpoint to authorize the users:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
client_id=ClientID
&response_type=code
&redirect_uri=RedirectURI
&response_mode=query
&scope=https://graph.microsoft.com/.default
&state=12345
When I tried to sign-in with the personal account, the user logged in successfully like below:
And now I tried to login with other tenant user like below:
By using common endpoint, I am able to sign with personal accounts and other tenant accounts too successfully.
To limit the feature to specific companies AAD, check this blog.
Auth0 Enterprise is required to authorize tenants to the Azure AD Application.
For more in detail, refer below MsDocs:
Use tenant restrictions to manage access to SaaS apps - Microsoft Entra
Multi-tenant application with a whitelist on tenants authorized by Marshaljs
Assuming you want to use multi-tenant app to allow users from different company to sign in your application with their work account. Let's assume you create an Azure AD application in your tenant(tenantA).
Then in your app, you may set the TenantId as the tenant id so that even you created a multi-tenant app, you will only allow users in your tenant to sign in. And the sign in request may look like https://login.microsoftonline.com/{tenantA_tenant_id}/oauth2/v2.0/authorize?, with this link, you will be able to use account like user#tenantA.onmicrosoft.com to sign in, you can also use personal account which is invites to tenantA as a guest to sign in your account.
If you want users in tenantB to sign in your app with account like user#tenantB.onmicrosoft.com, then you must set the TenantId in your app as common which will make the auth request look like https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
Then when sign in the application created by tenantA with account in tenantB, you may see screenshot below. After consenting it, user#tenantB.onmicrosoft.com can sign in this application.
I have a webforms app running on .net 4.7.2, currently being hosted on Azure as a SaaS. It is a single software for multiple clients, each one with its own database.
Currently the user authentication is manually handled by us, but we are trying to implement a multi tenant strategy, using the AzureAD and OWIN tools.
The app service has an Identity Provider configured, from a test AAD. We can login with the provided credentials, but I can only configure a single microsoft identity provider.
I'm not sure where to go from here... After hours reading the multiple docs from microsoft, i'm still stuck.
By default, web app/API registrations in Azure AD are single tenant. You can make your registration multi-tenant by finding the Supported account types switch on the Authentication pane of your application registration in the Azure portal and setting it to Accounts in any organizational directory. So that people from other azure ad tenants will login.
multi-tenant SaaS web application sample
If in case if you want to use other identity providers, You can federate with IdPs that use the SAML protocol. SAML/WS-Fed IdP federation allows external users to redeem invitations from you by signing into your apps with their existing social or enterprise accounts. Federation with SAML/WS-Fed identity providers
And we have azure ADB2C, Azure Active Directory B2C provides business-to-customer identity as a service. Your customers use their preferred social, enterprise, or local account identities to get single sign-on access to your applications and APIs.
Reference Docs:
Sign in any Azure Active Directory user using the multi-tenant application pattern
Azure Active Directory B2C
I am trying to integrate the Sign-In functionality of Microsoft. I have registered my app in Azure Portal and My requirement is to give authority to any end-user (MS Account holder) to sign-in into my app and get the Access Token, so as per documentation i have set the client Id, Redirect URI, Tenant-ID to "Common", but its not allowing the personal MS account holder to sign-IN. Its giving below error:
"You can't sign in here with a personal account. Use your work or school account instead."
Can anyone help into this?
You should register the Azure AD app as this type: Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts.
If you want to modify the exist Azure AD app to make it support personal account login, you could modify the manifest file, setting AzureADandPersonalMicrosoftAccount as the value for "signInAudience".
See reference here.
I'm currently developing a API to commercialized in a B2B SAAS fashion.
The goal is to authenticate the worker of the company. We have an SDK that should be able to do that. There is the possibility to force each user to set credentials specific for our service, but that will hurt integration with companies applications.
The idea would be to have some kind of authentication (client independent) that make it easier to authenticate users.
The question is: There is a easy way to create an automatic process that does not depend on the client type of authentication methods, for this type of task?
Thanks in advance.
Have you taken a look at Azure AD? It specifically supports multi-tenant scenarios.
Tenants can use Azure AD Connect to sync their on-premise directory to the cloud. Clients can use ADAL to acquire a token which your service trusts. The issued token contains a tenant-id claim indicating via which tenant the user logged in.
Just to add to MvdD answer, in Azure AD support three ways to sign in:
Federated Single Sign-On enables applications to redirect to Azure AD
for user authentication instead of prompting for its own password.
This is supported for applications that support protocols such as SAML
2.0, WS-Federation, or OpenID Connect, and is the richest mode of single sign-on.
Password-based Single Sign-On enables secure application password
storage and replay using a web browser extension or mobile app. This
leverages the existing sign-in process provided by the application,
but enables an administrator to manage the passwords and does not
require the user to know the password.
Existing Single Sign-On enables Azure AD to leverage any existing
single sign-on that has been set up for the application, but enables
these applications to be linked to the Office 365 or Azure AD access
panel portals, and also enables additional reporting in Azure AD when
the applications are launched there.
I need to run .NET applications in Azure and have them authenticate against my on-premise directory (via PingFederate). It appears that ACS is the only way to do federated authentication from Azure, even though it has been deprecated for over a year. It also seems that ACS does not support OpenID Connect.
So am I correct in thinking it is not possible to do federated authentication via OpenID connect from Azure? And does anyone know when federation with external identity providers will be added to Azure AD?
Federated authentication is supported by Azure AD. Most of our enterprise customers connect their Azure Active Directory to their on-premises directory for federated authentication with Office 365 and other SAAS apps connected with Azure AD.
You can indeed federated your Azure AD with PingFederate and use Azure AD' OpenIDConnect protocol to configure single sign on for your cloud application.
Sign-up for a free trial Azure subscription and create a directory. Use the documentation here (http://msdn.microsoft.com/library/azure/jj673460.aspx) and the following sample app (https://github.com/AzureADSamples/WebApp-OpenIDConnect-DotNet) to connect your app' authentication with your directory using OpenIDConnect.
Then, add a verified domain to your directory and federate it with your PingFederate STS by following the guidance here (http://documentation.pingidentity.com/display/PFS/SSO+to+Office+365+Introduction).
We don't recommend using ACS for this scenario.
Hope this helps.