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/

And? certification wouldn't have caught this bug since it wasn't a problem with the OIDC part of the exchange.

"email_verified" : "True if the End-User's e-mail address has been verified; otherwise false....." openid.net/specs/openid-conn…

Go read the writeup again. The original post wasn't the clearest explanation of the problem but I also posted some more details in this thread that make it clearer.

My point is that OIDC has mechanisms to prevent this issue..