Show HN: Tesseral – Open-Source Auth

(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.

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.

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...

Have a look at Authkit.

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.

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.

Django is in the works! As is Laravel and Rails (my first love).

We're trying to offer a clear abstraction for specifically B2B SaaS. By taking opinions, we can make implementation quicker and easier for developers.

Thanks Aeneas!

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.

> 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.

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.

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.

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]

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.

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.)