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.
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.
weitendorf · 6h 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.
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.
magicalhippo · 5h ago
> 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.
ehutch79 · 4h ago
From the authentication systems perspective, what exactly is the difference between an employee and 3rd party auditor?
From the authorization system, why would it care who they work for, as opposed to the permissions assigned to them?
magicalhippo · 4h ago
> From the authentication systems perspective, what exactly is the difference between an employee and 3rd party auditor?
Might require different authentication providers.
> From the authorization system, why would it care who they work for, as opposed to the permissions assigned to them?
Take the case of the accountant in the parent company. Either you create a user for that accountant in each of the child companies and manage access individually for each company, or you have a single user which has access to different child companies through separate permissions or something like that.
If you do it the first way, it's more like a regular B2C case, but not exactly because you still gotta do things like automatically disable those child-users when the accountant quits the parent company.
We've hit these scenarios as customer requirements in our B2B product, YMMV.
joseonjok · 4h ago
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 schemes
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.
pakl · 1h ago
In most B2B cases you really don’t want to self host authentication. Really.
There are plenty of identity providers out there who will worry about hashing passwords, resetting them, 2FA, etc. Most client businesses already have identities via one of those for all their employees (read: users of your APIs or apps).
Unfortunately nearly all of the open source solutions out there do exactly what you said, they start with (required) self-hosting authentication. Not helpful.
I believe it’s important to offer people a choice.
Some prefer self-hosting, while others opt for SaaS—it really depends on their specific needs. If you require data residency and complete control, self-hosting is the way to go. On the other hand, if you want a hands-off operational experience, SaaS makes more sense.
skeptrune · 6h ago
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.
nijave · 6h ago
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.
SahAssar · 6h ago
> it'd be good to callout OpenIDC as a predecessor to SAML
SAML is older than OpenID Connect by ~13 years.
jpc0 · 5h ago
OIDC does not in any way offer the same functionality as SCIM and SAML.
SAML is approximately OIDC + SCIM + Legacy Cruft
OkayPhysicist · 4h ago
What is the extra stuff that is provided compared to OIDC? I was implementing some of this stuff recently, and for my use case (who is this user? Do they have permission to use this application? Which parts of the application are they allowed to use?) OIDC seemed to cover everything, so I'm pretty curious if I missed some functionality that SAML provides.
jpc0 · 4h ago
Creating the user in your application before first logon.
Removing the user from your application immediately and not when their session eventually expires.
Doing those things in batch.
Querying that data at will to produce reports.
Updating a users group membership when needed and immediately and not when you decide to do so.
And then you only need an opaque userid from me and not a fat OIDC token that knows everything about my internal structure.
maxwellg · 2h ago
These are all features of SCIM, not of SAML. SAML only communicates user metadata on login. SCIM can be used with both SAML and OIDC.
jpc0 · 2h ago
You may be correct there. I seem to remember being able to handle that over SAML but could be an extension…
Regardless OIDC is authentication not authorisation. OIDC asserts who you are not what you are allowed to do, where SAML asserts what as well as who.
I mean you could hack assertions into scopes somehow and return it in the OIDC token but that’s not really standardised and everyone will just decide what they are going to add whenever they want which is at best no better than SAML using JS instead of XML.
maxwellg · 19m ago
The usual tagline is that "OAuth is authorization, not authentication". OIDC is an authentication layer built on top of OAuth. This means that OIDC can be used for both authentication and authorization to a third party API - most OIDC implementations allow the client to request an ID token (for authentication) and a traditional OAuth Access token (for authorization) in a single transaction. Clients can opt out of the authorization process by requesting only `response_type=id_token` and eschewing an authorization code entirely but that is not so common.
SAML does not grant any authorization to an upstream API.
lll-o-lll · 1h ago
The authorization model is bespoke to your ecosystem. Whether you do that with claims, scopes or assertions is irrelevant. None of these are hacks, but they can’t be simply standardized either. Provisioning/Deprovisioning is a separate concern; SCIM is one way (but just in time provisioning can also be achieved with both solutions).
There’s no reason to choose SAML other than for legacy integration.
T-Winsnes · 2h ago
SAML allows you to send additional attributes with the identity payload, like group memberships. This is not inherently authorisation, but can be used to automatically map users to teams/groups/roles in your application.
SAML is a very complicated standard, and very painful to implement. OIDC is much simpler, but lacks some of the capabilities.
Both can automatically create users on login, that is application implementation detail. Both also need SCIM or something similar to offboard users
cyberax · 1h ago
> Removing the user from your application immediately and not when their session eventually expires.
This is orthogonal to OIDC, unless you're using it to transfer groups in the token (don't).
> Querying that data at will to produce reports.
How the heck is this OIDC/SAML functionality?
> Removing the user from your application immediately and not when their session eventually expires.
OIDC allows the same workflow. The app just needs to be able to validate the session from the `sid` claim.
> And then you only need an opaque userid from me and not a fat OIDC token that knows everything about my internal structure.
OIDC tokens are opaque.
deathanatos · 4h ago
You're putting words in their mouth by adding in SCIM.
jpc0 · 4h ago
> SAML is approximately OIDC + SCIM + Legacy Cruft
I believe I added sufficient context for why I added SCIM into the mix.
funerr · 6h ago
How does this compare to better-auth?
noleary · 6h ago
(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.
jpc0 · 5h ago
I’m hoping the asked might have already known but pricing?
joseonjok · 4h ago
I'm not even sure better auth is worth comparing to, there are so many critical open issues that impact not only security but feature parity with much more established and mature open source solutions.
Not to be harsh but the website not loading earlier clearly doesn't set a good first impression.
nylonstrung · 6h ago
How does this compare to zitadel
noleary · 5h ago
(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!).
ffo · 2h ago
Welcome to the (B2B) auth space—it's encouraging to see more teams working on these challenges.
From our experience at Zitadel, we’ve found that mid-market and enterprise customers often also look for industry standards like SAML and OpenID Connect to integrate their services, so we’ve made those a core part of our offering—including providing fully compliant SAML and OpenID Connect endpoints. It looks like Tesseral is taking a more focused approach with SDK and API integrations for web apps, which makes a lot of sense for many teams starting out.
We also believe that, over time, the distinction between B2C and B2B use cases will blur, and both will be consolidated into a potent, unified identity infrastructure platform. That’s the direction we’re building toward with Zitadel.
Wishing you all the best as Tesseral grows. If you ever want to swap stories about auth, don't hesitate to reach out!
joseonjok · 4h ago
You are building an auth and you didn't even bother doing a in depth look at what Zitadel does ???? This doesn't communicate any serious commitment or product depth. Zitadel already does B2B very well and it is not only mature but very flexible to use across much of the enterprise space.
ffo · 1h ago
Thanks for highlighting Zitadel!
We agree—Zitadel is a strong platform. Our main challenge as an infrastructure product is balancing flexibility with ease of use. While we offer a lot of adaptability for different use cases, getting started can be daunting. We're actively working to make our onboarding process smoother so users can get up and running more quickly. For example we just started working on a lot of improvements on our SDKs as well as a template login app in nextjs that people can fork.
vivzkestrel · 5h ago
how does it compare to supertokens
Analemma_ · 5h 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?
Polizeiposaune · 4h ago
I would expect LLMs to generate a wall of text rather than ask simple questions.
warkdarrior · 1h ago
I bet someone is using an LLM to generate questions and trigger discussion between human accounts. The resulting thread will be later used for LLM training.
Application error: a client-side exception has occurred while loading tesseral.com (see the browser console for more information).
rsstack · 6h ago
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.
jamil7 · 6h ago
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.
koakuma-chan · 6h ago
They gotta start catching error that webgl is disabled.
mrweasel · 6h ago
Or you know, just remove the animation all together, it's not like it makes the product more compelling.
noleary · 6h ago
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
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.
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.
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.
From the authorization system, why would it care who they work for, as opposed to the permissions assigned to them?
Might require different authentication providers.
> From the authorization system, why would it care who they work for, as opposed to the permissions assigned to them?
Take the case of the accountant in the parent company. Either you create a user for that accountant in each of the child companies and manage access individually for each company, or you have a single user which has access to different child companies through separate permissions or something like that.
If you do it the first way, it's more like a regular B2C case, but not exactly because you still gotta do things like automatically disable those child-users when the accountant quits the parent company.
We've hit these scenarios as customer requirements in our B2B product, YMMV.
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.
There are plenty of identity providers out there who will worry about hashing passwords, resetting them, 2FA, etc. Most client businesses already have identities via one of those for all their employees (read: users of your APIs or apps).
Unfortunately nearly all of the open source solutions out there do exactly what you said, they start with (required) self-hosting authentication. Not helpful.
What’s more relevant to businesses is authorization using existing IdPs (shameless plug: https://github.com/DMGT-TECH/the-usher-server)
Some prefer self-hosting, while others opt for SaaS—it really depends on their specific needs. If you require data residency and complete control, self-hosting is the way to go. On the other hand, if you want a hands-off operational experience, SaaS makes more sense.
SAML is older than OpenID Connect by ~13 years.
SAML is approximately OIDC + SCIM + Legacy Cruft
Removing the user from your application immediately and not when their session eventually expires.
Doing those things in batch.
Querying that data at will to produce reports.
Updating a users group membership when needed and immediately and not when you decide to do so.
And then you only need an opaque userid from me and not a fat OIDC token that knows everything about my internal structure.
Regardless OIDC is authentication not authorisation. OIDC asserts who you are not what you are allowed to do, where SAML asserts what as well as who.
I mean you could hack assertions into scopes somehow and return it in the OIDC token but that’s not really standardised and everyone will just decide what they are going to add whenever they want which is at best no better than SAML using JS instead of XML.
SAML does not grant any authorization to an upstream API.
There’s no reason to choose SAML other than for legacy integration.
SAML is a very complicated standard, and very painful to implement. OIDC is much simpler, but lacks some of the capabilities.
Both can automatically create users on login, that is application implementation detail. Both also need SCIM or something similar to offboard users
This is orthogonal to OIDC, unless you're using it to transfer groups in the token (don't).
> Querying that data at will to produce reports.
How the heck is this OIDC/SAML functionality?
> Removing the user from your application immediately and not when their session eventually expires.
OIDC allows the same workflow. The app just needs to be able to validate the session from the `sid` claim.
> And then you only need an opaque userid from me and not a fat OIDC token that knows everything about my internal structure.
OIDC tokens are opaque.
I believe I added sufficient context for why I added SCIM into the mix.
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.
Not to be harsh but the website not loading earlier clearly doesn't set a good first impression.
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!).
From our experience at Zitadel, we’ve found that mid-market and enterprise customers often also look for industry standards like SAML and OpenID Connect to integrate their services, so we’ve made those a core part of our offering—including providing fully compliant SAML and OpenID Connect endpoints. It looks like Tesseral is taking a more focused approach with SDK and API integrations for web apps, which makes a lot of sense for many teams starting out.
We also believe that, over time, the distinction between B2C and B2B use cases will blur, and both will be consolidated into a potent, unified identity infrastructure platform. That’s the direction we’re building toward with Zitadel.
Wishing you all the best as Tesseral grows. If you ever want to swap stories about auth, don't hesitate to reach out!
We agree—Zitadel is a strong platform. Our main challenge as an infrastructure product is balancing flexibility with ease of use. While we offer a lot of adaptability for different use cases, getting started can be daunting. We're actively working to make our onboarding process smoother so users can get up and running more quickly. For example we just started working on a lot of improvements on our SDKs as well as a template login app in nextjs that people can fork.
Application error: a client-side exception has occurred while loading tesseral.com (see the browser console for more information).