Comment by krooj
1 year ago
I feel as though this is a consequence of organizations not really understanding how complex the space truly is. The way I've watched OAuth2 + OIDC get adopted in various companies was never from a security-first perspective; rather, it's always sold as a "feature": login with x, etc. Even when there are moves to make flows more secure - PKCE, for example - you end up playing a game of "whack-a-mole" with various platforms doing shitty things in terms of cookie sharing, redirect handling, and the like. The fundamentals of 3-legged OAuth2 are sound and there's tons of prior art (CAS comes to mind), but the OpenID Foundation should be tarred and feathered for the shitty way they market and sold OIDC.
OpenID Connect and all its extensions are so high in complexity and scope. The documents themselves are massive and written in a quite hard to understand form. I've implemented many protocols and RFCs so I feel I have some experience.
Because OpenID Connect and OAuth2 are so closely related, I worry that some of this overengineering is making it's way back into new OAuth2 extensions.
I'm worried both will eventually collapse under their own weight, creating a market for a new, simpler incumbent and setting us back another 10 years as all this has to get reinvented again.
My outside impression is that the OIDC folks are highly productive with really strong domain knowledge and experience, but they're not strong communicators or shepherds with a strong enough vision.
The sad thing is that this is the second thing with the OpenID name that's going down this path. The original OpenID concept was great but also collapsed due to their over-engineering.
Agree - you only need to look at things like the hybrid flows to see where things fall apart: why would you issue an id_token that contains user information to a client which hasn't yet fully authenticated itself via a code-to-token exchange with passing it's client_id + secret? If you look at certain implementations, such as Auth0, you'll find that they actually POST that token back at the redirect_uri, since, a) it's at least registered against the client; b) it's not subject to capture as easily. The spec says NOTHING about protecting this info, though.