No Map Inside

I have almost never talked about OIDC in a technical interview.

There is plenty I want to ask. What is the difference between state and nonce. What problem does PKCE solve. When do you choose opaque tokens over JWTs. Which scales better in a large system. Explain back-channel logout. But I already know most candidates cannot answer, and the moment someone writes "felt like a pressure interview" in feedback, it stings. So I do not ask.

OIDC is hard. It is a prefab bolted onto OAuth, specs stitched together from different eras. OAuth 2.0, OpenID Connect Core, Discovery, Dynamic Registration. Where OAuth ends and OIDC begins is blurry. What makes it worse is each provider's implementation. Google, who wrote the spec while running, and Apple, who ignores it entirely. You read the RFC and it does not match what the provider actually does. You lose track of where the truth lives.

Without having implemented it yourself, you cannot even grasp why OAuth requires client registration. What client credentials are. How an ID token differs from an access token. Why refresh tokens exist. What API scopes mean. If you have never implemented the authorization code flow yourself, you cannot picture what happens in the redirect round-trip.

I gently tell junior engineers to study it. None of them look interested. I get it. Too many moving parts, too abstract, no visible artifact. It just works until it breaks, and when it breaks, everything burns. The risk-to-reward ratio looks terrible from the outside.

But as long as you build anything on the web, you cannot escape authentication. Someday you will have to walk through that prefab. Better to carry a map before you get lost inside.