Users exclusively belong to Organizations; every User belongs to exactly one Organization.
But I also see a screenshot where, after login, the User has to choose an organization or to create a new one. It seems to me that you support Users and Organizations in a many-to-many relationship, is that correct?
At my work, we landed on the terminology of Users, Memberships, and Accounts to describe this (a User can have Memberships to multiple Accounts, an Account can have multiple Members, etc). As a result, you don't "delete a user", you "revoke a membership".
Yeah, this is a line I wrote and could probably improve the clarity on. It's worth distinguishing the Tesseral concept of a User from the sense in which we might colloquially refer to a user. Some other people call the equivalent of a Tesseral User a Member or something similar.
An individual human being who wants to log in can be represented by multiple Users in Tesseral, each of which belongs to exactly one Organization.
That is, there's support for a given person with a given email address to participate in different workspaces, but each workspace will have a different instance of a User.
That feels needlessly confusing and not a great way to handle large orgs. Datadog does a similar thing—I need to completely switch contexts to start working in a separate organization and there's absolutely no way to open tabs from two orgs side by side. Not to mention, any link to a dashboard or alert will fail until I go and select the right org from the dropdown (and if I don't know what org the link is in from context, I have no way to find it).
I don't think new auth services should encourage this pattern and I highly recommend that you remove this restriction as soon as possible before it becomes even more baked in. Your downstream services should have access to all of the orgs a user belongs to right from the beginning, using a comma-separated list or multi-value headers or something similar. Don't shard user IDs in this way.
> But when I authenticate my common support agents instead of the customers themselves, I do want them to have access to everything.
> I don’t think anyone has yet managed to make this easy.
We have a few recommendations for this (I work for FusionAuth, a different auth server). From our doc[0]:
Have users reset their password every time they need access to a different tenant.
Use a passwordless login option like a magic link or passkey.
Set up or use an administrative identity server, such as a second instance of FusionAuth, Google GSuite, or Azure AD/Microsoft Entra, and have these users log in using that.
Put all admin users in one FusionAuth tenant, create an application in that tenant, and set up an OIDC Identity Provider for applications in other tenants to delegate to that application.
> You don’t want org1 to have access to the data that user x has access to in org2
Of course not—I'm not sure why you'd think I mean that?
I'm just saying that if I open a link to `https://datadog.com/alert/12389` and `https://datadog.com/alert/12500` and the alerts are for different orgs, my auth cookies should be able to tell that I, as user X, have access to both orgs without having to "switch contexts" or re-auth.
It would also help with links routing to the correct org:
> If you are a member of multiple organizations, custom sub-domains help you identify the source of an alert or notification. Also, they can immediately switch you to the organization associated with the sub-domain.
However, that doesn't change my opinion that one-org-per-session and one-org-per-user is a terrible way to design an auth/auth system and Tesseral—a library/service that is trying to Get Auth Right—shouldn't design such a limitation into their system from the beginning
I think FusionAuth does something similar. They have a global user, and uses the notion of tenants / application registrations (which I think is comparable to a Tesseral Organization) to segment the same user.
Then you can define applications (which are mapped 1:1 to tenants) where a user has a registration entry against that application, where a user can be referenced by their global user id, or application-specific user id.
Applications are OAuth2 applications (meaning a dedicated client id / secret), so we only create a single application and tenant, and maintain organization segmentation on our own application / db side instead.
(We're paying customers of FusionAuth. Anyone from FusionAuth, feel free to correct me.)
"An individual human being who wants to log in can be represented by multiple Users in Tesseral, each of which belongs to exactly one Organization."
This will be extremely confusing. You should simplify it and just keep the concept of User as we usually do. A user should have access to 1 or more organizations. That's it. You should rethink this otherwise it will be too confusing.
But isn't this kind of like saying your logins to Blizzard and Activision should actually be the same underlying user? Doesn't make sense, and becomes an authz nightmare, imo.
I think the logic is to differentiate the "identity" from a "user"
One identity can have multiple users (one for each organization)
At the same time, a user can have multiple identities. (e.g. username/password, Google oAuth, SAML etc.)
The other terms that gets thrown around for this is “Workspace” and some sort of “Visitor”, “Guest”, or “Membership” relationship, or a “we create a copy and assign it to the new Organization” strategy. The past three places I’ve worked have done something akin to this. Usually after they guess about how Google Docs/Google Workspace functions based on observed behavior.
I went back and forth deciding if I should use a service like auth0 / Clerk / Stack Auth for my Flask based app. Ultimately I decided on doing it myself. Storing users and organization in the SQLite db and using a Flask package like Flask-Login. I didn’t want to have to migrate to an ORM (SQLAlchemy) and needed a few basic constraints:
- Users can optionally be assigned to an organization but not required.
- Email address is globally unique.
- A user can only be associated to a single organization.
- 2FA support.
- Single-Sign-On support with Google, Facebook, and GitHub.
I have a feeling not using a framework or auth service is going to bite me in the butt down the line, but it just felt easier to roll my own implementation to start.
It depends a bit on exactly what your use case is (i.e., which features are even relevant to you) and specifically what the alternate vendor would be. I really do try hard not to oversell what we offer.
I'll say this: if you're looking for an open source solution built to make B2B auth easy, we're the only option of the three. For Keycloak, for example, it's been an unresolved feature gap for many years that it can't support SCIM provisioning [0]; an unrelated characteristic -- not necessarily a flaw -- of Keycloak's is that it's quite agnostic to your use case and consequently requires some effort to implement.
On the other hand, we don't yet offer a huge amount of customization. We've instead -- for now -- prioritized building a relatively opinionated and therefore straightforward product. Similarly, if you're looking for some long-tail features, a longstanding vendor like Auth0 will very likely be able to help you.
Probably a few other considerations might be relevant that I'm neglecting. Send me an email if you're interested in chatting more (contact in HN bio) -- more than happy to help explore some of your options, even if that means we're not right for you.
I am curious about the use case to impersonate a user in S2S call here. In regular scenarios the caller service usually have enough privileges that it can pass the user as a header/parameter. An alternative could be OAuth2 flow with password grant type which already exists.
Plenty of cases. For example, I have an AI service that runs some expensive operations, for example, creates a video with interpretive dance for a given email.
In the normal case, the app running on the device just makes a request to that service, and gets the result back. The service does all the accounting for the request quotas, etc.
Now I want to run the same process for the user's emails in advance, from a service that runs on my server. You can't do this easily with existing S2S auth providers.
Thanks for the example, if I get the use case correctly then its about being able to exectue the operation on behalf of the user when the user is not around. This is what the OAuth2 (authorization) is designed for, the user consents giving the access token to the client app which can interact with the resource servers on behalf of the user. In this case the service running on your server would be the client app and the AI service has the burden to support OAuth2 functionality and API's. It does requires explicit user in the loop for the initial handshake.
However it seems like you are looking at the possibility of not even having the user in initial handshake to exchange/get the access token. Rather you are hoping that its a S2S call to get the token in the context of a user. I am treating this as more of an Assume user scenario and in my mind assuming the user context for debugging and service role is more day to day use case from what I have seen from security perspective. Or read only operations on behalf of user can be another bucket, mutations on behalf of user without users consent is something that sounds tricky for any external service
When Ory came out I was excited because they have a solid product that is made in Go, however their lack of multi-tenancy that didn't require setting up servers for each tenant made them a non-starter
I just had to implement 2FA on our homegrown auth, and I can't wait to replace it with Tesseral
To put this into some context: Ory as a product has grown a lot since then, and while it‘s not possible to have „logical user-pool multi-tenancy“ (logical in the sense that it‘s not running multiple instances) on the open source core alone, it certainly is possible on any of the paid-for options!
And generally speaking , there are a couple of examples out there that use the OSS core for multi-tenancy with the deployment scenario, but usually for a finite amount of tenants.
Our thinking behind this is that mostly direct competitors would need true multi tenancy, where every tenant has their own user pools, configs, URLs and so on.
It's pretty clear what you're supposed to do. Keycloak can't give you that kind of clarity, because they're designed to accommodate products that are B2C/B2B, single- or multi-tenant. Sometimes Keycloak is an IDP or an OAuth gateway, sometimes Keycloak is a customer identity management product.
Keycloak requires you to have familiarity with technologies at a level beyond what most developers have worked with. When your customer says "I need to enable SAML, and require it for all logins", with Keycloak you now need to know how SAML works, how to configure it, and how to walk your customer through that process. (FWIW, they can't support SCIM at all, you need to install a 3rd-party plugin.)
That code above is your answer to SAML, SCIM, customizing login methods, disabling Log in with Google, inviting users, or anything else your customer will ask for.
SCIM support is going to be implemented in the newer Red Hat build of Keycloak release (successor of RH-SSO), the current plan is to have an implementation with Red Hat build of Keycloak 26.4 scheduled for Q4/2025, however that is subject to change because of priorities.
It's a nice project but I don't think any venture needs a separate service for user accounts right off the bat. And I level that same criticism at Clerk, Auth0, Cognito which are all stand-ins for a lack of BE engineering.
Rails + Devise + OmniAuth + Doorkeeper has kept me going for yeeeeeaaaaaarrrrrrs.
We use Clerk and it's expensive but works great and saved us a ton of time on enterprise readiness. Saying "just BE engineer it" is all well and good until you need 2FA and org management and SSO and RBAC and configurable 2FA enforcement and passwordless sign-in and SMS and a lock-out policy and JIT account provisioning and all the UI to match and so on.
Recently, I spoke with a person who had experience in the startup world, and the one thing he would do differently in the future was to use Keycloak from the beginning instead of cloud-native authentication services, to have control over the user authentication flow.
Given that context, having other self-hosted options sounds like a good thing.
What about ventures without top quality engineering talent?
Security is the one thing that absolutely has to work and keep working as new threats develop. There’s thousands of LLM assisted projects being created by one person teams that will, and probably should, hand off this problem.
Bad quality CRUD is one thing, bad quality auth is another.
Well, yes, any dependency is technically a "lack of engineering". That's kinda the point - engineering capacity is limited and should be directed towards core business differentiators, not generic infrastructure.
That said, Auth is not really like all the rest of the services. It's special in that it controls all access to everything else making it the load-bearing stone in your entire architecture. Fundamental mistakes in your user auth model tend to be very very hard to unwind. So take the time to do the engineering work (thinking) even if you eventually outsource to a hosted provider - at least you'll know what you're outsourcing and the implications.
Auth0’s main differentiator is their tutorials for every framework under the sun. Want to have a SwiftUI, angular and Python command line frontends? They have tutorials for all that.
For the managed service, how do you think about the N+1 request/query issue and latency with things like org membership checks and authz checks? This always pushes me to want this stuff in my db or at least on my side of the network line. Seems that tesseral is self-hostable which is awesome and could be a solution, but I’d probably rather just use the managed service if it wasn’t for this issue.
Since Tesseral's data model is that users belong-to organizations, anytime you have a user, an organization is also available to you (e.g. in the context of a JWT's claims, or an API call to `api.tesseral.com/v1/users/user_...`, etc):
For authz checks, you have a similar denormalization when you use Tesseral's RBAC. When a user gets an access token, those access tokens have a list of `actions` that the user is allowed to carry out. All of our SDKs have a `hasPermission` function that basically just `accessToken.actions.contains(...)`:
So we do a little bit of denormalization whenever we mint an access token, but in exchange your code doesn't need to do any network hops to get an organization or do a permission check. (Access tokens are ES256-signed, and our SDKs handle caching the public keys, so that network hop is very infrequent.)
It's a bit of a mix of subtle design decisions and discrete features.
A few major things:
1. In business software, Organizations are your tenants. Users aren't tenants themselves. You have to think about things like "Which Organizations can this person sign into", you need to support user invitations, and you'll need to accommodate IT admins asking for control -- think stuff like turning off magic links for every employee at their company or requiring every employee to have MFA.
2. B2B software needs different auth and user management features. The big one is SAML SSO, but there's also stuff like provisioning (and deprovisioning) users from identity providers and letting your customers define custom role-based access control. Similarly, consumer software generally doesn't need to support stuff like API keys or audit logs.
Generally speaking, the big conceptual difference is that you're selling to a company, and the company wants control.
We know the Stack Auth team well, and we really respect what they're up to! We have a really high opinion of them. I'd be curious how they'd assess the comparison.
First, of course you can often use either of our two products in many cases. We do compete!
Second, I think we focus on subtly different customers. There are cases where they're a better fit and cases where I'd assess us to be a better fit. For example, Stack Auth is pretty closely aligned to the Next.js ecosystem. They're really quite strong at serving Next.js. They also have a billing and payments product that's likely interesting to companies with a heavy self-service motion. On the other hand, Tesseral serves only B2B software, and we're not as focused on Next.js (SDK currently in the works). If, for instance, you have a Go backend and sell large enterprise-y deals, we're probably a better fit.
But this will probably evolve over time. I'd expect this comparison to be outdated within a few months.
Overall, I expect our companies will drift in slightly different directions over time. We're both very early stage companies that have focused on pretty foundational features so far.
> For example, Stack Auth is pretty closely aligned to the Next.js ecosystem
Please for the love of god don't get sucked into the trap of building front end code for frameworks. Make it work with a 5 line static HTML file and a <script> tag, then build wrappers if you think they make sense.
Right now we offer prebuilt pages you can redirect to, as well as SDKs your clientside JavaScript can talk to if you want to reskin. Said SDKs are glorified cURL wrappers, and our prebuilt pages are built using them too.
No, at least not in the sense in which I've seen people use Sailpoint.
We often like to segment the world of identity and access management in two categories: workforce identity and customer identity (CIAM). There's a little bit of a blurry line between them, but it's mostly a useful way to break up the world.
Workforce identity products help IT teams manage employees' access to software systems. Think of the most recognizable sense in which people use Okta: you present your credentials to Okta, and it signs you into third party software like Slack.
Customer identity products like ours integrate with products like Sailpoint or Okta. If you make a product like Slack, you have many customers with many identity providers. You would use a product like ours to keep track of your users across different companies, and you'd use a product like ours to support single sign-on integrations with products like Sailpoint or Okta.
That said, I wouldn't be surprised if you can make Sailpoint behave like CIAM software. I am truthfully not very familiar with their product -- it's not very easy to make a developer account with them!
Dang. So an IdP + SCIM? From an IAM team perspective I rather dislike having IdPs being the source of truth for authz, because you're embedding a lot of application specific logic in a second location. It can't be worse than Shibboleth. I think there's a niche out there for a better IDM but it's a very unsexy space.
Indeed @vanschelven, django-hidp (Hello, ID Please) is our newly open-sourced full-featured authentication system for Django projects that we’ve just soft-launched. We were getting ready to post this on HN, but since this is here now, I thought we might just chime in on the discussion.
Current status of django-hidp is we’re still refining the documentation and building the website, but the core functionality is solid, and already in use for quite a lot of our clients. As such, we would say it's ready for evaluation by interested Django developers.
So, if you’re interested in a comprehensive authentication system for Django projects, django-hidp offers:
- comprehensive authentication: user registration with email verification, login, password reset, and more
- OpenID Connect (OIDC) support: built-in support for integrating with providers like Google and Microsoft
- One-Time Passwords (OTP): based on django-otp, with flexible flows and policies
- rate limiting: protects against brute-force attacks
- Content Security Policy (CSP): helps prevent cross-site scripting and other code injection attacks
- standalone OIDC Provider: can be configured to act as its own OIDC provider
- and a lot more...
Designed with OWASP best practices in mind, django-hidp aims to provide a secure and flexible solution for user authentication in Django projects. Without having to reinvent any wheels (no pun intended) and combining slews of dependencies together into a coherent whole. We've already done that quite a lot of times in the past, and now we finally sat down to that work for you, and build an opinionated, batteries-included application that can be used in all Django projects.
If you have any questions, or would like to know more, please reach out to me.
Zitadel is switching its license from Apache to AGPL3, that’s at least one difference. The license change caught my attention because I also use Zitadel, this project is MIT.
I think (not sure though) there is another difference to add here. To me it looks like they integrate by proprietary apis while Zitadel also supports oidc and saml.
But I have not checked their docs, so I could be wrong.
Lots of European companies are now looking at cloud options that do not rely on US companies as part of their due diligence.
That Amazon, Google or Azure might close our cloud accounts because the U.S. President insists on it because he’s offended or being leveraged, is a high enough risk to have started risk assessments, especially in EU businesses that operate critical infrastructure.
These US companies bending the knee to an authoritarian has not gone down well across the pond.
(disclaimer: I work at Zitadel)
Totally understand this concern. We ran into the same issue when building Zitadel - data residency requirements in Europe are real and getting stricter. That's why we built in deployment flexibility from day one. You can self-host on any infrastructure or use our managed service in your preferred region. The goal was to avoid vendor lock-in while still keeping things developer-friendly.
Strong agree. Working with European gov partners lately, and the further they can run from closed source USA infrastructure, the better. There are immense amounts of resources and political capital being spent down on this, and only more to come
because AWS is an american company, and right now the US is hostile to the rest of the world. probably similar to how US companies view working with a Russian or Chinese company.
Unfortunately AWS across the EU are still subsidiaries of an American corporation and therefore subject to the CLOUD Act, which allows US authorities to compel access to data stored by American companies anywhere in the world, including their European subsidiaries. This creates a direct conflict with GDPR's data protection requirements and EU digital sovereignty principles.
+1 to this concern from our Very Large customers in the EU.
Today, AWS, GCP, etc. are omnipresent, so there are plenty of counterexamples; however, the growing concern is, "How do we become less reliant on AWS in the next decade?" There is no answer to that today, but this adds growing friction for any USA-based B2B vendors who implicitly say "we will increase your ties to the USA forever". This concern about hyperscalers predates recent counter-USA movements, and feels like a one-way road.
Definitely. In a lot of companies (especially in Germany) management is looking how they can reduce their dependency on US clouds. For example by moving to something like Scaleway, the LIDL (Schwarz digits) cloud, etc.
Getting deeper into US clouds is not something which aligns with the "goal on the horizon" of most managements.
I rolled my own auth [0] and it works just fine. Why do I need another service for Auth, it's simple enough already. I guess B2B products need more auth features so it's worth using a library?
From the docs:
Users exclusively belong to Organizations; every User belongs to exactly one Organization.
But I also see a screenshot where, after login, the User has to choose an organization or to create a new one. It seems to me that you support Users and Organizations in a many-to-many relationship, is that correct?
At my work, we landed on the terminology of Users, Memberships, and Accounts to describe this (a User can have Memberships to multiple Accounts, an Account can have multiple Members, etc). As a result, you don't "delete a user", you "revoke a membership".
(I'm the other cofounder of Tesseral).
Yeah, this is a line I wrote and could probably improve the clarity on. It's worth distinguishing the Tesseral concept of a User from the sense in which we might colloquially refer to a user. Some other people call the equivalent of a Tesseral User a Member or something similar.
An individual human being who wants to log in can be represented by multiple Users in Tesseral, each of which belongs to exactly one Organization.
That is, there's support for a given person with a given email address to participate in different workspaces, but each workspace will have a different instance of a User.
That feels needlessly confusing and not a great way to handle large orgs. Datadog does a similar thing—I need to completely switch contexts to start working in a separate organization and there's absolutely no way to open tabs from two orgs side by side. Not to mention, any link to a dashboard or alert will fail until I go and select the right org from the dropdown (and if I don't know what org the link is in from context, I have no way to find it).
I don't think new auth services should encourage this pattern and I highly recommend that you remove this restriction as soon as possible before it becomes even more baked in. Your downstream services should have access to all of the orgs a user belongs to right from the beginning, using a comma-separated list or multi-value headers or something similar. Don't shard user IDs in this way.
I don’t think this is necessarily true. You don’t want org1 to have access to the data that user x has access to in org2.
But when I authenticate my common support agents instead of the customers themselves, I do want them to have access to everything.
I don’t think anyone has yet managed to make this easy.
> But when I authenticate my common support agents instead of the customers themselves, I do want them to have access to everything.
> I don’t think anyone has yet managed to make this easy.
We have a few recommendations for this (I work for FusionAuth, a different auth server). From our doc[0]:
It's a thorny problem, for sure.0: https://fusionauth.io/docs/get-started/core-concepts/users
> You don’t want org1 to have access to the data that user x has access to in org2
Of course not—I'm not sure why you'd think I mean that?
I'm just saying that if I open a link to `https://datadog.com/alert/12389` and `https://datadog.com/alert/12500` and the alerts are for different orgs, my auth cookies should be able to tell that I, as user X, have access to both orgs without having to "switch contexts" or re-auth.
It's possible to have multiple Datadog orgs open in the same browser context by having an admin from your account enable custom subdomains (https://docs.datadoghq.com/account_management/multi_organiza...).
It would also help with links routing to the correct org:
> If you are a member of multiple organizations, custom sub-domains help you identify the source of an alert or notification. Also, they can immediately switch you to the organization associated with the sub-domain.
Wow, that's super helpful, thanks.
However, that doesn't change my opinion that one-org-per-session and one-org-per-user is a terrible way to design an auth/auth system and Tesseral—a library/service that is trying to Get Auth Right—shouldn't design such a limitation into their system from the beginning
I think FusionAuth does something similar. They have a global user, and uses the notion of tenants / application registrations (which I think is comparable to a Tesseral Organization) to segment the same user.
Then you can define applications (which are mapped 1:1 to tenants) where a user has a registration entry against that application, where a user can be referenced by their global user id, or application-specific user id.
Applications are OAuth2 applications (meaning a dedicated client id / secret), so we only create a single application and tenant, and maintain organization segmentation on our own application / db side instead.
(We're paying customers of FusionAuth. Anyone from FusionAuth, feel free to correct me.)
"An individual human being who wants to log in can be represented by multiple Users in Tesseral, each of which belongs to exactly one Organization."
This will be extremely confusing. You should simplify it and just keep the concept of User as we usually do. A user should have access to 1 or more organizations. That's it. You should rethink this otherwise it will be too confusing.
But isn't this kind of like saying your logins to Blizzard and Activision should actually be the same underlying user? Doesn't make sense, and becomes an authz nightmare, imo.
I think the logic is to differentiate the "identity" from a "user"
One identity can have multiple users (one for each organization) At the same time, a user can have multiple identities. (e.g. username/password, Google oAuth, SAML etc.)
Here is a usecase.
Auth backend for an online accounting software.
An "admin" user creates orgs. Invites 3 other users.
Then there are orgs with multiple admins, multiple users, single user is member of multiple orgs by invite.
Like we have GitHub orgs.
The other terms that gets thrown around for this is “Workspace” and some sort of “Visitor”, “Guest”, or “Membership” relationship, or a “we create a copy and assign it to the new Organization” strategy. The past three places I’ve worked have done something akin to this. Usually after they guess about how Google Docs/Google Workspace functions based on observed behavior.
I went back and forth deciding if I should use a service like auth0 / Clerk / Stack Auth for my Flask based app. Ultimately I decided on doing it myself. Storing users and organization in the SQLite db and using a Flask package like Flask-Login. I didn’t want to have to migrate to an ORM (SQLAlchemy) and needed a few basic constraints:
- Users can optionally be assigned to an organization but not required.
- Email address is globally unique.
- A user can only be associated to a single organization.
- 2FA support.
- Single-Sign-On support with Google, Facebook, and GitHub.
I have a feeling not using a framework or auth service is going to bite me in the butt down the line, but it just felt easier to roll my own implementation to start.
Great demo videos -- looks like lots of strong design decisions! Will definitely try this in a future project.
... actually, given you already have a Golang SDK, I may try this very soon!
This is a very timely for us. We are close to pulling the trigger on KeyCloak.
We also looked at Auth0 and Fusionauth - KeyCloak won.
We did not check Teseral - could you help me understand why I would choose Tesseral over the other 3?
It depends a bit on exactly what your use case is (i.e., which features are even relevant to you) and specifically what the alternate vendor would be. I really do try hard not to oversell what we offer.
I'll say this: if you're looking for an open source solution built to make B2B auth easy, we're the only option of the three. For Keycloak, for example, it's been an unresolved feature gap for many years that it can't support SCIM provisioning [0]; an unrelated characteristic -- not necessarily a flaw -- of Keycloak's is that it's quite agnostic to your use case and consequently requires some effort to implement.
On the other hand, we don't yet offer a huge amount of customization. We've instead -- for now -- prioritized building a relatively opinionated and therefore straightforward product. Similarly, if you're looking for some long-tail features, a longstanding vendor like Auth0 will very likely be able to help you.
Probably a few other considerations might be relevant that I'm neglecting. Send me an email if you're interested in chatting more (contact in HN bio) -- more than happy to help explore some of your options, even if that means we're not right for you.
[0] https://stackoverflow.com/questions/58566587/does-keycloak-s...
Thanks for evaluating FusionAuth! (I work there.)
Would love to learn more about the strengths and weaknesses of each of these options in light of your use case.
My contact info is in my profile.
Have a look at Authkit.
So you're competing with Auth0, Clerk and others. You really need some differentiator. For me that would be:
- Service-to-service authentication.
- User impersonation in S2S calls ("I'm a service SERVICE1 making a call on behalf of USER_JOE"), including for offline flows.
- A way to view and manage the offline grants for S2S impersonation.
- All of the above must be resilient.
I don't think any authentication solution actually tackles this.
I am curious about the use case to impersonate a user in S2S call here. In regular scenarios the caller service usually have enough privileges that it can pass the user as a header/parameter. An alternative could be OAuth2 flow with password grant type which already exists.
Plenty of cases. For example, I have an AI service that runs some expensive operations, for example, creates a video with interpretive dance for a given email.
In the normal case, the app running on the device just makes a request to that service, and gets the result back. The service does all the accounting for the request quotas, etc.
Now I want to run the same process for the user's emails in advance, from a service that runs on my server. You can't do this easily with existing S2S auth providers.
Thanks for the example, if I get the use case correctly then its about being able to exectue the operation on behalf of the user when the user is not around. This is what the OAuth2 (authorization) is designed for, the user consents giving the access token to the client app which can interact with the resource servers on behalf of the user. In this case the service running on your server would be the client app and the AI service has the burden to support OAuth2 functionality and API's. It does requires explicit user in the loop for the initial handshake.
However it seems like you are looking at the possibility of not even having the user in initial handshake to exchange/get the access token. Rather you are hoping that its a S2S call to get the token in the context of a user. I am treating this as more of an Assume user scenario and in my mind assuming the user context for debugging and service role is more day to day use case from what I have seen from security perspective. Or read only operations on behalf of user can be another bucket, mutations on behalf of user without users consent is something that sounds tricky for any external service
When Ory came out I was excited because they have a solid product that is made in Go, however their lack of multi-tenancy that didn't require setting up servers for each tenant made them a non-starter
I just had to implement 2FA on our homegrown auth, and I can't wait to replace it with Tesseral
To put this into some context: Ory as a product has grown a lot since then, and while it‘s not possible to have „logical user-pool multi-tenancy“ (logical in the sense that it‘s not running multiple instances) on the open source core alone, it certainly is possible on any of the paid-for options!
And generally speaking , there are a couple of examples out there that use the OSS core for multi-tenancy with the deployment scenario, but usually for a finite amount of tenants.
Our thinking behind this is that mostly direct competitors would need true multi tenancy, where every tenant has their own user pools, configs, URLs and so on.
> I just had to implement 2FA on our homegrown auth, and I can't wait to replace it with Tesseral
My condolences. Never fun to bolt on undifferentiated but required features.
Glad to hear! Drop me a note if you have any issues/feedback as you go through the docs.
Contact info in my HN bio.
How does it compare to Keycloak?
We're trying to offer a clear abstraction for specifically B2B SaaS. By taking opinions, we can make implementation quicker and easier for developers.
In what technical ways is that visible?
One way is that it's really obvious what you're supposed to do with Tesseral! Like, here's our Go SDK docs:
https://tesseral.com/docs/sdks/serverside-sdks/tesseral-sdk-...
It's pretty clear what you're supposed to do. Keycloak can't give you that kind of clarity, because they're designed to accommodate products that are B2C/B2B, single- or multi-tenant. Sometimes Keycloak is an IDP or an OAuth gateway, sometimes Keycloak is a customer identity management product.
Keycloak requires you to have familiarity with technologies at a level beyond what most developers have worked with. When your customer says "I need to enable SAML, and require it for all logins", with Keycloak you now need to know how SAML works, how to configure it, and how to walk your customer through that process. (FWIW, they can't support SCIM at all, you need to install a 3rd-party plugin.)
In Tesseral, all you need is this [0]:
That code above is your answer to SAML, SCIM, customizing login methods, disabling Log in with Google, inviting users, or anything else your customer will ask for.[0]: https://tesseral.com/docs/sdks/clientside-sdks/tesseral-sdk-...
SCIM is on the roadmap for Keycloak.
-> https://access.redhat.com/solutions/5065271I don't really understand the main difference advantage, except that you offer better support for business.
Maybe that's enough? There's a lot of room for differentiation in the auth space, as there's a wide universe of needs.
Just look at the 30 companies in the authentication space YC has funded:
https://www.ycombinator.com/companies?query=authentication
Congrats on the launch Ulysse - impressive what you have been able to spin up with limited resources! Greetings from Ory :)
Thanks Aeneas!
It's a nice project but I don't think any venture needs a separate service for user accounts right off the bat. And I level that same criticism at Clerk, Auth0, Cognito which are all stand-ins for a lack of BE engineering.
Rails + Devise + OmniAuth + Doorkeeper has kept me going for yeeeeeaaaaaarrrrrrs.
We use Clerk and it's expensive but works great and saved us a ton of time on enterprise readiness. Saying "just BE engineer it" is all well and good until you need 2FA and org management and SSO and RBAC and configurable 2FA enforcement and passwordless sign-in and SMS and a lock-out policy and JIT account provisioning and all the UI to match and so on.
Recently, I spoke with a person who had experience in the startup world, and the one thing he would do differently in the future was to use Keycloak from the beginning instead of cloud-native authentication services, to have control over the user authentication flow.
Given that context, having other self-hosted options sounds like a good thing.
What about ventures without top quality engineering talent?
Security is the one thing that absolutely has to work and keep working as new threats develop. There’s thousands of LLM assisted projects being created by one person teams that will, and probably should, hand off this problem.
Bad quality CRUD is one thing, bad quality auth is another.
> all stand-ins for a lack of BE engineering.
Well, yes, any dependency is technically a "lack of engineering". That's kinda the point - engineering capacity is limited and should be directed towards core business differentiators, not generic infrastructure.
That said, Auth is not really like all the rest of the services. It's special in that it controls all access to everything else making it the load-bearing stone in your entire architecture. Fundamental mistakes in your user auth model tend to be very very hard to unwind. So take the time to do the engineering work (thinking) even if you eventually outsource to a hosted provider - at least you'll know what you're outsourcing and the implications.
Auth0’s main differentiator is their tutorials for every framework under the sun. Want to have a SwiftUI, angular and Python command line frontends? They have tutorials for all that.
Eh, I don't really mind a service playing in the same space as Keycloak.
It's really not much work to spin up a service, and personally having used Rails + Devise + OmniAuth + Doorkeeper... I'd pick Keycloak instead.
The level of complexity is pretty similar at the end of the day, but you get more robust auth service, with a lot more flexibility.
Congrats on the launch! (From a FusionAuth employee!)
Also, I interviewed Ned, the CEO of Tesseral, on my newsletter. You can read his thoughts about the future of CIAM here: https://ciamweekly.substack.com/p/an-interview-with-ned-olea...
Congrats guys—looking good!
For the managed service, how do you think about the N+1 request/query issue and latency with things like org membership checks and authz checks? This always pushes me to want this stuff in my db or at least on my side of the network line. Seems that tesseral is self-hostable which is awesome and could be a solution, but I’d probably rather just use the managed service if it wasn’t for this issue.
Since Tesseral's data model is that users belong-to organizations, anytime you have a user, an organization is also available to you (e.g. in the context of a JWT's claims, or an API call to `api.tesseral.com/v1/users/user_...`, etc):
For authz checks, you have a similar denormalization when you use Tesseral's RBAC. When a user gets an access token, those access tokens have a list of `actions` that the user is allowed to carry out. All of our SDKs have a `hasPermission` function that basically just `accessToken.actions.contains(...)`:
e.g. Go: https://pkg.go.dev/github.com/tesseral-labs/tesseral-sdk-go@...
Again in Go, here's the data type for access tokens:
https://pkg.go.dev/github.com/tesseral-labs/tesseral-sdk-go#... (organization lives in .Organization, list of permissions lives in .Actions)
So we do a little bit of denormalization whenever we mint an access token, but in exchange your code doesn't need to do any network hops to get an organization or do a permission check. (Access tokens are ES256-signed, and our SDKs handle caching the public keys, so that network hop is very infrequent.)
Oh nice, that seems ideal. Good stuff.
Seems python support is there. Would appreciate a Django walkthrough as well. Clerk, Betterauth and others mostly skip Django for some reason
Django is in the works! As is Laravel and Rails (my first love).
What's so different about auth for B2B?
It's a bit of a mix of subtle design decisions and discrete features.
A few major things:
1. In business software, Organizations are your tenants. Users aren't tenants themselves. You have to think about things like "Which Organizations can this person sign into", you need to support user invitations, and you'll need to accommodate IT admins asking for control -- think stuff like turning off magic links for every employee at their company or requiring every employee to have MFA.
2. B2B software needs different auth and user management features. The big one is SAML SSO, but there's also stuff like provisioning (and deprovisioning) users from identity providers and letting your customers define custom role-based access control. Similarly, consumer software generally doesn't need to support stuff like API keys or audit logs.
Generally speaking, the big conceptual difference is that you're selling to a company, and the company wants control.
[dead]
How does it compare to the other recent YC company Stack Auth?
We know the Stack Auth team well, and we really respect what they're up to! We have a really high opinion of them. I'd be curious how they'd assess the comparison.
First, of course you can often use either of our two products in many cases. We do compete!
Second, I think we focus on subtly different customers. There are cases where they're a better fit and cases where I'd assess us to be a better fit. For example, Stack Auth is pretty closely aligned to the Next.js ecosystem. They're really quite strong at serving Next.js. They also have a billing and payments product that's likely interesting to companies with a heavy self-service motion. On the other hand, Tesseral serves only B2B software, and we're not as focused on Next.js (SDK currently in the works). If, for instance, you have a Go backend and sell large enterprise-y deals, we're probably a better fit.
But this will probably evolve over time. I'd expect this comparison to be outdated within a few months.
Overall, I expect our companies will drift in slightly different directions over time. We're both very early stage companies that have focused on pretty foundational features so far.
> For example, Stack Auth is pretty closely aligned to the Next.js ecosystem
Please for the love of god don't get sucked into the trap of building front end code for frameworks. Make it work with a 5 line static HTML file and a <script> tag, then build wrappers if you think they make sense.
Right now we offer prebuilt pages you can redirect to, as well as SDKs your clientside JavaScript can talk to if you want to reskin. Said SDKs are glorified cURL wrappers, and our prebuilt pages are built using them too.
Prebuilt UIs: https://tesseral.com/docs/features/self-serve-organization-s...
The API they talk to, which you can talk to too: https://tesseral.com/docs/frontend-api-reference/tesseral-fr...
Does this compete with IDMs with Sailpoint?
No, at least not in the sense in which I've seen people use Sailpoint.
We often like to segment the world of identity and access management in two categories: workforce identity and customer identity (CIAM). There's a little bit of a blurry line between them, but it's mostly a useful way to break up the world.
Workforce identity products help IT teams manage employees' access to software systems. Think of the most recognizable sense in which people use Okta: you present your credentials to Okta, and it signs you into third party software like Slack.
Customer identity products like ours integrate with products like Sailpoint or Okta. If you make a product like Slack, you have many customers with many identity providers. You would use a product like ours to keep track of your users across different companies, and you'd use a product like ours to support single sign-on integrations with products like Sailpoint or Okta.
That said, I wouldn't be surprised if you can make Sailpoint behave like CIAM software. I am truthfully not very familiar with their product -- it's not very easy to make a developer account with them!
Dang. So an IdP + SCIM? From an IAM team perspective I rather dislike having IdPs being the source of truth for authz, because you're embedding a lot of application specific logic in a second location. It can't be worse than Shibboleth. I think there's a niche out there for a better IDM but it's a very unsexy space.
Have you had a pen test yet?
Yes! Can discuss more over email if you have any questions.
keycloak, better-auth, supertokens and now this, i would love to know how it compares to the rest
In the Django world I just ran into this project with similar goals:
https://github.com/leukeleu/django-hidp
Indeed @vanschelven, django-hidp (Hello, ID Please) is our newly open-sourced full-featured authentication system for Django projects that we’ve just soft-launched. We were getting ready to post this on HN, but since this is here now, I thought we might just chime in on the discussion.
Current status of django-hidp is we’re still refining the documentation and building the website, but the core functionality is solid, and already in use for quite a lot of our clients. As such, we would say it's ready for evaluation by interested Django developers.
So, if you’re interested in a comprehensive authentication system for Django projects, django-hidp offers:
- comprehensive authentication: user registration with email verification, login, password reset, and more
- OpenID Connect (OIDC) support: built-in support for integrating with providers like Google and Microsoft
- One-Time Passwords (OTP): based on django-otp, with flexible flows and policies
- rate limiting: protects against brute-force attacks
- Content Security Policy (CSP): helps prevent cross-site scripting and other code injection attacks
- standalone OIDC Provider: can be configured to act as its own OIDC provider
- and a lot more...
Designed with OWASP best practices in mind, django-hidp aims to provide a secure and flexible solution for user authentication in Django projects. Without having to reinvent any wheels (no pun intended) and combining slews of dependencies together into a coherent whole. We've already done that quite a lot of times in the past, and now we finally sat down to that work for you, and build an opinionated, batteries-included application that can be used in all Django projects.
If you have any questions, or would like to know more, please reach out to me.
this looks interesting - launching a new app soon and in the middle of setting up auth. looking forward to learning more!
if you need any help, or run into any issues, please reach out to me - glad to help!
[dead]
Looks nice, we've been using https://zitadel.com/ and the journey to mutli-tennancy was fairly straight forward.
Zitadel is switching its license from Apache to AGPL3, that’s at least one difference. The license change caught my attention because I also use Zitadel, this project is MIT.
[0] https://zitadel.com/blog/zitadel-v3-announcement
I think (not sure though) there is another difference to add here. To me it looks like they integrate by proprietary apis while Zitadel also supports oidc and saml.
But I have not checked their docs, so I could be wrong.
This looks neat, unfortunately the dependency on AWS is a show stopper for many European companies these days.
Lots of European companies are now looking at cloud options that do not rely on US companies as part of their due diligence.
That Amazon, Google or Azure might close our cloud accounts because the U.S. President insists on it because he’s offended or being leveraged, is a high enough risk to have started risk assessments, especially in EU businesses that operate critical infrastructure.
These US companies bending the knee to an authoritarian has not gone down well across the pond.
https://www.heise.de/en/news/Criminal-Court-Microsoft-s-emai...
We're aiming to abstract away our AWS dependencies -- KMS, S3, SES -- specifically to accommodate other clouds or non-clouds.
There is a nice library that abstracts a few core things like secret management for the major cloud platforms and some self hosted or local options.
https://gocloud.dev/howto/secrets/
(disclaimer: I work at Zitadel) Totally understand this concern. We ran into the same issue when building Zitadel - data residency requirements in Europe are real and getting stricter. That's why we built in deployment flexibility from day one. You can self-host on any infrastructure or use our managed service in your preferred region. The goal was to avoid vendor lock-in while still keeping things developer-friendly.
https://news.ycombinator.com/item?id=43119777
that's fair. My apologies. Happy to remove it.
Why is that? AWS has availability zones all around the globe, and 8 across the EU.
Strong agree. Working with European gov partners lately, and the further they can run from closed source USA infrastructure, the better. There are immense amounts of resources and political capital being spent down on this, and only more to come
because AWS is an american company, and right now the US is hostile to the rest of the world. probably similar to how US companies view working with a Russian or Chinese company.
Unfortunately AWS across the EU are still subsidiaries of an American corporation and therefore subject to the CLOUD Act, which allows US authorities to compel access to data stored by American companies anywhere in the world, including their European subsidiaries. This creates a direct conflict with GDPR's data protection requirements and EU digital sovereignty principles.
I wasn't aware either. Is GCP and Azure similarly viewed in the EU? You run out of cloud providers pretty quickly.
+1 to this concern from our Very Large customers in the EU.
Today, AWS, GCP, etc. are omnipresent, so there are plenty of counterexamples; however, the growing concern is, "How do we become less reliant on AWS in the next decade?" There is no answer to that today, but this adds growing friction for any USA-based B2B vendors who implicitly say "we will increase your ties to the USA forever". This concern about hyperscalers predates recent counter-USA movements, and feels like a one-way road.
Definitely. In a lot of companies (especially in Germany) management is looking how they can reduce their dependency on US clouds. For example by moving to something like Scaleway, the LIDL (Schwarz digits) cloud, etc.
Getting deeper into US clouds is not something which aligns with the "goal on the horizon" of most managements.
Never read Faust, huh?
[dead]
I rolled my own auth [0] and it works just fine. Why do I need another service for Auth, it's simple enough already. I guess B2B products need more auth features so it's worth using a library?
[0] https://github.com/wakatime/crackboard.dev/blob/main/package...
Thanks for sharing, your code looks good.