Tl;dr

I will show you typical CIAM challenges, scenarios, diagrams, and links to the repositories with the implementation of the new Azure Service—Entra External ID for Customers (CIAM).

Big Picture

Big Picture

Link to bigger picture.

Introduction

Entra External ID for Customers is a new Azure Tenant type that allows you to create digital identities for your customers. It is a separate tenant type, not connected with your organisation’s tenant.

I want to show you typical CIAM challenges with the diagram (big picture). We will go through the diagram step by step, and I will show you possible solutions.

Technical details

Microsoft is adding new features to the Entra External ID service quarter by quarter (like Native Authentication is Globally Available now). Please check the official documentation for the most up-to-date information: https://learn.microsoft.com/en-us/entra/external-id/customers/concept-supported-features-customers

I’m waiting for the Verified ID authentication method and passkey support, and you?

Below, you can find a list of available features and links to the GitHub repositories with the implementation for the elements from the diagram that should help you build the CIAM system.

Authentication methods

  • Email with password
  • Email one-time passcode

MFA

  • Email one-time passcode
  • SMS-based authentication

Business Case

Easy access to web & mobile applications

You can provide easy access to your services with an email address and OTP (one-time passcode - so code shared to your mailbox).

Pros
  • Passwordless.
  • Easy to use with Native Authentication - so mobile application without web redirection (keep the user in the app) - check my blog post and demo here.
Cons
  • We don’t know about email security level(MFA, password complexity, etc.).
  • Each sign-in session requires a new OTP code and email access.
  • Email messages can be shared between users.
Technical details (for Android)

Additional OpenID Connect and OAuth2 flows

You have many options to enable authentication for your application or applications. The Entra External ID for Customers supports the following flows:

  • OpenID Connect
  • Authorisation code (and with PKCE)
  • Client credentials (Preview)
  • Device authorisation (Preview)
  • On-Behalf-Of flow
  • Implicit grant
  • there is no ROPC (Resource Owner Password Credentials)

Complete MS documentation: https://learn.microsoft.com/en-us/entra/external-id/customers/concept-supported-features-customers#openid-connect-and-oauth2-flows

Business Case

Service to Service authentication (M2M)

With the Client credentials flow, you can provide service-to-service authentication. For example, you can use it to authenticate your API to an external service. It is easy to set up and cheap to run, providing secure communication between services without additional cost.

Please remember that everything depends on your business case. A possible alternative is, for example, an API Management service that can also be protected with an OAuth2 token.

SCIM provisioning

user-provisioning

SCIM provisioning is a standard for user provisioning. It is widely used in the industry to automate the user provisioning process.

Microsoft provides a repository for SCIM provisioning samples. The repository is available at https://github.com/AzureAD/SCIMReferenceCode

The code can be your starting point for the implementation of your project.

Group provisioning & exposing as claims

group-provisioning We can extend the basic SCIM provisioning with groups.

Business Cases

Simple authorisation cases with groups

With groups, you can provide simple authorisation cases. For example, you can define a group as a specific role and assign this group to the user. In the token, you will expose the group identifiers in one claim (default behaviour) and use it in your application to provide access to specific resources.

Profile Edit

profile-edit

In the Entra External ID for Customers, we should define a dedicated web application (Frontend + Backend) to manage the user profile.

Business Cases

Confident platform served by your business domain

The recommendation is to use a custom domain to improve the confidentiality and integrity of the systems. In the case of the custom domain, you can use Azure FrontDoor to improve the user experience by adding your domain in front of the Identity Provider. So you don’t need to use a default Microsoft domain *.ciamlogin.com (or with Azure AD B2C *.b2c.login.com), but you can use your custom domain like id.your-business-domain.com. In addition, in the context of security (zero trust and lading zones), the recommendation is to use the following services: Azure FrontDoor as a WAF to expose services (user profile, branding files).

The proposed solution is to define:

  • id.factorlabs.pl (in schema id.your-business-domain.domain as name of the service for Identity Provider) and your business domain.
  • profile.factorlabs.pl (in schema profile.your-business-domain.domain as name of the service for Profile Edit Service) and your business domain, next option is user.factorlabs.pl.
  • store.factorlabs.pl as your business example for store; maybe you have only one service, so you can use the root domain for your business, or maybe you have more applications - we can adapt to your needs.

Technical details

Best and continuously updated by Microsoft repository https://github.com/microsoft/woodgrove-groceries with live demo https://woodgrovedemo.com/ with the profile edit implementation.

Fetch the user profile: https://github.com/microsoft/woodgrove-groceries/blob/main/Controllers/UserAttributesController.cs#L47 Update the user profile: https://github.com/microsoft/woodgrove-groceries/blob/main/Controllers/UserAttributesController.cs#L113

Token enrichment

token-enrichment

Token enrichment is a feature that allows you to add additional claims to the token. The dedicated token enrichment flow from the diagram is described with 6-8 points.

Business Cases

Advanced authorisation cases custom claims

When you expect advanced authorisation cases, maybe Fain-Grained Authorization, you can use the token enrichment to add additional claims to the token from a dedicated service.

Technical details

Documentation: https://learn.microsoft.com/en-us/entra/identity-platform/custom-extension-tokenissuancestart-configuration Repository: https://github.com/microsoft/woodgrove-auth-api The code to add additional claims to the token is available at: https://github.com/microsoft/woodgrove-auth-api/blob/main/Controllers/OnTokenIssuanceStartController.cs

Conclusion

The diagram and the links to the repositories with the implementation will help you build the CIAM system or systems. Please keep your fingers crossed for the next Entra External ID feature release.