Aaron Parecki

Technology is about revolting against your fathers data description language.

It's almost like they learned nothing from the mess of XML-based protocols

And so did Verified / Verifiable Credentials specs. ** sigh **

Isn’t CBOR putting it back?

Well, after 18 years, XML DSig libs still exhibited critical normalization bugs last year. It has been continuing and I expect it to continue. That's why we removed any and all normalization from JWS. That was one of the first decision I and @ve7jtb made. Just a data point.

No, just SAML and wouldn’t call it less complicated, just maybe so obviously complicated that only few tried to do the XML handling themselves and rather used proper libs😀 Really don’t want to criticize anyone.I have high respect for everyone inventing/maintaining such standards

High complexity means? Are you aware of solutions for Id federation that are simpler to use and secure?

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).

I think the complexity comes with all the different options you have (eg grant types and self-encoded vs reference tokens, etc) and the number of tokens/secrets/codes involved. Not sure if every average pentester could find critical logical bugs in the flows.

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.

Of course, usage of standard libs should help. Just not sure how widespread they are compared to individual implementations in that area.

Fully agree to that 😀 Just looking also at examples like insomniasec.com/blog/auth0-jwt… or threatpost.com/microsoft-oaut…. 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.

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

The protocols are not the most complicated typically (not saying they are ‘easy’ either). But business requirements on top make things 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 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?

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...

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.

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.

I see. Thanks for the clarification.

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

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