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?
2
1
1
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.
1
But it’s exposed to the client and did accept arbitrary values, right?
2
Yea, it's just not part of the OAuth API. It's more like bad logic on the internal implementation of the AS.
2
1
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...
1
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?
2
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.

May 31, 2020 · 12:59 PM UTC

2
1
Fully agree to that 😀 Just looking also at examples like insomniasec.com/blog/auth0-j… or threatpost.com/microsoft-oau…. o/c they are different + very individual, but if already the big players have such issues, how much more can go wrong on RS side where devs are usually not Auth experts.
2
1
Yes! And that is *exactly* why I always advocate for pushing the complexity to the authorization server and keeping the client side simple. Fewer options for clients means fewer ways to mess it up, and there will always be more client developers than AS developers.
2
I don’t see how this is related to the OIDC protocol flow. Can you please elaborate?
1
1