In Azure AD B2C you’ve two ways to provide identity UX:

• user flows - predefined, built-in, configurable policies so you can create sign-up/in and policy editing UX in minutes.
• custom policies - enable you to create your own user journeys for complex identity experience scenarios.

User Flows

For the most common identity tasks. Things like:

• Account types used for sign-in, such as social accounts or local accounts.
• Attributes to be collected from the consumer.
• MFA
• User interface customization
• Set of claims in a token your app receives

Custom Policies

They’re config files that define the behaviour of your Azure AD B2C tenant UX. They can be fully edited by an identity developer to complete many different tasks.

It’s fully configurable and policy-driven.

• Federate with other identity providers
• Third party MFA
• Collect any user input
• Integrate with external systems using REST API communication

Each user journey is defined by a policy. You can build as many or as few policies as you need.

Defined by several XML files that refer to each other in a hierarchical chain.

Starter Pack

The starter pack comes with pre-built policies.

• LocalAccounts - Enables the use of local accounts only.
• SocialAccounts - Enables the use of social (or federated) accounts only.
• SocialAndLocalAccounts - Enables the use of both local and social accounts. Most of our samples refer to this policy.
• SocialAndLocalAccountsWithMFA - Enables social, local, and multi-factor authentication options.

Each starter pack includes:

• a base file that contains most definitions. To help with troubleshooting and long-term maintenance of your policies, try to minimize the number of changes you make to this file.
• an extension file holds the unique config changes for your tenant. This file is derived from the base file. Use this to add new functionality or override existing functionality. e.g. to federate with new identity providers.
• a relying party (RP) file is the single task-focused file that’s invoked directly by the relying party application, such as web, mobile or desktop app. Each unique task such as sign-up/in, password reset etc requires its own relying party policy file. This file is derived from the extensions file. You can add more relying party policies. (e.g. delete my account, change a phone number…)

The basics

Claim

A claim provides temporary storage of data during an Azure AD B2C policy execution. It can store info about the user, such as first name, last name… or any other claim obtainer from the user or other systems. The claim schema is the place where you declare your claims.

When a policy runs, B2C sends and receives claims to and from internal and external parties, then sends a subset of these claims to your relying party app as part of the token.

• Claims are saved, read, or updated against the directory user object.
• Claims are received from an external identity provder.
• Claims are sent or received using a custom REST API service.
• Data is collected as claims from the user during sign-up or edit profile flows.

Claims transformation are predefined functions to convert a given claim into another one, evaluate a claim or set a claim value.

User Journey

They allow you to define business logic with path through which users will follow to gain access to your application. The user is taken through this journey to retrieve the claims that are to be presented to your app.

A user journey is built from a sequence of orchestration steps.

How you can add orchestration steps to social and local account starter pack.

Orchestration Steps

A user must reach the last step to acquire a token. Orchestration steps can be conditionally executed based on preconditions. After an step completes, B2C stores the outputted claims in the claims bag. This bag can be used by any further orchestration steps in the user’s journey.

Reference(s)

https://docs.microsoft.com/en-us/azure/active-directory-b2c/user-flow-overview
https://docs.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-overview

Read More

JSON Web Key (JWK) represents a set of public keys as a JSON object. This format is used to represent bare keys.

The following is a key example:

{
  "jwk": [
    {
      "alg": "EC",
      "crv": "P-256",
      "x": "{x_value}",
      "y": "{y_value}",
      "use": "enc",
      "kid": "1"
    },
    {
      "alg": "RSA",
      "mod": "{mod_value}",
      "exp": "AQAB",
      "kid": "2011-04-29"
    }
  ]
}

It’s possible to go from PEM format to JWK and from JWK to PEM.

Azure AD B2C creates and validates user flows with keys. It automatically rotates them, but they’re created as JWK and not PEM.
To validate the JWT we need to:

1. Go to the keys endpoint:
2. Copy JWK.
3. Convert to PEM.
4. Validate it with PEM public key.

As the documentation states the client needs to check periodically for new JWK keys, as they rotate them. A good period check is every 24 hours.

Reference(s)

https://openid.net/specs/draft-jones-json-web-key-03.html#anchor1
https://stackoverflow.com/questions/50816301/msal-access-token-invalid-signature
https://docs.microsoft.com/es-es/azure/active-directory-b2c/tokens-overview

