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://zitadel.com/blog/zitadel-v3-announcement

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.

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.

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.

Given that context, having other self-hosted options sounds like a good thing.

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.

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.

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.

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!

Contact info in my HN bio.

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.

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