Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: