Azure B2C is a authentication portal for social, personal and corporate accounts. The authentication is based on OpenID Connect.
You can modify the login pages, add identity providers, give all Azure AD tenants the right to login thru your tenant.
There is wide range of possibilities with it but first about the authentication and then to the end-user product benefits and setup.
Table of Contents
What are the bits and pieces for B2C?
OpenID Connect
OpenID has these certified partners
What is OpenID?
OpenID Connect (OIDC) is an authentication protocol built on OAuth 2.0 that you can use to securely sign in a user to an application. When you use the Microsoft identity platform’s implementation of OpenID Connect, you can add sign-in and API access to your apps. This article shows how to do this independent of language and describes how to send and receive HTTP messages without using any Microsoft open-source libraries.
OpenID Connect extends the OAuth 2.0 authorization protocol for use as an authentication protocol, so that you can do single sign-on using OAuth. OpenID Connect introduces the concept of an ID token, which is a security token that allows the client to verify the identity of the user. The ID token also gets basic profile information about the user. It also introduces the UserInfo endpoint, an API that returns information about the user.
OpenID authentication flow
OpenID Connect metadata
Discovery document path: /.well-known/openid-configuration
Authority: https://login.microsoftonline.com/{tenant}/v2.0
The {tenant}
can take one of four values:
Value | Description |
---|---|
common | Users with both a personal Microsoft account and a work or school account from Azure AD can sign in to the application. |
organizations | Only users with work or school accounts from Azure AD can sign in to the application. |
consumers | Only users with a personal Microsoft account can sign in to the application. |
8eaef023-2b34-4da1-9baa-8bc8c9d6a490 or contoso.onmicrosoft.com | Only users from a specific Azure AD tenant (whether they are members in the directory with a work or school account, or they are guests in the directory with a personal Microsoft account) can sign in to the application. Either the friendly domain name of the Azure AD tenant or the tenant’s GUID identifier can be used. You can also use the consumer tenant, 9188040d-6c67-4c5b-b112-36a304b66dad , in place of the consumers tenant. |
The authority differs across national clouds – e.g. https://login.microsoftonline.de
for the Azure AD Germany instance. If you do not use the public cloud, please review the national cloud endpoints to find the appropriate one for you. Ensure that the tenant and /v2.0/
are present in your request so you can use the v2.0 version of the endpoint.
Azure B2C (Admin) experience
Creating a B2C tenant is really straight forward, you create a resource and find Azure B2C, choose your B2C name tenant name and create.
You can also link existing B2C tenants to your subscription.
In any case you need an tenant having a subscription to the background that will be linked for B2C tenant.
The portal itself
Couple of points here. First you register an application then setup identity providers and the last creating user flows.
Registering application
- Select App registrations, and then select New registration.
- Enter a Name for the application. For example, webapp1.
- Under Supported account types, select Accounts in any identity provider or organizational directory (for authenticating users with user flows).
- Under Redirect URI, select Web, and then enter
https://jwt.ms
in the URL text box.The redirect URI is the endpoint to which the user is sent by the authorization server (Azure AD B2C, in this case) after completing its interaction with the user, and to which an access token or authorization code is sent upon successful authorization. In a production application, it’s typically a publicly accessible endpoint where your app is running, likehttps://contoso.com/auth-response
. For testing purposes like this tutorial, you can set it tohttps://jwt.ms
, a Microsoft-owned web application that displays the decoded contents of a token (the contents of the token never leave your browser). During app development, you might add the endpoint where your application listens locally, likehttps://localhost:5000
. You can add and modify redirect URIs in your registered applications at any time.The following restrictions apply to redirect URIs:- The reply URL must begin with the scheme
https
. - The reply URL is case-sensitive. Its case must match the case of the URL path of your running application. For example, if your application includes as part of its path
.../abc/response-oidc
, do not specify.../ABC/response-oidc
in the reply URL. Because the web browser treats paths as case-sensitive, cookies associated with.../abc/response-oidc
may be excluded if redirected to the case-mismatched.../ABC/response-oidc
URL.
- The reply URL must begin with the scheme
- Under Permissions, select the Grant admin consent to openid and offline_access permissions check box.
- Select Register.
Identity providers
These are there by default, I have already added MS Account and Azure AD to this and will go thru those options also.
In the beginning of this post I wrote about the OpenID Connect supported providers, all of those you can add to this list.
Let’s go thru MS Account first.
First the MS Account provider will be registered to the linked Real Azure subscription with app registration.
- Choose All services in the top-left corner of the Azure portal, and then search for and select App registrations.
- Select New registration.
- Enter a Name for your application. For example, MSAapp1.
- Under Supported account types, select Accounts in any organizational directory (Any Azure AD directory – Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox).For more information on the different account type selections, see Quickstart: Register an application with the Microsoft identity platform.
- Under Redirect URI (optional), select Web and enter
https://your-tenant-name.b2clogin.com/your-tenant-name.onmicrosoft.com/oauth2/authresp
. If you use a custom domain, enterhttps://your-domain-name/your-tenant-name.onmicrosoft.com/oauth2/authresp
. Replaceyour-tenant-name
with the name of your tenant, andyour-domain-name
with your custom domain. - Select Register
- Record the Application (client) ID shown on the application Overview page. You need the client ID when you configure the identity provider in the next section.
- Select Certificates & secrets
- Click New client secret
- Enter a Description for the secret, for example Application password 1, and then click Add.
- Record the application password shown in the Value column. You need the client secret when you configure the identity provider in the next section.
And then go go B2c tenant and add your app id and secret to the settings.
What about Azure AD (Single tenant)?
The process is similar but you need to define more. First your create the app registration inside the Real Azure tenant having the subscription.
- Under Azure services, select App registrations or search for and select App registrations.
- Select New registration.
- Enter a Name for your application. For example,
Azure AD B2C App
. - Accept the default selection of Accounts in this organizational directory only (Default Directory only – Single tenant) for this application.
- For the Redirect URI, accept the value of Web, and enter the following URL in all lowercase letters, where
your-B2C-tenant-name
is replaced with the name of your Azure AD B2C tenant.Copyhttps://your-B2C-tenant-name.b2clogin.com/your-B2C-tenant-name.onmicrosoft.com/oauth2/authresp
For example,https://fabrikam.b2clogin.com/fabrikam.onmicrosoft.com/oauth2/authresp
.If you use a custom domain, enterhttps://your-domain-name/your-tenant-name.onmicrosoft.com/oauth2/authresp
. Replaceyour-domain-name
with your custom domain, andyour-tenant-name
with the name of your tenant. - Select Register. Record the Application (client) ID for use in a later step.
- Select Certificates & secrets, and then select New client secret.
- Enter a Description for the secret, select an expiration, and then select Add. Record the Value of the secret for use in a later step.
Once you have it created you will go back to B2C tenant and add the info to a new OpenID provider.
- Select Identity providers, and then select New OpenID Connect provider.
- Enter a Name. For example, enter Contoso Azure AD.
- For Metadata url, enter the following URL replacing
{tenant}
with the domain name of your Azure AD tenant:https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration
For example, https://login.microsoftonline.com/contoso.onmicrosoft.com/v2.0/.well-known/openid-configuration
. If you use a custom domain, replace contoso.com
with your custom domain in https://login.microsoftonline.com/contoso.com/v2.0/.well-known/openid-configuration
.
- For Client ID, enter the application ID that you previously recorded.
- For Client secret, enter the client secret that you previously recorded.
- For Scope, enter
openid profile
. - Leave the default values for Response type, and Response mode.
- (Optional) For the Domain hint, enter
contoso.com
. For more information, see Set up direct sign-in using Azure Active Directory B2C. - Under Identity provider claims mapping, select the following claims:
- User ID: oid
- Display name: name
- Given name: given_name
- Surname: family_name
- Email: email
- Select Save.
And this what it looks like in the portal.
Once done add them both as identity providers to user flows. In my example I will use the default flows only.
Identity providers to user flows
Open policies -> user flows.
You will these templates out of the box.
In my example I will use Sign Up or Sign in.
Open your user flow and choose identity providers.
Then save and you run your flow from “Run user flow” it will try your journey (yes, journey)
In the testing it will ran against jwt.ms and it will show how the login experience is.
and this is what the default page look like. As you can see there is the identity providers we setup and ready to use.
When you login, you will be greeted with the consent from your Azure AD and the token is created.
What about Azure AD (multi-tenant)?
Multi-tenant means that You can sign-in using login.microsoftonline.com page with the credentials from Your home tenant.
All the security settings configured will be used because You are logging to Your own environment, B2C will just ask for the authentication and pass the authorization with the token.
You could use custom claims inside the token and I will give an example how.
How to setup an multi-tenant sign-in flow?
Getting started with multi-tenant flows, you need B2C started pack from Microsoft.
1 |
git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack |
It will download the xml files.
Registering application
After the tutorial you will have jwt.ms as an registered app in your B2C tenant. JWT.MS allows you to decode tokens and the tokens never leave your browser.
Adding encryption keys for IEF
Once You are done with ProxyIdentityExperienceFramework you can start to modify the xml-files.
XML-files
You can start with SocialAndLocalAccounts it will enable the use of both local and social accounts.
You can start adding Facebook as social media IdP by following Microsoft instructions blindly.
Or You can remove it completely if not needed. Then You don’t see any prompts.
Base-policy
From the base policy you will first change the TenantId and PolicyUri. You will use Your B2C TENANT not the linked Azure AD which has B2C tenant under it.
In the base file, there is also PartnerClaimTypes, partner claims come from the authenticating (source Azure AD). TID in example is the Tenant ID of the source Azure AD, you can use this inside Your tokens later.
And You can define your own claims also. This will get users email address.
In this file You will also define those Identity providers. In here Facebook is still there but You can remove the whole section from <ClaimsProviders> to </Claimsproviders> if not needed.
There is also the Local Account sign-in in the base file.
And under that one your input
And output claims, output claims will be inserted into the token that will authorize your session.
Azure AD IdP is also in this file. You will add Your app registrations Object and App ID in here, the secret that was defined when You registered the app and the Token signing key container.
This was done in the guide that I mentioned earlier when we were adding Identity Experience Framework applications ^^.
User journeys
Inside the base-file you also have User journeys, there will make the user sign-in flow or the path they will follow. You can have profile edits here (if you use local accounts in example) and password reset.
But I will concentrate only in the SignUpOrSignin journey. There is Facebook again, if not needed delete.
And also removing the claims from SelfAsserted-Social technical profile. This will disable the profile edit screen as we don’t need it.
Still following? Yes, I know it’s a lot to comprehend but you need testing, breaking, deploying to understand the process with custom flows.
Token life-time
Life of the token and refresh is also defined in this file.
CAE (Continuous access evaluation)
CAE is enabled by default if You don’t disable it with Conditional Access policies and it secure your authorization process.
Critical events that will be evaluated:
- User Account is deleted or disabled
- Password for a user is changed or reset
- Multi-factor authentication is enabled for the user
- Administrator explicitly revokes all refresh tokens for a user
- High user risk detected by Azure AD Identity Protection
Extensions-policy
All the policies relay on the last one, Extension to Base and Sign-In to Extension. That the the reason You have to upload them in the certain order.
In here You will define the ClaimsProviders for the Multi-tenant. Like it says in the xml-file, add Tenant ID’s You want to allow or don’t add any if need to use as multi-tenant. AADAppSecret if the secret from Multi-tenant App that is inside your Linked Azure AD not B2C.
These are confusing for the first 100 times, I know but You will get this, eventually. It just takes time to understand.
Claims transformation is also happening in this file. Basically Your can get others claims and add them to different types of claims, depending on Your need to get that custom token working.
In here you will also add the IEF registrations made in the beginning.
Sign-in policy
Sign-in policy will gather the information from the users and insert it to the token.
The relying party is referring to the User journey inside Extension policy.
Extension policy
If You followed the instruction from Microsoft, You should now have three policies inside the tenant with B2C_1A_ added in front of them and you can follow the steps for testing the policies, if not keep trying and learning.
You don’t need the TrustFrameworkLocalization.xml if don’t do any localization for the languages and pages.
Eventually the portal will look like this.
Benefits of custom policies
Custom policies are completely customizable, like meaning completely. You can add language support, own pages or just to remove all the pages and leave the login.microsoftonline.com prompt.
There is numerous ways to achieve the goal but you just need to understand how it works to design and deploy a working solution.
DevOps
You can also deploy Custom policies with pipelines.
What about consenting?
If the end-users come from Azure AD they will use Enterprise applications to publish the Your app for SSO and management.
So when a user from the organization first time logins to Your app, they will be greeted with Consent and if the tenants security settings are up-to-date that will be denied.
Why? Well let me explain
When You register Your application in the external Azure AD, you will have to make it as Enterprise Application if You want to enable SSO or to display the application inside MyApps portal.
I wrote a different post about consenting, so here you go.
How?
Azure AD B2C (end-user) experience
The end-user experience with consumer accounts and default user flows.
And for the enterprise users and for custom flows. The same login screen that you login to all Microsoft services. And Your own security methods after login. Or even ADFS if you have it.
Features
An Azure AD B2C tenant is different than an Azure Active Directory tenant, which you may already have, but it relies on it. The following Azure AD features can be used in your Azure AD B2C tenant.
Feature | Azure AD | Azure AD B2C |
---|---|---|
Groups | Groups can be used to manage administrative and user accounts. | Groups can be used to manage administrative accounts. Consumer accounts can not be member of any group. |
Inviting External Identities guests | You can invite guest users and configure External Identities features such as federation and sign-in with Facebook and Google accounts. | You can invite only a Microsoft account or an Azure AD user as a guest to your Azure AD tenant for accessing applications or managing tenants. For consumer accounts, you use Azure AD B2C user flows and custom policies to manage users and sign-up or sign-in with external identity providers, such as Google or Facebook. |
Roles and administrators | Fully supported for administrative and user accounts. | Roles are not supported with consumer accounts. Consumer accounts don’t have access to any Azure resources. |
Custom domain names | You can use Azure AD custom domains for administrative accounts only. | Consumer accounts can sign in with a username, phone number, or any email address. You can use custom domains in your redirect URLs. |
Conditional Access | Fully supported for administrative and user accounts. | A subset of Azure AD Conditional Access features is supported with consumer accounts Lean how to configure Azure AD B2C conditional access. |
Premium P1 | Fully supported for Azure AD premium P1 features. For example, Password Protection, Hybrid Identities, Conditional Access, Dynamic groups, and more. | A subset of Azure AD Conditional Access features is supported with consumer accounts. Learn how to configure Azure AD B2C Conditional Access. |
Premium P2 | Fully supported for Azure AD premium P2 features. For example, Identity Protection, and Identity Governance. | A subset of Azure AD Identity Protection features is supported with consumer accounts. Learn how to Investigate risk with Identity Protection and configure Azure AD B2C Conditional Access. |
Limitations
The following end-user related service limits apply to all authentication and authorization protocols supported by Azure AD B2C, including SAML, Open ID Connect, OAuth2, and ROPC.
Category | Limit |
---|---|
Number of requests per IP address per Azure AD B2C tenant | 6,000/5min |
Total number of requests per Azure AD B2C tenant | 12,000/min |
The number of requests can vary depending on the number of directory reads and writes that occur during the Azure AD B2C user journey. For example, a simple sign-in journey that reads from the directory consists of 1 request. If the sign-in journey must also update the directory, this operation is counted as an additional request.
Azure AD B2C configuration limits
The following table lists the administrative configuration limits in the Azure AD B2C service.
Category | Limit |
---|---|
Number of scopes per application | 1000 |
Number of custom attributes per user 1 | 100 |
Number of redirect URLs per application | 100 |
Number of sign out URLs per application | 1 |
String Limit per Attribute | 250 Chars |
Number of B2C tenants per subscription | 20 |
Levels of inheritance in custom policies | 10 |
Number of policies per Azure AD B2C tenant (user flows + custom policies) | 200 |
Maximum policy file size | 1024 KB |
Community site
In this site you will find custom user journeys, a demo website (which I took the last login pics from), Github repo, webinars and links to official documentations.
Ending of the post
So with Azure B2C you can deliver and excellent end-user experience with almost all the possible login identities you can imagine.
The user interface can be customized and you can create custom user flows and also the first 50.000 users are free.
You can have your custom domain example with Azure Front Door and Microsoft even provides you the certificate for the domain.
This really is an excellent product for your custom application front ends. Hopefully this post made Your understand more what Azure B2C is.
Thanks for reading!