Hi folks! I'm Ulysse, and Tesseral (<a href="https://github.com/tesseral-labs/tesseral">https://github.com/tesseral-labs/tesseral</a>) is open-source auth for B2B SaaS.<p>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.<p>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.<p>We made Tesseral to help software engineers get B2B auth exactly right – and focus their energy on building the features that users want.<p>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).<p>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.<p>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.)<p>If you want to experiment with Tesseral, you can host it yourself or use our hosted service. The hosted service lives at <a href="https://console.tesseral.com">https://console.tesseral.com</a>. You can find documentation here: <a href="https://tesseral.com/docs">https://tesseral.com/docs</a>.<p>Here are a few simple demos:<p><a href="https://www.youtube.com/watch?v=IhYPzz3vB54" rel="nofollow">https://www.youtube.com/watch?v=IhYPzz3vB54</a><p><a href="https://www.youtube.com/watch?v=t-JJ8TNjqNU" rel="nofollow">https://www.youtube.com/watch?v=t-JJ8TNjqNU</a><p><a href="https://www.youtube.com/watch?v=mwthBIRZO8k" rel="nofollow">https://www.youtube.com/watch?v=mwthBIRZO8k</a><p>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.<p>What have we missed? What can we do better? We're eager to hear from the community!
From the docs:<p><i>Users exclusively belong to Organizations; every User belongs to exactly one Organization.</i><p>But I also see a screenshot where, after login, the User has to choose an organization or to create a new one. It <i>seems</i> to me that you support Users and Organizations in a many-to-many relationship, is that correct?<p>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 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:<p>- Users can optionally be assigned to an organization but not required.<p>- Email address is globally unique.<p>- A user can only be associated to a single organization.<p>- 2FA support.<p>- Single-Sign-On support with Google, Facebook, and GitHub.<p>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.<p>... 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.<p>We also looked at
Auth0 and Fusionauth - KeyCloak won.<p>We did not check Teseral - could you help me understand why I would choose Tesseral over the other 3?
So you're competing with Auth0, Clerk and others. You really need some differentiator. For me that would be:<p>- Service-to-service authentication.<p>- User impersonation in S2S calls ("I'm a service SERVICE1 making a call on behalf of USER_JOE"), including for offline flows.<p>- A way to view and manage the offline grants for S2S impersonation.<p>- All of the above must be resilient.<p>I don't think any authentication solution actually tackles this.
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<p>I just had to implement 2FA on our homegrown auth, and I can't wait to replace it with Tesseral
Congrats on the launch! (From a FusionAuth employee!)<p>Also, I interviewed Ned, the CEO of Tesseral, on my newsletter. You can read his thoughts about the future of CIAM here: <a href="https://ciamweekly.substack.com/p/an-interview-with-ned-oleary" rel="nofollow">https://ciamweekly.substack.com/p/an-interview-with-ned-olea...</a>
Congrats guys—looking good!<p>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.
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.<p>Rails + Devise + OmniAuth + Doorkeeper has kept me going for yeeeeeaaaaaarrrrrrs.
In the Django world I just ran into this project with similar goals:<p><a href="https://github.com/leukeleu/django-hidp">https://github.com/leukeleu/django-hidp</a>
Looks nice, we've been using <a href="https://zitadel.com/" rel="nofollow">https://zitadel.com/</a> and the journey to mutli-tennancy was fairly straight forward.
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?<p>[0] <a href="https://github.com/wakatime/crackboard.dev/blob/main/packages/core/src/backend/auth.ts">https://github.com/wakatime/crackboard.dev/blob/main/package...</a>