[Ronnie76er]

Just want to mention something about the id_token provided. I'm on my phone, so I don't have apples implementation handy, but in OIDC, the relying party (Spotify for example) is supposed to use the id_token to verify the user that is authenticated, specifically the sub claim in the jwt id_token.

https://openid.net/specs/openid-connect-core-1_0-final.html#...

It's likely (although like others have noted, this is scant on details), that this value was correct and represented the authenticated user.

A relying party should not use the email value to authenticate the user.

Not contesting that this is a bug that should be fixed and a potential security issue, but perhaps not as bad.

Anyone else? Am I reading this right?

[m_herrlich]

The apple endpoint returned an apple-signed jwt with an email of the attacker's choice in the sub field. It didn't even have to be an email associated with an apple id. Relying parties verify the id_token against Apple's cert and that is Apple's guarantee that the email is correct.

[dwaite]

the sub field does not contain an email address in SiwA.

[cfors]

So the way I believe that it works is that the vulnerability was that a valid email is used to generate an Apple signed JWT. The server side validation would be unable to tell that the token wasn’t issued in behalf of the user since Apple actually signed it.

[dwaite]

the SiwA identification is based on "sub", email address is an important address but you aren't supposed to link accounts based on it since the user can change the email address or revoke email proxy at any time.

[homakov]

true, email shouldnt be used when you can identify by unique id. I doubt the bug was even exploitable with most apps. Apple just paid magnitudes more than its severity.