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.
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.
Application error: a client-side exception has occurred while loading tesseral.com (see the browser console for more information).
Next.js doing that is like ASP.NET in production "in debug mode" printing stack traces, or PHP applications printing their MySQL connection errors. So sad.
I've been seeing this all over the internet, even on news websites that have already loaded their content. So Next doesn't allow me to read text that's already loaded in my browser because of some random JS error I don't care about.
They gotta start catching error that webgl is disabled.
Or you know, just remove the animation all together, it's not like it makes the product more compelling.
oops, thanks for flagging. we'll fix this! we only recently did a complete overhaul of our website and are still patching up some details
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.
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.
> it'd be good to callout OpenIDC as a predecessor to SAML
SAML is older than OpenID Connect by ~13 years.
OIDC does not in any way offer the same functionality as SCIM and SAML.
SAML is approximately OIDC + SCIM + Legacy Cruft
how does it compare to supertokens
How does this compare to better-auth?
(I'm a cofounder of Tesseral)
We're huge fans of Better Auth -- it's a really great offering. They might have their own take on how we differ, but here's my best attempt at a quick comparison.
We take pretty different approaches to roughly the same family of problems.
Better Auth is focused on being a great library for TypeScript. If you write Typescript and want to build your own auth, they're a great bet.
We're more of an API-first service that's agnostic to the language or framework that you use. We have a pretty opinionated product that is meant to handle auth for you -- it's not really an auth library per se.
I’m hoping the asked might have already known but pricing?
How does this compare to zitadel
(I am a cofounder of Tesseral)
Honestly, I'm not intimately familiar with Zitadel's solution. At a quick glance, it seems quite powerful! But it does seem like our product is more opinionated -- and is more narrowly focused on serving B2B applications.
I suspect that if you have the appetite and experience to build something unusual or otherwise complex, Zitadel will be a great fit. Perhaps they are like Keycloak in this respect. On the other hand, we try very hard to steer developers into a 'pit of success' by abstracting away a lot of details that most people don't need to worry about.
But I'll admit that comparison may be inaccurate; I probably will have to look in more detail. (The comparison will certainly seem wrong months / years into the future as our companies evolve!).
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?
> Business authorization models work exactly the same way
Except you got people from the parent company wanting access to certain stuff, and then there's the third-party auditor that needs access and so on.
So no, B2B isn't exactly the same necessarily.