- Seems pretty good although it'd be good to callout OpenIDC as a predecessor to SAML. OpenIDC is pretty widely supported with the added benefit of not having to deal with certificate expiry.by nijave - 10 hours ago
- How does this compare to zitadelby nylonstrung - 10 hours ago
- How does this compare to better-auth?by funerr - 10 hours ago
- https://tesseral.com/by koakuma-chan - 10 hours ago
Application error: a client-side exception has occurred while loading tesseral.com (see the browser console for more information).
- I think making it easier to respond to the super annoying requests like "make everyone use a yubikey" is a real pain point I'd buy something to solve.by skeptrune - 10 hours ago
- I've been thinking a ton about this over the last year and I think this is actually overcomplicating things. Generally from what I can tell, most of what makes Auth so painful is overcomplicating things.by weitendorf - 9 hours ago
My belief is that the only two things you need to know to understand Auth are Identity and your Authorization model. Everything else is just a consequence of those two things.
Consumer and B2B auth are different mostly because they have different identity and authorization models, neither of which are really that complicated to identify:
1. Consumers theoretically control their own identity but in practice almost all delegate it to gmail, facebook, microsoft, etc. Businesses have actual control over their employee's identities because they own domains and emails get routed to wherever they point their domain at.
2. Consumer authorization models by default give the user access to all of their data and none of anybody else's data, unless explicitly configured otherwise. Business authorization models work exactly the same way for admins (meaning, control of the business' source of identity gives them access to ~all of the business' data). It's kind of insane to give everybody access to everybody's data so businesses create ontologies of roles/groups/scopes so that each employee only gets just as much admin powers as they require.
Why does it work that way? Well, when you control your own identity like consumers and admins, you want to just get things done without permission and auth getting in the way. When you control other people's identity you aren't personally subject to the difficulties that arise from locking things down, but you are responsible for their identity and what that identity can do, so you do what you can to limit access.
It all kinda reduces down to the problem that the Internet didn't come with a good system for managing identity, so we all use accounts based on email, which is based on domains, which route traffic using DNS, which basically sends all the account recovery/verification/communication record for every employee of a company to one spot. There is an inherent escalation of privilege vulnerability there, and there's no good fix, so we resign ourselves to a security model that says 1. centralize all information in one place 2. do whatever possible to hide, compartmentalize, and limit access to that information. It feels insane because it is insane.
Being responsible for only your own identity, actions, access, and data: makes sense. Being responsible for everybody else's actions, access, and data (because your job is managing the thing that centralized it all in one place): nightmare fuel.
- how does it compare to supertokensby vivzkestrel - 9 hours ago
- I know it is bad form to level accusations at other commenters, but I have to ask: have the LLMs infested this thread? What is with all the content-free "how does it compare to [X]" comments in here?by Analemma_ - 9 hours ago
- I've standardized on a couple defaults that save me a lot of pain down the road. First is I always tenant by an "Organization" as the article suggests, even when the initial organization is a user of one. This allows for creating teams or organization sharing. Which for anything other than "will always be a single user app" every app eventually wants multi-user organizations.by rorylaitila - 8 hours ago
Two, I appear as RBAC but implement ABAC under the hood. Technically the App is ABAC, but to the initial users, all they see are Roles. They cannot configure their resources. Later on, I can build interfaces for ABAC to manage their own Resources and Roles.
Bonus third, all Resources resolve to URL routes GET or POST. The application firewall prevents calls to URLs that they do not have resource permission. The server strips links and buttons from the HTML that they do not have permission to (or decorates them with a style). Thus there is no "if has resource show" code all polluting my UI.
- I'm puzzled as to why this area is constantly seeing reinventing the wheels? I can name a few very mature (20 years in teh making) open source projects that pretty much lets you self host everything you might possibly need to handle all sorts of authentication schemesby joseonjok - 7 hours ago
It seems like if its not written in Javascript people have aversion to it and this "keep everything typescript" really makes no sense to me especially when you deal with the missio n critical nature of backends.