Skip to main content
Case Study · Platform Engineering

A Canonical Multi-Tenant Identity Platform

One identity and access layer across every Baalvion property — RS256 tokens, role-based access, and row-level tenant isolation.

Results

Many → 1
Login systems
RS256 only
Token scheme
Zero (verified)
Cross-tenant leaks

Technology Stack

  • RS256 JWT
  • RBAC
  • Row-level security
  • API gateway
  • Organisation model

The Challenge

Every Baalvion property had grown its own authentication: different login screens, different role models, and inconsistent token schemes — some using shared-secret signing that any service could forge. There was no single way to reason about who could access what, and tenant boundaries were enforced inconsistently across services.

The Solution

We built one canonical identity service for the entire group. It issues RS256-signed access tokens — services verify them with a public key and can never mint their own. A unified organisation-and-role model defines access centrally, and every tenant's data is isolated at the database layer with row-level security. This is the multi-tenancy discipline we describe in building multi-tenant SaaS.

  • One login across every property.
  • RS256 tokens so services verify without holding signing secrets.
  • Central RBAC with an organisation and role model.
  • Row-level security enforcing tenant isolation at the data layer.

Architecture

A central auth service authenticates users and issues asymmetric-signed tokens carrying organisation and role claims. The API gateway validates tokens and forwards a tenant context that every downstream service uses to scope queries. At the database, row-level security policies fail closed — a query without the correct tenant context returns nothing. We verified isolation with adversarial cross-tenant probes, a practice covered in secure software development.

Technology Stack

RS256 JWTs, a role-based access model, row-level security for tenancy, an API gateway, and a shared organisation model — delivered through our enterprise software and technology consulting practices.

Results

Many login systems collapsed into one. The token scheme is now RS256-only, eliminating forgeable shared secrets. And adversarial testing confirmed zero cross-tenant data leakage across the platform.

Lessons Learned

Asymmetric signing was the key decision — services verify tokens without ever being able to forge them. Centralising authorization stopped each app reinventing access control inconsistently. And isolation is only real once you've tried to break it: adversarial cross-tenant tests turned an assumption into a guarantee.

Frequently Asked Questions

Why RS256 instead of a shared secret?+

With RS256, the auth service signs with a private key and every other service verifies with the public key — so no downstream service can forge a token, which a shared secret would allow.

How is tenant isolation enforced?+

At the database layer with row-level security policies that fail closed: a query lacking the correct tenant context returns no rows.

How was isolation verified?+

With adversarial cross-tenant probes that deliberately attempt to read another tenant's data and confirm it is impossible.

Does one identity layer hurt user experience?+

The opposite — users get a single sign-on across every property, while the platform gets one consistent place to reason about access.

More case studies

Achieve outcomes like these

Talk to our strategy team about how the Baalvion Operating System can power your next platform.