Early in my career, I worked on enterprise auth and security features at Segment. I've been obsessed with the subtle details of enterprise software ever since. For example, I wrote an implementation of SAML in the early days of the COVID pandemic because I thought it was fun.
Over the years, I've felt frustrated that too few people have seemed interested in making auth obvious for developers of business software. Auth really doesn't need to be so confusing.
We made Tesseral to help software engineers get B2B auth exactly right – and focus their energy on building the features that users want.
You can use Tesseral to stand up a login page, authenticate your users, and manage their access to resources. Think of it like Auth0 or Clerk, but open source and built specifically for B2B apps. Among other things, that means that it’s designed for B2B multi-tenancy and includes enterprise-ready features like single sign-on (SAML SSO), multi-factor authentication (MFA), SCIM provisioning, and role-based access control (RBAC).
For those who expose public APIs, you can use Tesseral to manage API keys for your customers. You can even limit the scope of API keys to specific actions by using our RBAC feature.
We've taken care to make Tesseral powerful and secure enough to power real enterprise software but still leave it simple enough for any software developer to use. You don't have to be a security expert to implement Tesseral. (By default, therefore, Tesseral imposes a few opinions. Let us know if you have a good reason to do something unusual, and we'll work something out.)
If you want to experiment with Tesseral, you can host it yourself or use our hosted service. The hosted service lives at https://console.tesseral.com. You can find documentation here: https://tesseral.com/docs.
Here are a few simple demos:
https://www.youtube.com/watch?v=IhYPzz3vB54
https://www.youtube.com/watch?v=t-JJ8TNjqNU
https://www.youtube.com/watch?v=mwthBIRZO8k
We're in the early stages of the project, so we still have some gaps. We have more features, bug fixes, SDKs, and documentation on the way.
What have we missed? What can we do better? We're eager to hear from the community!
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.
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.
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.)
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.
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.)
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.
- 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.
... actually, given you already have a Golang SDK, I may try this very soon!
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?
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...
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.
- 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.
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.
I just had to implement 2FA on our homegrown auth, and I can't wait to replace it with Tesseral
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.
My condolences. Never fun to bolt on undifferentiated but required features.
Contact info in my HN bio.
Rails + Devise + OmniAuth + Doorkeeper has kept me going for yeeeeeaaaaaarrrrrrs.
Given that context, having other self-hosted options sounds like a good thing.
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.
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.
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.
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.)
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...
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.
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.
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.
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!
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.
But I have not checked their docs, so I could be wrong.
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...
[0] https://github.com/wakatime/crackboard.dev/blob/main/package...
