Is Supabase Auth Enough? When You Need Keycloak – and When You Don't

The question comes up in almost every project conversation once Supabase is set: “Do we even need Keycloak then?” My answer surprises many people: in the majority of cases, no. And I say that as someone who earns money setting up and running Keycloak.

For context on who is writing here: I am Matthias, a one-person agency called happycoding.agency in Berlin. I run both systems in production and have no contract with either vendor: what you read here is project experience, not a sales pitch.

That is exactly why I advise you against it when the need is missing. An identity server without a job to do is not an investment but ongoing effort without return: it wants to be patched, monitored, and touched on every major release, while your users simply want a login that works.

In this article I draw the line as precisely as my project experience allows: first what Supabase Auth can really do, then the four points where it ends. Plus a decision matrix and a reassuring finding at the end: if you have to switch later, you are not trapped.

First, the classification: Supabase Auth is not an add-on module but a fixed part of every Supabase project. There is no second service, no token synchronization between systems, no extra invoice. The Pro plan costs $25 per month and includes 100,000 monthly active users, MAU for short (source: Supabase pricing page, as of October 2026).

For the vast majority of B2C and SaaS applications, this list is complete. Registration, session management, and token refresh run through the same API you are working with anyway.

The most important advantage appears in no feature table: auth and database speak the same language. In Row Level Security policies, you read the user ID with auth.uid() and the full token with auth.jwt(). You store roles and permissions in app_metadata, and authorization happens in the database instead of in every API route separately.

An example from a customer portal: the rule “invoices are visible only to your own company” is one line of SQL against auth.jwt(), not a middleware stack across three services.

One trap is documented by Supabase itself: users can write to user_metadata on their own through the update function. If you build policies on it, you hand out privilege escalation at self-service prices. The rule to remember: authorization data belongs in app_metadata, without exception.

Here I clear up an outdated objection. “As soon as the first enterprise customer demands SAML, you need Keycloak”: that is no longer true. Supabase Auth supports SAML 2.0 from the Pro plan, with several identity providers in parallel. The Okta, Entra ID, or Google Workspace of your business customers can be connected directly.

The typical scenario: you build a portal for a mid-sized company whose biggest buyer is a corporate group. Their IT department demands that their purchasers sign in through the company's own Okta. This used to be where the Keycloak project started; today it is one configuration step per customer.

According to the Supabase pricing page (as of October 2026), 50 SSO MAU are included; after that, each active SSO user costs $0.015 per month. A B2B portal with 500 SSO users therefore pays around $6.75 extra per month. Enterprise SSO is no longer a budget question but an architecture question.

Staying honest means naming the rough edges too: single logout is missing, linking SSO identities to existing accounts is blocked for security reasons, IdP-initiated flows do not get along with PKCE, and you manage the providers via CLI. For most projects, these are footnotes. For what fundamentally separates the two protocols, read SAML vs. OIDC.

Now the other side of the ledger. With four requirements, I steer the project conversation straight toward Keycloak. What Keycloak is in the first place and how it works is covered in my Keycloak basics article; here it is purely about drawing the line.

If employees are supposed to sign in with their existing directory accounts, there is no way around user federation. Keycloak ships with built-in integration for LDAP and Active Directory servers, including synchronization of groups and attributes. Supabase Auth offers nothing here: no LDAP, no directory integration. In corporate and government projects, this is regularly the knockout criterion.

A typical case from an inquiry: 400 employees, group permissions from Active Directory, the internal IT department's password policy. Supabase Auth has no answer to that; Keycloak solves it through configuration.

Honesty includes a recent development: Supabase Auth can now act as an identity provider itself. The built-in OAuth 2.1 server issues OIDC tokens for third-party applications at no extra charge (as of October 2026). Two things it cannot do: issue SAML assertions for external systems and cleanly separate tenants.

Keycloak delivers both, as a SAML IdP and with separate realms per tenant. Realms are more than namespaces: each tenant gets its own login screen, its own password policies, and its own administrators. If your product sells exactly this separation, that is the Keycloak moment.

Supabase offers six Auth Hooks, for custom JWT claims or pre-registration checks, for example; the hooks for MFA and password checks require the Team plan. That covers a lot, but it ends at fixed extension points. Keycloak lets you assemble complete authentication flows and extend them with code: mandatory contract acceptance before the first login, step-up checks for sensitive actions, lookups against third-party systems. The project site explicitly calls this “Customize through code”.

Supabase runs in European regions such as Frankfurt or Zurich on request, and self-hosting via Docker exists. But: the self-hosted variant is limited to a single project, relies on community support, and lacks quite a few platform features. If your client contractually demands the identity server in their own data center, Keycloak is the grown-up answer: a CNCF incubating project since April 10, 2023, operable wherever you want.

The difference lies in the contracts: with the managed platform, Supabase remains your data processor, even if the data sits in Frankfurt. With self-operated Keycloak, the login infrastructure belongs to you, including logs, backups, and key material. Some tenders demand exactly that, and then no pricing argument helps.

The four limits come at a price, and that price is operations. Keycloak ships four minor releases per year, with major versions every two to three years; the current release is 26.8.0 from October 1, 2026 (as of October 2026). Every release wants to be installed, every configuration backed up, every upgrade tested.

Then there is the team question: running Keycloak means taking responsibility for a Java application plus database and cluster configuration. That is no dark art, but it is a different discipline from the Postgres world your Supabase project already lives in.

What that means in euros, from a single instance to an operations retainer, is broken down without ballpark prose in my article What does Keycloak really cost?. The short version: the license is free, the operations never are.

For orientation, I have condensed the most common constellations from my project conversations. Read the table as a starting point, not a verdict: if two rows apply to you at the same time, the stricter requirement wins.

Two rows deserve a comment. First: “business customers demand SSO” is no longer a Keycloak trigger, as long as it is about signing in to your own app. Second: the last row is the normal case in my project conversations, and the following section belongs to it.

The strongest argument for starting with Supabase Auth is technical, not price-based: the architecture keeps the door open. On request, Supabase signs tokens asymmetrically with ES256 or RS256 and publishes the public keys at a JWKS endpoint. External services verify your tokens without you having to share secrets.

The other direction works too: Supabase accepts external tokens. The third-party auth list officially names Clerk, Firebase Auth, Auth0, AWS Cognito, and WorkOS, billed at $0.00325 per third-party MAU (as of October 2026). Keycloak is not on this list, but it can be connected as an OAuth provider within Supabase Auth; since Keycloak 22, the openid scope belongs in the sign-in call.

Important for the database: if you attach Keycloak behind Supabase Auth as an OAuth provider, Supabase still issues the tokens. Your RLS policies with auth.uid() and auth.jwt() remain valid, unchanged. The switch happens at the front door, not in the foundation.

The realistic path: you start with Supabase Auth and RLS. If the LDAP requirement arrives in two years, you put Keycloak in front instead of rebuilding database and policies. Which systems would be candidates alongside Keycloak at that point is something I have worked through in my comparison of Keycloak alternatives.

Are you facing exactly this decision right now? Then check three items on your requirements list: directory integration, SAML issuance, hosting location. If none of them appears there, take Supabase Auth and invest the saved operations time in your product. How I set up and support Supabase projects is shown on my Supabase services page.

If you are unsure which row of the matrix applies to you: send me your requirements, and I will tell you honestly within 30 minutes whether Supabase Auth is enough. Sometimes the answer is yes, even though I would earn more with Keycloak: book a no-obligation intro call.