Comment by jurgenaut23
14 hours ago
I am tempted to agree with you because I could never quite wrap up my head around it, but I never had to implement OAuth beyond a brief skim through the doc for my own understanding. I always thought this complexity was there for some good reason (security?).
OAuth first and foremost is driven by getting secret information from, let’s say, Big Company. It’s understandable that there are many steps for some random Joe to get Google emails or Facebook DMs.
OpenID piggy-backed on it by layering on new terms to an already complex scheme. The precious, secret information from Big Company in OpenID is just Email and maybe Name and Profile Picture. Then there’s a lot of ceremony for the service using OAuth to securely get that big secret (the user’s Email, which they had to supply in the first place directly to Relying Party).
OAuth is designed so that an end-user never needs to see an API key (OAuth refresh/access token) or even know what one is. When it is implemented to the spec, that happens well.
I think that most of the "just give me an API key" comments are from a <1% of end-users (developers) that know what an API key is, and are facing a broken OAuth implementation.
> and are facing a broken OAuth implementation.
Or didn't bother to read the spec to understand why it's non trivial. Things like this are complex because attacks will force it to be.
Also, the broken implementation might be an OIDC implementation that doesn't support client_credentials for example. Seen that many times and that does make it rather awkward to implement a server to server flow...
> was there for some good reason (security?).
To cover the myriad of (sometimes downright stupid) requirements that large enterprises have.
> I always thought this complexity was there for some good reason (security?).
It's just design by committee.
far from it! it was just designed by comitee who both future proofed it and made sure it worked on low powered devices from 1971.
i make a point to implement oauth from scratch, because using the overly complex libraries expose you to bugs such as attacker sending a token which the metadata just says "no encryption or signature. trust me bro", which is actually part of the spec if you combine some options.
while in the real world, if google or apple sends you a token that is not always the same signature cypher (one of a dozen by the spec) you are better of threating as malicious, because it pretty much is. a manual implementation of a token consumer is about 20 lines... including downloading the provider keys and checking it (which most startups never do! allowing anyone to just sign a token as anyone)