Read More

Azure AD B2C is Identity as a Service. It allows you to login into apps or use Twitter, Google or other authenticators. They can sign up or sign in. OpenID, OAuth, SAML.

Customers get to use their preferred accounts to sign up or create a regular user / pwd. You can customize the login experience.

App Types

This is best for the following types:

• Server-based web apps work perfectly. They use OpenID Connect for all UX.
• Mobile apps. They use OAuth2 auth code flow.
• Web services and APIs. OAuth2.

This doesn’t work together with Azure AD B2C.

• Daemons.
• Web API chains.

Configure Azure Active Directory B2C

Create new resource -> B2C -> Create new tenant -> enter general information

Notice for the initial domain name, the full domain will be *.onmicrosoft.com

Once a tenant is provisioned, click to manage it. A new tab opens, this is because the B2C tenant is separate from your Azure subscription’s tenant. Your Azure subscription has an Azure Active Directory Tenant associated with it and this new B2C one is distinct and separate. It’s its own directory.

Inside we have the following modules or tabs:

• Applications: websites or web APIs or Apps
• Identity provider: lists all identity providers such as Facebook or Github and your users may log in through them.
• User attributes: you can see all metadata you collect from users.
• Users: you can see and edit all users who have created accounts.
• User flows: Heart and soul of Azure AD B2C as it guides users through the sign in or sign up, or password resets.
• Audit Logs: Authentication of various apps or administrative events.

Link Azure AD B2C Tenant

Before being able to use the B2C instance, you also have to link the B2C directory back to the main subscription. This makes it a service for you to use.

Create new resource -> Azure Active Directory B2C -> Create -> Link existing Azure AD B2C Tenant to my Azure subscription -> select the one you just created -> put it into a resource group

User flow

The flows are reusable. They controls when social accounts can be used to sign in.
The attributes to collect from the user. (you can collect standard or custom ones). To use MFA or not.
User interface customization. Information inside the token that’s returned from B2C. It can be used across B2C apps. They’re entirely reusable.

Azure AD B2C Application - it’s not your web or API. It’s models apps that have authentication added. It makes sure only your users can sign-in.

Redirect URI - where to redirect response after the user’s been authenticated. As a test, put https://jwt.ms to see what’s inside the JWT token.

Built-in User Flows

There’re 3 recommended to have, but you can create custom ones:

• Sign-in/up.
• Profile editing.
• Password reset.

Everything that controls the journeys of the users is located under Policies.

Social Providers

Social network provider are called identity providers (IdP). In order to use them, you have to configure them first. You will get a key which you enter into B2C and the authentication will happen seamlessly.

B2C Application Deep Dive

A B2C app models the real world. Every real-world app needs a B2C app.

reply URL: URL where responses will be returned to your webapp. App ID: unique ID that identifies your B2C app.
They obey standards like OAuth 2.0 or OpenID Connect.
When you want to interact with it, you specify your user flow.

Everything from Sign in to get Resource token happens inside Azure, not your app.

Tokens

They’re the way that B2C uses to transmit claims about a user calling Apps. They’re all JWT tokens.

ID token: contains claims user to identify user. (e.g. user’s object ID in AD). You must always validate it. Access token: Claims used to identify API permissions. Validate it. Refresh token: It should be a black box to your app. Both others tokens expire.

How server-based apps authentication works with B2C. Underlying authentication protocol is OpenID Connect.

Custom Policies

Individual steps into a user’s journey:

They’re XML files
have a Schema definition (which will be used to return the tokens)
Content definition - Things like how to render pages. Technical profiles - they’re the endpoints and how to communicate with identity providers. Orchestration - steps that are contained within the custom policies

Policy Files

In order to work with custom policies we’ll need to handle three files:

• base file - contains most definitions. make minimal changes. you shouldn’t ever have to change this file. Starting point that every B2C tenant would use. Contains the common elements for everything.
• Extensions file - unique config for tenant. Make changes here that overrides anything in the base file. These changes apply to the entire tenant.
• Relying party file - single task focused that’s invoked by app. This is the file that your app invokes. Use this file to make any final tweaks to the user’s journey.

Reference(s)

User flows and custom policies in Azure Active Directory B2C - Azure AD B2C | Microsoft Learn

Read More