[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 : 188 points
Date : 2025-05-28 15:27 UTC (1 days 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
| skpodila wrote:
| that's fair. My apologies. Happy to remove it.
| 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-...
| exceptione wrote:
| SCIM is on the roadmap for Keycloak. 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.
|
| -> https://access.redhat.com/solutions/5065271
| 3abiton wrote:
| I don't really understand the main difference advantage,
| except that you offer better support for business.
| 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.
| rick1290 wrote:
| this looks interesting - launching a new app soon and in the
| middle of setting up auth. looking forward to learning more!
| 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.
| perrygeo wrote:
| > 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.
| noworriesnate wrote:
| 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.
| 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.
| mike_d wrote:
| > 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.
| ucarion wrote:
| 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...
| 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.
| Aeolun wrote:
| 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.
| nightpool wrote:
| > 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.
| 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.
| ezekg wrote:
| 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.
| tmaier wrote:
| 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.)
| 2Gkashmiri wrote:
| 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.
| Moto7451 wrote:
| 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.
| 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.
| sandeepkd wrote:
| 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.
| cyberax wrote:
| 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.
| aeneas_ory wrote:
| Congrats on the launch Ulysse - impressive what you have been
| able to spin up with limited resources! Greetings from Ory :)
| ucarion wrote:
| Thanks Aeneas!
| d0100 wrote:
| 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
| noleary wrote:
| 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.
| aeneas_ory wrote:
| 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.
| nodesocket wrote:
| 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.
| warthog wrote:
| Seems python support is there. Would appreciate a Django
| walkthrough as well. Clerk, Betterauth and others mostly skip
| Django for some reason
| ucarion wrote:
| Django is in the works! As is Laravel and Rails (my first
| love).
| danenania wrote:
| 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.
| ucarion wrote:
| 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.)
| danenania wrote:
| Oh nice, that seems ideal. Good stuff.
| philbo wrote:
| Have you had a pen test yet?
| grahamgooch wrote:
| 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?
| isaachinman wrote:
| Have a look at Authkit.
___________________________________________________________________
(page generated 2025-05-29 23:02 UTC)