> ...affected third-party applications which were using it and didn’t implement their own additional security measures.
Third-party applications really have no recourse but to trust the signed JWT. That is just how OAuth2/OIDC works.
User impersonation against an IdP is a serious security issue. 100k is cheap.
The bug was basically on the IdP's "consent screen". Instead of using the email from the active logged in account, it allowed the attack to POST in any email they wanted.
Obviously not having the bug would be great. Apple could do "more", and layer on more things on top of OAuth, like a proof of key extension (DPoP) on the flow: https://tools.ietf.org/html/draft-fett-oauth-dpop-04
But if you have a bug like this, where you can edit your claims arbitrarily inside the IdP, extra security layers kinda don't matter.
The relying party would have to incorrectly rely on the 'email' claim, which is not guaranteed to be sent, stable, or unique, rather than the "sub" claim as documented.
This shouldn't be an account takeover problem unless your site did that or one of a few other things wrong. However, I'd be reluctant to blame the site in those cases - a lot of security issues (including this one on Apple's side) come from two components not fully understanding the contract between them.
> I found I could request JWTs for any Email ID from Apple and when the signature of these tokens was verified using Apple’s public key, they showed as valid. This means an attacker could forge a JWT by linking any Email ID to it and gaining access to the victim’s account.
