[HN Gopher] Show HN: Tesseral - Open-Source Auth
___________________________________________________________________
Show HN: Tesseral - Open-Source Auth
Hi folks! I'm Ulysse, and Tesseral (https://github.com/tesseral-
labs/tesseral) is open-source auth for B2B SaaS. 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!
Author : ucarion
Score : 116 points
Date : 2025-05-28 15:27 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| macmac wrote:
| This looks neat, unfortunately the dependency on AWS is a show
| stopper for many European companies these days.
| themanmaran wrote:
| Why is that? AWS has availability zones all around the globe,
| and 8 across the EU.
| turblety wrote:
| 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.
| growthwtf wrote:
| I wasn't aware either. Is GCP and Azure similarly viewed in
| the EU? You run out of cloud providers pretty quickly.
| jsiepkes wrote:
| 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.
| e1g wrote:
| +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.
| arccy wrote:
| 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.
| 52-6F-62 wrote:
| Never read Faust, huh?
| patcon wrote:
| 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
| ucarion wrote:
| We're aiming to abstract away our AWS dependencies -- KMS, S3,
| SES -- specifically to accommodate other clouds or non-clouds.
| lbhdc wrote:
| 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/
| junto wrote:
| 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...
| skpodila wrote:
| (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.
| dang wrote:
| https://news.ycombinator.com/item?id=43119777
| welder wrote:
| 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...
| NetOpWibby wrote:
| Thanks for sharing, your code looks good.
| _joel wrote:
| Looks nice, we've been using https://zitadel.com/ and the journey
| to mutli-tennancy was fairly straight forward.
| bithavoc wrote:
| 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
| ffo wrote:
| 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.
| chpatrick wrote:
| How does it compare to Keycloak?
| ucarion wrote:
| We're trying to offer a clear abstraction for specifically B2B
| SaaS. By taking opinions, we can make implementation quicker
| and easier for developers.
| chpatrick wrote:
| In what technical ways is that visible?
| ucarion wrote:
| 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]:
| import { useOrganizationSettingsUrl } from
| "@tesseral/tesseral-react"; const Example = ()
| => { const organizationSettingsUrl =
| useOrganizationSettingsUrl(); return <a
| href={organizationSettingsUrl}>Organization Settings</a>;
| }
|
| 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-...
| vanschelven wrote:
| In the Django world I just ran into this project with similar
| goals:
|
| https://github.com/leukeleu/django-hidp
| dbunskoek wrote:
| 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.
| tjko wrote:
| 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!
| vivzkestrel wrote:
| keycloak, better-auth, supertokens and now this, i would love to
| know how it compares to the rest
| ljm wrote:
| 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.
| mickeyfrac wrote:
| 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.
| horsawlarway wrote:
| 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.
| arendtio wrote:
| 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.
| stuartjohnson12 wrote:
| 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.
| diqi wrote:
| What's so different about auth for B2B?
| ucarion wrote:
| 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.
| KaoruAoiShiho wrote:
| How does it compare to the other recent YC company Stack Auth?
| noleary wrote:
| 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.
| satyrnein wrote:
| 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".
| noleary wrote:
| (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_.
| nightpool wrote:
| 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.
| theogravity wrote:
| 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.)
| codegeek wrote:
| "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.
| hooverd wrote:
| Does this compete with IDMs with Sailpoint?
| noleary wrote:
| 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!
| hooverd wrote:
| 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.
| cyberax wrote:
| 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.
| aeneas_ory wrote:
| Congrats on the launch Ulysse - impressive what you have been
| able to spin up with limited resources! Greetings from Ory :)
___________________________________________________________________
(page generated 2025-05-28 23:00 UTC)