WeChat ID
aaronpk_tv
-
Vinod Anandan
https://twitter.com/_VinodAnandan
•
May 31
Yes, thank you. I agree that RP should be simple and IdP should be handling the complexity. AFAIU, the OIDC spec is clear about the email_verified attribute.
The original post didn’t make this clear, so I’m writing a new post to hopefully better explain the problem. You’ll see that it has nothing to do with OIDC at all. Link coming shortly, I hope. -
Vinod Anandan
https://twitter.com/_VinodAnandan
•
May 31
My point is that OIDC has mechanisms to prevent this issue..
Please go read it again and understand the problem
-
Vinod Anandan
https://twitter.com/_VinodAnandan
•
May 31
"email_verified" : "True if the End-User's e-mail address has been verified; otherwise false....."
https://openid.net/specs/openid-connect-core-1_0.html
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. -
Vinod Anandan
https://twitter.com/_VinodAnandan
•
May 31
"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.... "
https://openid.net/certification/
And? certification wouldn't have caught this bug since it wasn't a problem with the OIDC part of the exchange. -
Fully agree to that 😀
Just looking also at examples like https://insomniasec.com/blog/auth0-jwt-validation-bypass or https://threatpost.com/microsoft-oauth-flaw-azure-takeover/150737/.
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. -
Barbara Schachner
https://twitter.com/barschachner
•
May 31
Fully agree to that 😀
Just looking also at examples like https://insomniasec.com/blog/auth0-jwt-validation-bypass or https://threatpost.com/microsoft-oauth-flaw-azure-takeover/150737/.
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.
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. -
Arif Yayalar 💛❤️🦁
https://twitter.com/ayayalar
•
May 30
@aaronpk little disappointed that you sell pdf/ePub editions of OAuth 2.0 Simplified separately.
Yeah it's mainly a technical limitation of the platform we used for publishing it. If you send me a receipt, I'll send you the other format! -
Barbara Schachner
https://twitter.com/barschachner
•
May 31
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. -
Aaron Parecki
https://aaronparecki.com/
•
May 31
It's the handler that responds to the "Continue" form post on this screen. Instead of a Boolean, the client sent back the actual email address and the server accepted arbitrary values.
Now that I'm writing this out, I realize that the client also sends back the "name" here, intentionally, since the name is user-editable. So I can see how this happened. It's just extremely poor coding practice to essentially also allow the email to be editable here. -
Torsten Lodderstedt
https://twitter.com/tlodderstedt
•
May 31
But it’s exposed to the client and did accept arbitrary values, right?
It's the handler that responds to the "Continue" form post on this screen. Instead of a Boolean, the client sent back the actual email address and the server accepted arbitrary values.
-
Torsten Lodderstedt
https://twitter.com/tlodderstedt
•
May 31
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.
-
Torsten Lodderstedt
https://twitter.com/tlodderstedt
•
May 31
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.
-
Josh Long (龙之春, जोश, Джош Лонг, جوش لونق)
https://twitter.com/starbuxman
•
May 31
2020 has been a bumpy ride over here in America.
* a global pandemic killing 100,000+ Americans? Check.
* race-wars spilling into the streets? Check.
And it's not even June.
Don't worry, there's still time for the earthquake -
All we need is the big earthquake to really round out 2020
-
Adam Avenir
https://twitter.com/adamavenir
•
May 31
Still *somehow* I’m hopeful that the 2030s will be better than we can ever imagine them right now. Lots of pain between now and then and lots more work to be done.
