Comment by Zetice | Hacker News Reader

Comment by Zetice | Hacker News Reader

Parent Full thread

As someone who's had to implement these things for our B2B SaaS, I will say it's been a lot less clear how to be as minimally innovative as possible when trying to weave in AuthZ into our product than it is to avoid innovation in something like IaC or CI/CD.

Everything related to AuthZ ends up being so specific to every other decision you make about your infra, and companies that offer solutions tend to charge an arm and a leg so it's not easy to experiment (let's not even talk about vendor lock-in risks).

I've found Cognito + CASL to be an... acceptable middle ground, as Cognito specifically "standardizes" the various OIDC/SAML/OAuth2 integrations such that I can rely on a certain structure within the JWT that apparently (based on this article) isn't consistent! And CASL I at least know how to insert into our infra, though I could see how it might not be the latest-and-greatest...

I just wish I had the time to dive into the theory more. It seems interesting, but it's such a "boring" and "solved" thing that spending time on it doesn't really move the needle when it comes to stuff like customer acquisition.

I'm not quite sure what you're getting at, as OIDC and friends are very standardized when it comes to quite a few of the most important claims you would expect. There's an entire IANA registry [0] devoted to registered claims, in fact.

As for authz choices, you're correct that it's almost always entirely dependent on the application, and subject to frequent change as applications evolve, and as e.g. user and group structure evolves as well. The "managers" group of today might turn into "directors" and "VPs" as the company grows, and "pictures" might soon incorporate "albums" as an optional grouping factor with its own permissions.

In general, I would not really call authentication/authorization boring. There are components of it that are solved, but the reality of today is that people want a "share" link that they can paste in Slack and anybody can use it within seconds, and that kind of speed needs to be accounted for in authz, which is a significant engineering challenge.

Papers like Zanzibar [1] are super interesting to read too. And at least to me, not boring at all.

[0] https://www.iana.org/assignments/jwt/jwt.xhtml

[1] https://research.google/pubs/pub48190/

Yes they are standard, but this is akin to having a 'standard menu' at a restaurant. You're not getting every item on the menu, and for the ones that you do you could make modifications.

OAuth2 and OpenID has many standards documents. A 'standard' OAuth2 server can be written in 30 minutes if you only care about 1 grant type and none of the extra features and 1 flavor.

But it can also take 6 months if you do want support for all the features such as introspection, revokating, multiple grant types, ID Tokens, etc.

I wrote a bit about this issue here:

https://evertpot.com/oauth2-usability/

Note that this post is only about OAuth2, adding OpenID to the mix blows this problem up further.

The key point is that OAuth2 and OpenID provide a framework for building authentication and identity systems, with a matrix of possible implementation details that often have to be communicated out-of-band. It's still useful as a foundation, but picking an OAuth2 implementation is not as simple as just finding one that is OAuth2 compliant, you might have to dig deep and find out what parts you need and if your server implements them.

> And at least to me, not boring at all

I love Auth! It's always the key that unlocks everything else. Chances are that 50% of the "blocked" problems in your company can be solved if you know how their Auth works.

Plus, everyone thinks it's not worth their time to learn so you can be a superhero with just a few weeks of work.

This is helpful, thanks!

By "boring", I see that as a good thing; you want auth to be boring, is my point. Intellectually stimulating it is in any event (I enjoy learning systems), but I want the process to be me learning how it's done (the "boring"), not having to come up with novel solutions given my problem set (the "exciting").

> such a "boring" and "solved" thing

Well, don't forget it's also a security thing so no matter what DON'T IMPLEMENT IT YOURSELF YOU'LL GET IT WRONG so you sort of _have_ to mostly ignore the spec and start looking for a (probably commercial) implementation.

I think the advice to "not roll your own" is usually in regards to encryption. Other security stuff is more reasonable to take on yourself; I'm not sure it's more likely that you'll use someone elses AuthZ framework any more correctly than you'll implement your own.

Yeah, I'm finding that I also need to understand authentication well enough that I COULD implement it, just to safely and correctly use someone else's implementation.

Thank you for the comment! I have to admit it's hard for me to follow what you're saying, I'm not sure what you mean by "innovation" or "middle ground", or where you're getting that the JWT structure (of an OIDC token?) isn't consistent.

As a startup, I very much do not want to innovate or be in any way "creative" when implementing functionality that isn't my company's core value prop for customers. So for something like AuthZ I want to be as conforming as possible to what "everyone else" is doing, and I want to do that as quickly and seamlessly as I can, so when I say "innovation" here, I'm saying I don't want to build a new library or write a new technology to do AuthN/Z that isn't well-trod ground.

What I've experienced however, is that this isn't as easy as I expected. The "middle ground" here is between "inventing form whole cloth a bespoke library to solve AuthZ" and "do absolutely nothing whatsoever new". Using CASL in my infra's middleware to solve AuthN seems to be working for me. I can write the rules in a way CASL understands, and I was able to quickly implement the middleware without having to do anything crazy.

As for "JWT structure being inconsistent" I mean to say that often I'm asked to "connect" many different providers, e.g. Google social sign-in, Okta, Auth0, etc., all of whom have their own way of structuring their JWT payloads (beyond the standard that is), and using Cognito as an intermediary has been helpful to avoid all of that, as again, I'm trying to do as little as possible myself.

Maybe it's worthwhile pointing out that even Auth0 is kind of exploring a bespoke way of doing this:

https://auth0.com/docs/customize/extensions/authorization-ex...

Thank you for the clarification and for the tip about CASL and Cognito!

Reply on news.ycombinator.com