How can I get the standard OpenID connect claims when using Azure Active Directory and Azure Active Directory B2C?

Question

We are developing an ASP.NET core 2.2 web application by using IdentityServer 4 as a gateway to other identity providers following the federation gateway architecture.

The application we are developing is the actual identity provider web application which is, as explained above, just a gateway to some configured upstream identity providers.

The user basically configures his preferred upstream identity providers and our application takes care of configuring IdentityServer4 so that the configured providers are used as external identity providers for identity server itself.

The requirement for the application user is that each configured provider must be compliant with the OpenID connect protocol. Each upstream provider is in fact registered with identity server 4 by using the ASP.NET core authentication handler for OpenID connect.

During the development phase we are testing the application by using Azure active directory B2C and our company's instance of Azure Active Directory as test upstream identity providers.

We ask for 3 different scopes during the authentication: openid, profile and email.

We do so because the only user claims that we need from the external provider are sub (provided by the openid scope), given_name and family_name (provided by the profile scope) and email (provided by the email scope). Notice that the email claim is really important for us, because we want to use it as the primary key by which identifying the system users (this is relevant for the Azure Active Directory B2C issue explained below).

These are standard open id connect scopes and claims so we expected to find them easily in our test providers. Unfortunately the reality is different and neither Azure Active Directory nor Azure Active Directory B2C send all of these claims.

What we actually get are the following claims:

• sub, name and email from Azure active directory (given_name and family_name are missing)
• sub, emails, given_name and family_name from Azure active directory B2C (notice that emails is not a standard claim and from the Azure portal it is classified as StringCollection, so it seems possible to get multiple emails for a user which is not what we want).

My questions are basically the followings:

• is it possible to get the standard OpenID connect sub, email, given_name, and family_name claims from both Azure Active Directory and Azure Active Directory B2C ? Is it just a matter of configuring them properly ?
• is it possible to assume that any identity provider declaring of being compliant with OpenID connect is able to provide us with these four claims ? We would like to avoid cluttering our code base of fallback logic to handle the subtle specificity of different providers

Thanks for helping !

Answer 1

You are referring to a claims that are marked as OPTIONAL by the OpenID Connect Standard.

As far as it concerns Azure AD (not B2C), here is the doc:

• Tokens and claims in Microsoft Identity Platform (no given_name & family_name)
• Regarding given_name, family_name, email check the optional claims in Azure Active Directory doc in order to include these in your id_token.

And for B2C, hmm, there is really no documentation about that, or I am having issues finding it. This is a general B2C tokens reference doc. But just go to your user_flow and define the requested claims for the application (relying party):

There is a general challenge how you issue an e-mail claim in a B2C context. Because you may have a local user, or a social user (which includes the Azure AD user federated over B2C in your case) or even a remote user (more complex scenarios with custom flows). So you do not have really have a source of truth for the e-mail.

Given name and family name are so called self asserted - the end user provides the info and you (B2C) just save it to the profile. So your application is getting information provided by the user. It may be anything.

You are certainly able to create a custom claim and name it email instead of emails in B2C. But you have to ultimately decide which will be source for this claim. You can achieve that goal using custom flow.

I would generally also argue against e-mail being primary key or even a match for something. There are enough circumstances, especially within a corporation when an employee e-mail may and will change. And your application shall not rely on the fact that e-mail is immutable property of a user profile.

With this, I believe I answered only question one.

As for the latter:

is it possible to assume that any identity provider declaring of being compliant with OpenID connect is able to provide us with these four claims ?

Do not forget that the claims you refer to are marked OPTIONAL in the OpenID Connect specification. That means that an Identity provider does not have to implement these in order to be OpenID Connect compliant. More specifically, the documentation states:

Claims requested by the following scopes are treated by Authorization Servers as Voluntary Claims.

But yes - Azure Active Directory provides all of them - with the configuration for the optional claims. And B2C also provides them - with more complex workaround for the email claim.