Neither first name nor last name populated in claims principle by Apple provider

[asos-tomtroughton]

Describe the bug

I've created this as a bug report initially but my assumption is that the scenario I'm describing must be by design or it would have been detected earlier. It concerns the Apple provider. We have found that even when the Apple callback includes first name and last name, these are not added to the claims principle in the authentication ticket.

Steps To reproduce

From looking at AppleAuthenticationOptions I see "name" is one of the default scopes. Without changing these scopes, in our tests we can observe the callback from Apple to contain the following URL-encoded form parameters:

• state
• code
• firstName
• lastName
• email

The name parameters have the expected values (the name from the Apple account), although obviously here they're part of the Apple URL-encoded form callback rather than the token returned by the subsequent code exchange. But this at least confirms that Apple isn't withholding these data on the user's behalf.

Expected behaviour

Upon inspecting the authentication ticket created by this Apple middleware we expect to see first name and last name represented by claims, given that "name" was one of the requested scopes.

Actual behaviour

The claims collection contains email but not either of the name claims.

System information

• Library Version: 8.1.0
• .NET version: 8.0.7

[kevinchalet]

Upon inspecting the authentication ticket created by this Apple middleware we expect to see first name and last name represented by claims, given that "name" was one of the requested scopes.

We deliberately stopped extracting these unsafe claims for the reasons explained here: https://github.com/aspnet-contrib/AspNet.Security.OAuth.Providers/security/advisories/GHSA-3893-h8qg-6h5f

More information here: https://github.com/aspnet-contrib/AspNet.Security.OAuth.Providers/issues/713#issuecomment-1232698064

[asos-tomtroughton]

Thank you for confirming. Are you aware of any work-around or is it a simple fact that a user's name is unavailable to OAuth implementations that use Apple until Apple themselves address this vulnerability? I'm surprised they don't return these claims in the signed token issued by the code exchange...

[martincostello]

The values are available, but only the first time the user goes through the OAuth flow for a given application, it's just we no longer expose them because they could be spoofed.

If Apple made the values more securely available (i.e. in the JWT), we would consider adding them back.

Otherwise you'd need to write some custom code to get the values and take your own considered risk assessment with regards to the spoofing potential based on what you intend to do with the values doing so would present.

Unless of course Apple have already made such changes, and we're just not aware of them, so haven't done anything to use them.

[kevinchalet]

Thank you for confirming. Are you aware of any work-around?

I'm not aware of any workaround, sadly (except either extracting the unsafe parameters manually or just asking the user what name they'd like to use).

The proper fix - returning the user details in the identity token, as you mentioned - must come from Apple itself.

I'm surprised they don't return these claims in the signed token issued by the code exchange...

Honestly, their implementation is quite terrible and has very annoying non-standard aspects (e.g their discovery document is incomplete, requesting the name or email scopes forces you to use response_mode=form_post and they require some sorcery for generating a client_secret based on a private key... which makes no sense since we already have a standard method for that in OpenID Connect: private_key_jwt)

[asos-tomtroughton]

Very useful context. Many thanks for your help.