Learn Authentication the Hard Way: Part Three | Hacker News Reader

Learn Authentication the Hard Way: Part Three

andrew-best.com

321 pointsmariuz14 comments

I am currently an IAM engineer and can I just throw out there how much I hate OAuth/OIDC, I work at a large org and have to integrate with dozens of different vendors and applications and not a single one has the same way of doing OAuth because to quote the spec, wait it isn't a spec it is a "framework" we have to remember that, under interoperability it says

> OAuth 2.0 provides a rich authorization framework with well-defined security properties. However, as a rich and highly extensible framework with many optional components, on its own, this specification is likely to produce a wide range of non-interoperable implementations.

Don't get me wrong, OAuth is still better than WS-Fed and what we had before but we really need to come up with a real standard and spec for authentication, because OAuth/OIDC is a joke. It isn't just me either that thinks this one of the authors of the OAuth spec said as much[1]

Can anyone tell me what their experience with OAuth has been, or have they been able to get it to work across multiple different systems. I would love to believe it is just my org, but it seems like the entire identity space is a clusterfck.

[1] https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45...

We implemented OAuth about a year ago with Okta, and it's been an absolute nightmare. We have a couple of clients that have their own IDP, and they want us to let them use SAML to authenticate. I can't figure out whether the difficulties are inherent to SAML itself or because of Okta, but I hate it either way.

SAML is its own nightmare on top of the OAuth/OIDC mess. You're probably in the worst of all worlds right now.

SAML2 is kind of hairy, technically, but--speaking as someone who used to do this full-time up until six years ago and has stepped into other sings since--most of the pain was from half-baked implementations and utter crap-tier error/exception reporting. Like, on one hand you'd be plagued by a lot of small-time implementations that had a very inadequate appreciation of the spec, and/or only supported about 10% of it, or had fatal flaws in their naive handling of XML or even worse fatal flaws related to XML-DSIG and canonicalization... and on the other hand you'd get these monstrous enterprise products that specialized in offering only the most oblique of views into their inner configuration or error states. It really takes a lot of patience and expert level skills in 5-6 different things to cut to the heart of most practical issues in the space.

I work in the space, and your experience is accurate to mine as well.

I think it's important to keep in mind that the hard part of OAuth/OIDC has nothing to do with the core federated authentication flow. The complexity comes from several other known hard problems: federated trust, AKA how do you on-board federated trust between business entities using short-lived, easily rotated certificates? And federated authorization, AKA how do you codify the taxonomies of user roles and application permissions as an API contract between diverse businesses and apps? Both are known hard problems.

The oft-linked Eran Hammer blog post isn't too relevant here, even if its critiques of OAuth2 are valid from the perspective of OAuth1. Really, they're fundamentally different protocols with different goals, and after all that drift in the working group, not changing the name and pretending it's an increment of version was bad form.

Nonetheless, OAuth2 just defines the roles of the players in a situation where an application wants to act on behalf of the user, and defines a few useful interactions between them.

OIDC then layers on top of OAuth2, by defining custom payloads that communicate authentication requests and responses. It does so by relying heavily on the JOSE specs. The end result of all this layering is a protocol that's conceptually similar to SAML, despite looking and feeling rather different. Meanwhile, all the truly hard stuff, like Discovery and Federation, are additional specs alongside. They see much less use.

There's sometimes bad implementations, and there's sometimes authorization flows that aren't actually OAuth2 but merely "OAuth2-inspired". In these, and in transmitted payloads, gratuitous differences from vendor to vendor are irksome.

The same stuff happens in SAML-land too. There are products big and small, IdPs and SPs, that don't actually comply with the protocol. Sometimes the product is fine in theory, but it's misused or misconfigured. Sometimes the IdP product is big enough that they have little incentive to improve, and sometimes the SP is desirable enough that you're being pressured by your employer to integrate with them regardless of any protocol shenanigans.

I'm not sure what your exact use case is, but if you need to connect to oauth-based APIs have you tried https://pipedream.com? It's a free developer tool that provides managed auth (including oauth token generation and refresh) for 100+ apps with an easy way to orchestrate those APIs in Node.js workflows. I wrote a short blog post at https://dev.to/pipedream/use-any-api-in-seconds-with-auth-ma.... I hope that's helpful!

Imagine trying to convince management to use a tool named Pipedream, sheesh, couldn’t think of a worse name.

I always liked telling mgmt about our product's use of FckEditor.

If you find yourself in a company where management cares about the name of a tool developers are using to get the job done, I strongly encourage you to find a better gig.

Yeah, on second thought, I agree with you, but now I can’t remember what Pipedream is even used for, so I guess that’s a different complaint I have about it. But most software doesn’t have a name that indicates exactly what it is, anyways, maybe it doesn’t matter. Sometimes they indicate (Word, Photoshop, GarageBand, Internet Explorer), sometimes they don’t (kubernetes, Logic, Chrome).

I appreciate the feedback! Luckily, that hasn’t been an issue and our users tell us they love the name :) Based on my experience, if management is focused on driving business value, then the name of a product or service isn’t really a factor. What matters is the value their teams and business get. And that’s what we’re focused on delivering to our users.

in the .net world I use IdentitySever 4 and have connected various other things into that environment without too much trouble. But the lingo/jargon of the identity world felt like a bit of a brick wall when trying to work out how things work. There's still a bunch of stuff I really am quite fuzzy on. There's a bit of massaging in the middleware that I need to do to get things to work nicely. But at least having ID4 as a isolation layer helps. Was very tedious.

Keep an eye on https://openid.net/wg/fastfed/

> it seems like the entire identity space is a clusterfck

Yeah, especially server identity in a many-service world.

Reply on news.ycombinator.com