|
| 1 | +# Best Practices for Use of MSAL with B2C Policies and the Identity Experience Framework |
| 2 | + |
| 3 | +## Overview |
| 4 | +The B2C Identity Experience Framework (IEF) enables a wide variety of experiences and functionalities by offering developers a high degree of policy, journey, and token response customization. |
| 5 | + |
| 6 | +To ensure compatibility with the MSAL client libraries, a core set of response tokens and claims conforming to the OAuth 2.0 and OpenID Connect specifications must be returned by your application's policies. |
| 7 | + |
| 8 | +## Token Response Properties Required by MSAL |
| 9 | +The following artifacts must be included in the response from your policy's `/token` endpoint: |
| 10 | + |
| 11 | +| Artifact | Expected Format | Description | |
| 12 | +|-------------------|------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| |
| 13 | +| `access_token` | String (JWT) | The requested access token. The app can use this token to authenticate to the secured resource, such as a web API. | |
| 14 | +| `token_type` | String | Indicates the token type such a 'Bearer'. | |
| 15 | +| `expires_in` | Numeric | How long the access token is valid (in seconds). | |
| 16 | +| `scope` | String | The scopes for which the access token is valid. | |
| 17 | +| `refresh_token` | String | An OAuth 2.0 refresh token. The app can use this token to acquire additional access tokens after the current access token expires.<br><br>Refresh tokens are long-lived and can be used to retain access to resources for extended periods of time. `offline_access` must be requested to obtain this token.<br><br>**Please Note:** Single Page Applications (SPAs) should not request `offline_access` as these apps will be issued a refresh token with a 24H validity period by default. | |
| 18 | +| `id_token` | String (JWT) | The app can decode this token to discover information about the signed-in user. The app may cache this token and use its contents for display purposes. | |
| 19 | +| `client_info` | String (base64 encoded JSON) | Automatically provided by B2C IdP. Metadata about the user and their tenant. | |
| 20 | + |
| 21 | +## ID Token Claims Required by MSAL Libraries |
| 22 | +The following ID token token claims are required when using MSAL: |
| 23 | + |
| 24 | +| Claim | Expected Format | Description | |
| 25 | +|-----------------------------------------------------------------------------------------------------------|-----------------|------------------------------------------------------------------------------------------------------------| |
| 26 | +| One or more of:<br>- `sub`<br>- `oid` | String | A locally unique identifier within the issuer for the end-user. | |
| 27 | +| One or more of:<br>- `preferred_username`<br>- `email`<br>- `emails` (Applies to MSAL-JS only)<br>- `upn` | String | If no value is returned, MSAL client libraries will use a default value: `MISSING_FROM_THE_TOKEN_RESPONSE` | |
| 28 | + |
| 29 | +## Best Practice: Include the Standard Set OpenID Connect Claims |
| 30 | +The OpenID Connect Framework (OIDC) defines a set of [standard claims](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). To ensure broad compatibility across OAuth 2.0 & OIDC libraries with your application's configured IEF policies, it is recommended that developers include the standard claim set (where possible). |
| 31 | + |
| 32 | +| Claim | Expected Format | Description | |
| 33 | +|-------------------------|-----------------|----------------------------------------------------------------------------------------------------------------------------------------------------| |
| 34 | +| `sub` | String | Subject - Identifier for the End-User at the Issuer. | |
| 35 | +| `name` | String | End-User's full name in displayable form. | |
| 36 | +| `given_name` | String | Given (first) name(s) of the End-User. | |
| 37 | +| `family_name` | String | Surname(s) (last) of the End-User. | |
| 38 | +| `middle_name` | String | Middle name(s) of the End-User. | |
| 39 | +| `nickname` | String | Casual name of the End-User | |
| 40 | +| `preferred_username` | String | Shorthand name by which the End-User wishes to be known at the RP. | |
| 41 | +| `profile` | String | URL of the End-User's profile page. | |
| 42 | +| `picture` | String | URL of the End-User's profile image; MUST refer to an image file such as PNG, JPG, or GIF. | |
| 43 | +| `website` | String | URL of End-User's web page. | |
| 44 | +| `email` | String | End-User's preferred email address. | |
| 45 | +| `email_verified` | Boolean | True if verified. The process for verification is unspecified. | |
| 46 | +| `gender` | String | End-User's gender. Values defined by the specification are `female` and `male`; other values may be used when neither defined value is applicable. | |
| 47 | +| `birthdate` | String | ISO 8601:2004 representation of the End-User's birthdate. May be 0000 to indicate omission. | |
| 48 | +| `zoneinfo` | String | String representing the End-User's timezone. | |
| 49 | +| `locale` | String | End-User's locale, represented as a BCP47 language tag. | |
| 50 | +| `phone_number` | String | End-User's preferred telephone number. Suggested format is E.164. | |
| 51 | +| `phone_number_verified` | Boolean | True if verified. The process for verification is unspecified. | |
| 52 | +| `address` | JSON Object | End-User's preferred postal address. Format is RFC-4627 conformant. | |
| 53 | +| `updated_at` | Numeric | Time the End-User's information was last updated. | |
0 commit comments