Entra External ID: Sign in with Apple does not pre-fill first and last name, but Google and Facebook do

Question

Entra External ID: Sign in with Apple does not pre-fill first and last name, but Google and Facebook do

Oleh Mryhlod 0

In an external tenant, we use the built-in Apple, Google and Facebook identity providers in one sign-up and sign-in user flow. The flow collects Given Name and Surname.

Google and Facebook sign-ups pre-fill Given Name and Surname on the sign-up page. Apple sign-ups show these fields empty, and the new user has no given name and no surname.

We recorded the Apple flow with browser developer tools, with an Apple ID that never signed in to the app:

Entra redirects to https://appleid.apple.com/auth/authorize with scope=openid email name and response_mode=form_post.
Apple shows the name-sharing screen, and the user shares the name.
Apple sends a form POST to https://<tenant>.ciamlogin.com/<tenant-id>/federation/oauth2 with the fields state, code and user. The user field contains {"name":{"firstName":"…","lastName":"…"},"email":"…"}.
The sign-up page shows empty Given Name and Surname fields.

Apple sends the name only in the user form field, and only on the first authorization. The Apple ID token does not contain the name. Azure AD B2C custom policies can read this field with ReadBodyClaimsOnIdpRedirect (user.name.firstName user.name.lastName), but we found no equivalent setting for the External ID built-in Apple provider.

Questions:

Does the built-in Apple identity provider in External ID support the name from Apple's user field?
If it does, how do we enable it?
If it does not, is this a known limitation, and is a fix planned?

SHOUMIK CHAKRAVARTY 1,320 Reputation points

2026-10-30T00:07:42.0366667+00:00

Hi @Oleh Mryhlod - welcome to the Microsoft Azure QnA.

1. Does the built-in Apple provider support the name from Apple’s user field?

Not as far as the documentation shows. Apple’s name never reaches the extension that could prefill those fields.

Look at what the OnAttributeCollectionStart payload actually contains. userSignUpInfo.attributes has only the attributes your user flow collects. userSignUpInfo.identities has only signInType, issuer and issuerAssignedId. Nothing in it carries the identity provider’s response body, and the page says “Your REST API can’t add new attributes.”

So the extension knows who signed in. It does not know their name.

2. If it does, how do we enable it?

There is nothing to turn on. setPrefillValues can fill those fields, but you have to hand it the value, and on a first Apple sign-up you do not have one.

3. Is this a known limitation, and is a fix planned?

Nothing records it as a known limitation. The Apple federation article is setup steps only, with nothing about claims or attribute mapping. So this is what I found by checking. I am a volunteer here, so I cannot say whether a fix is planned.

What I would do now

Apple sends the name once, on the first authorization, so anyone who has already signed up will never send it again. A fix would only help new users, and waiting adds to the ones you cannot recover. Collect the name on the attribute collection page you already have.

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.
Oleh Mryhlod 0 Reputation points

2026-10-30T08:54:41.0133333+00:00
@SHOUMIK CHAKRAVARTY Thank you for checking this. Your answer confirms that a custom extension can't help, because the OnAttributeCollectionStart payload doesn't carry Apple's user field.

To be clear about what we need: we know Apple sends the name only on the first authorization. For us, that is the sign-up, which is exactly where we need the name. The problem is the sign-up experience:

The user selects Sign in with Apple.

Apple shows its sharing screen. The user can change their name there and choose to share or hide their email.

The next screen is the Entra attribute collection page. It shows empty Given Name and Surname fields and asks the user to type the name again.

So we ask the user for their name twice, one screen after the other. This is a bad experience. It is also an App Store review risk, because Apple rejects apps that ask for a name that Sign in with Apple already gives. Google and Facebook in the same user flow pre-fill these fields, so the gap is only in the Apple provider.

What we need is for the built-in Apple identity provider to map user.name.firstName and user.name.lastName from Apple's form post to Given Name and Surname on sign-up. Azure AD B2C custom policies can already do this with ReadBodyClaimsOnIdpRedirect.

We want to keep this question open until Microsoft confirms whether this is a known limitation and whether a fix is planned.
SHOUMIK CHAKRAVARTY 1,320 Reputation points

2026-10-30T15:46:58.5833333+00:00

Hello @Oleh Mryhlod Good point on the App Store risk. It does rule out collecting the name on the page, so please ignore that suggestion in my answer.

Keeping the question open makes sense to me. This one needs someone from the product side to answer it. I will also raise it in our internal channel.

Your answer

SHOUMIK CHAKRAVARTY 1,320 Reputation points

2026-10-30T00:07:42.0366667+00:00

Hi @Oleh Mryhlod - welcome to the Microsoft Azure QnA.

1. Does the built-in Apple provider support the name from Apple’s user field?

Not as far as the documentation shows. Apple’s name never reaches the extension that could prefill those fields.

Look at what the OnAttributeCollectionStart payload actually contains. userSignUpInfo.attributes has only the attributes your user flow collects. userSignUpInfo.identities has only signInType, issuer and issuerAssignedId. Nothing in it carries the identity provider’s response body, and the page says “Your REST API can’t add new attributes.”

So the extension knows who signed in. It does not know their name.

2. If it does, how do we enable it?

There is nothing to turn on. setPrefillValues can fill those fields, but you have to hand it the value, and on a first Apple sign-up you do not have one.

3. Is this a known limitation, and is a fix planned?

Nothing records it as a known limitation. The Apple federation article is setup steps only, with nothing about claims or attribute mapping. So this is what I found by checking. I am a volunteer here, so I cannot say whether a fix is planned.

What I would do now

Apple sends the name once, on the first authorization, so anyone who has already signed up will never send it again. A fix would only help new users, and waiting adds to the ones you cannot recover. Collect the name on the attribute collection page you already have.

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.
Oleh Mryhlod 0 Reputation points

2026-10-30T08:54:41.0133333+00:00

@SHOUMIK CHAKRAVARTY Thank you for checking this. Your answer confirms that a custom extension can't help, because the OnAttributeCollectionStart payload doesn't carry Apple's user field.

To be clear about what we need: we know Apple sends the name only on the first authorization. For us, that is the sign-up, which is exactly where we need the name. The problem is the sign-up experience:

The user selects Sign in with Apple.

Apple shows its sharing screen. The user can change their name there and choose to share or hide their email.

The next screen is the Entra attribute collection page. It shows empty Given Name and Surname fields and asks the user to type the name again.

So we ask the user for their name twice, one screen after the other. This is a bad experience. It is also an App Store review risk, because Apple rejects apps that ask for a name that Sign in with Apple already gives. Google and Facebook in the same user flow pre-fill these fields, so the gap is only in the Apple provider.

What we need is for the built-in Apple identity provider to map user.name.firstName and user.name.lastName from Apple's form post to Given Name and Surname on sign-up. Azure AD B2C custom policies can already do this with ReadBodyClaimsOnIdpRedirect.

We want to keep this question open until Microsoft confirms whether this is a known limitation and whether a fix is planned.
SHOUMIK CHAKRAVARTY 1,320 Reputation points

2026-10-30T15:46:58.5833333+00:00

Hello @Oleh Mryhlod Good point on the App Store risk. It does rule out collecting the name on the page, so please ignore that suggestion in my answer.

Keeping the question open makes sense to me. This one needs someone from the product side to answer it. I will also raise it in our internal channel.