Bump AspNet.Security.OAuth.Apple to 6.0.10

[martincostello]

Resolves GHSA-3893-h8qg-6h5f.

I found this repository through our dependency graph:

[dansiegel]

Thanks for bringing this to my attention. Before I can merge this though I need to know if you've tested this and the Email, Given Name and Surname are still coming through as expected. In reading the thread it appears that the email may still be coming through but the given name/surname do not which means we would need to try to fetch these from Apple.

[martincostello]

The email does, the first and surnames do not. It was tested before release with my sample integration that runs in Azure (here).

I am not aware of a way to get them from Apple server-side, other than in the way that lead them to be vulnerable to be spoofed (which is why we moved that functionality, to err on the side of caution).

If you are aware of a way to do it (the Apple documentation isn't the best) after the first request that doesn't require the callback dance which a user could tamper with, then we can restore the functionality.

[dansiegel]

Sorry haven't had my coffee yet. Realized after I replied that you are a maintainer for the library. While I would like to take the update, the current version would lead to breaking behavior which I prefer not to have. I would imagine that there has to be a some sort of /me endpoint in Apple's API that would allow you to retrieve these claims?

[martincostello]

Not that I'm aware of (like I said, Apple's documentation isn't the best), otherwise we'd have switched over to it to do exactly that. The name is only received via the user parameter when Apple calls back:

• https://developer.apple.com/forums/thread/118209?answerId=369674022#369674022
• https://developer.apple.com/forums/thread/118209?answerId=377169022#377169022
• https://developer.apple.com/forums/thread/118209?answerId=724092022#724092022

The ID token received during the OAuth dance doesn't include any name-related claims. If you log into the sample site I linked to above, it will print all of the claims to the screen once you're logged in.

[dansiegel]

As I've looked more at this it seems that when you pass the scopes to get the email and name they are included as part of the response but not part of the token. Please correct me if I'm wrong.

Fundamentally I understand but wholly disagree with the argument that the user object cannot be trusted when the id_token contains a valid signed token. I would consider this to be part of a trusted response, particularly if the email claim in the id_token matches the email in the user response.

I believe perhaps a good compromise here would be if the options for AspNet.Security.OAuth.Apple include a boolean that lets us decide whether or not to include the unsigned User Claims.

[martincostello]

@kevinchalet Thoughts on the above?

[kevinchalet]

Fundamentally I understand but wholly disagree with the argument that the user object cannot be trusted when the id_token contains a valid signed token. I would consider this to be part of a trusted response, particularly if the email claim in the id_token matches the email in the user response.

The non-standard user parameter is an authorization response parameter which is returned alongside code and state to the redirection endpoint of the client. Since it's not signed nor HMACed, there's nothing preventing a malicious user from intercepting the request (as the attack takes places on the attacker's machine) and tampering with the values contained in the user JSON object before sending the authorization response to the client's redirection response.

The fact a valid id_token will be returned during the second phase (i.e the token request/response) doesn't protect you against this attack (one way to have prevented that could have consisted in returning an user_hash claim containing the hash of the expected user parameter, just like what we have with c_hash and at_hash in the hybrid flow).

You could certainly compare the email returned in that user parameter and the one returned as part of the id_token but it would be totally pointless:

• The email returned in the identity token is guaranteed to be issued by Apple, why would you look elsewhere for the same value?
• It wouldn't solve the problem affecting the family/given name.

I believe perhaps a good compromise here would be if the options for AspNet.Security.OAuth.Apple include a boolean that lets us decide whether or not to include the unsigned User Claims.

It's something that was suggested but I was personally against it as it would encourage bad practice. If you're fine with accepting an untrusted name, then you can just ask the user for their name once the login dance is complete.

[martincostello]

Closing as there doesn't seem to be a desire to take this change.

[dansiegel]

@martincostello actually I missed that there was an updated message, but either way I do not like breaking changes. What your update does is breaking. Any change should provide the ability to continue to get those claims. To have merged your PR would create an undesirable effect for my library.