if I understand correctly, the token request accepted an alternative email claim value and used it to override the value on Apple’s IDP. Really?

If I'm reading it right it's not the token endpoint, it's their internal API for accepting the request that let the user choose which email to share with the app. So it's a form validation problem.

But it’s exposed to the client and did accept arbitrary values, right?

Yea, it's just not part of the OAuth API. It's more like bad logic on the internal implementation of the AS.

Seen similar issues with SAML in the past. SP correctly verified the assertion, then redirected the user to the real app path with his email address as (exchangeable) parameter. On IdP/AS side it’s of course even more severe...

I feel logical bugs around OAuth/OIDC/JWT handling are on the rise - and they are like the login form SQL injections of the past („be whoever you want to be“). Love those standards and their capabilities - but are they getting too complicated?

Nah this is more a demonstration of why sticking to standards is a good idea, and why building an authorization server isn't a project that should be taken lightly.

I don’t see how this is related to the OIDC protocol flow. Can you please elaborate?

Sorry, the Apple vulnerability is not. It’s just my feeling that higher likelihood of logical bugs due to high complexity may also apply to OIDC (in combination with OAuth).

"The OpenID Foundation enables deployments of OpenID Connect and the Financial-grade API (FAPI) Read/Write Profile to be certified to specific conformance profiles to promote interoperability among implementations.... " openid.net/certification/