How We Handled Authentication and RBAC Across a Full-Stack Fintech SaaS

Quick Summary

Introduction

Authentication and authorization form the foundation of every software platform, yet they are often built quickly and revisited only when problems appear. Early in a product’s life, the access rules tend to be simple and easy to manage. As the platform adds features and onboards more customers, those rules grow more complex, and the original design starts to show its limits. In many cases, the layer that controls identity and permissions becomes both critical to the business and difficult to maintain.

This challenge is more pronounced in financial software, where the cost of weak access control is high. According to the 2025 Verizon Data Breach Investigations Report, stolen credentials were the initial vector in 22 percent of breaches, and access-related weaknesses remain one of the most common entry points for security incidents. That pattern is hard to ignore for any platform in financial services. For a platform that processes payments and stores regulated data, the authentication and RBAC layer is a core security concern rather than a background detail.

A US fintech client engaged our team to address exactly this problem. Their platform functioned well for day-to-day users, but its permission checks, tokens, and roles had degraded as the business scaled. This insight explains how we rebuilt authentication and RBAC across a full-stack fintech SaaS already running in production. It outlines the issues we identified, the trade-offs we evaluated, the architecture we selected, and the results the client measured after the new layer went live

Where Access Control Was Breaking in the Live Fintech Platform

The authentication and RBAC design had grown feature by feature, and the access rules had expanded with it in an unplanned way. Most permission checks lived in the React frontend, so anyone who opened the browser console could see menu items and API routes meant to stay hidden. In a handful of cases, that same user could call those protected routes directly without any server-side objection. The backend was trusting the client to enforce rules that only a server should ever enforce.

Tokens were the next weak point, and they created a similar kind of exposure. Access tokens were signed JWTs with a lifetime measured in hours, and there was no reliable way to revoke one before it expired. A leaked token therefore stayed valid until it timed out, which is hard to defend for a money-moving application. Refresh handling was inconsistent as well, so some sessions silently outlived the access their owner was meant to have.

The roles themselves were far too coarse for a product handling regulated financial data. The system offered an admin role, a standard user role, and very little structure in between those two extremes. That gap forced the team to grant more access than most jobs needed, simply to let people work. For a full-stack fintech SaaS holding financial records, that mix of client-side checks, long-lived tokens, and broad roles was the real exposure.

Key Factors We Evaluated Before Touching the Full-Stack Fintech SaaS

Before touching the authentication and RBAC layer, we mapped every constraint the rebuild had to respect. A fintech platform in production cannot pause for a security project, and each change had to survive an external audit. Three factors ended up shaping almost every decision we made from that point forward.

Existing Role Sprawl and Permission Debt

Over roughly two years, the team had added roles and one-off permission flags whenever a customer requested something specific. The outcome was a clear case of role sprawl that nobody had planned for. We counted more than a dozen overlapping roles and a scatter of boolean flags that no single person could fully explain.

Some of those permissions contradicted each other, and a few were never actually enforced anywhere in the code. This permission debt meant we could not simply copy the old rules into a new system. Instead, we rebuilt the model from the real job functions users performed, then retired every flag that no longer mapped to anything.

Compliance Requirements: SOC 2 and PCI DSS

The client was preparing for a SOC 2 Type II audit and already handled cardholder data under PCI DSS. Both frameworks care deeply about who can reach which resources, and about the reason for that access. PCI DSS Requirement 7 states plainly that access should follow need-to-know and least-privilege principles.

Our authentication and RBAC model therefore needed to align with a recognized standard rather than an internal habit. We grounded it in the NIST model for role-based access control, where permissions attach to roles and roles attach to users. That reference gave the auditors a clear standard to check against and gave our engineers a structure they could reason about.

Session Handling and Token Security Gaps

Session security was the third factor, and it proved just as decisive as the other two. Long-lived tokens with no revocation path are a well-known problem, and they are hard to justify in any fintech audit. We needed short access windows, immediate session invalidation after a compromise, and refresh behavior that could not be replayed. That requirement made the token design something to settle first, since every authorization check depends on a token the backend can genuinely trust.

Why We Rebuilt Authentication and RBAC instead of Patching it

Patching the system was a real option, and we weighed it carefully before deciding against it. We could have moved a few checks to the backend, shortened token lifetimes, and called the result an improvement. The trouble was that the problems were structural and tightly connected to one another. Client-side checks, coarse roles, and unrevocable tokens were not three separate bugs to squash. They were all symptoms of one design where the frontend held authority that clearly belonged on the server.

A patch would have left that flawed design fully intact beneath the new surface. Every new feature would have inherited the same weak assumptions, and each audit would have surfaced the same findings again. Rebuilding authentication and RBAC as one backend-owned layer let us fix the root cause a single time.

The effort also gave us a clean place to add the audit logging that the SOC 2 work required. For a full-stack fintech SaaS meant to run for years, removing an entire class of risk was worth the higher initial cost, which is why teams hire SaaS developers to get the access model right from the start.

The Access Control Architecture and Tech Stack We Chose

For a full-stack fintech SaaS, we centralized identity in one dedicated place instead of spreading it across several services. The stack was deliberately ordinary, and the value came from combining these parts so that access across the full-stack SaaS had a single owner and one source of truth.

• Authentication (Node.js): A dedicated Node.js module issued short-lived JSON Web Tokens with a 15-minute access window, keeping any single token useful for only a brief period.
• Session handling (Redis): Refresh tokens rotated on every use and lived in httpOnly, secure cookies rather than browser storage, and a Redis revocation list let us end any session on demand.
• Authorization (Express): Express middleware checked each request against the caller’s roles before any handler ran, so every real decision stayed on the server side.
• Frontend (React): The React frontend kept its display logic only, hiding controls a user could not use without acting as a security boundary.
• Data and Tenant Isolation (PostgreSQL): Roles, permissions, and their mappings lived in PostgreSQL, which also anchored tenant isolation through row-level security keyed on tenant identity.
• Credential Security (bcrypt, MFA): Passwords used bcrypt with a per-user salt, and multi-factor authentication became mandatory for every privileged role.

Combining these tools gave the authentication and RBAC layer one owner, one source of truth, and one place to audit.

Our Full-Stack SaaS Strategy for Rebuilding Authentication and RBAC

With the architecture agreed, we ran the rebuild across four deliberate and self-contained stages. Each stage could be released on its own, so the live full-stack fintech SaaS platform stayed available while the new layer gradually replaced the old one.

Step 1: Rebuild Authentication and Tokens

The authentication and RBAC rebuild began with login and tokens, because everything else depends on them. The new flow issued a short access token and a rotating refresh token at the moment of sign-in. The frontend no longer stored tokens in local storage, which closed a common cross-site scripting exposure. On each refresh, the backend checked the token against the Redis revocation list and then rotated it. We also added forced logout on password change and a firm cap on concurrent sessions per account. This stage ran beside the old login for a short window, so users moved across without a hard cutover.

Step 2: Rebuild the Role Model

The role hierarchy sits at the center of any working authentication and RBAC model, so we rebuilt it entirely. Rather than copying the old set, we listed the tasks users actually performed and grouped them into clear permissions. Those permissions then attached to a small number of well-defined roles that reflected genuine responsibilities. A hierarchy let senior roles inherit junior permissions without duplicating any rules across the system. We stored the whole model as data instead of code, so a new permission became a database change and an audit entry rather than a deployment.

Step 3: Enforce Authorization on the Backend

With the new roles defined, we moved authorization enforcement completely onto the backend server. Every API route now passed through middleware that resolved the caller’s permissions before any business logic ran. The frontend still hid controls a user could not use, but that behavior became a convenience rather than a boundary. If someone tampered with the client, the backend still refused the request without hesitation. We wrote these checks once inside a shared layer, so every endpoint inherited the authentication and RBAC enforcement by default.

Step 4: Isolate Tenants and Limit Privilege

The final stage of the authentication and RBAC rebuild locked down the tenant boundaries a multi-tenant SaaS depends on. PostgreSQL row-level security policies keyed on tenant identity, so a query for one customer could never return another customer’s records.

We paired that isolation with least privilege at the database level, granting the application role only what it truly needed. Service accounts were scoped in the same restrictive way across the platform. By this point, a user’s reach was defined in three reinforcing places at once: the role, the backend check, and the row-level policy. Breaking any single control on its own would no longer expose customer data.

What Changed After Re-architecting Authentication and RBAC

The authentication and RBAC rebuild produced measurable changes against the client’s own baseline. The figures below reflect the delivered rebuild and must be confirmed against the client’s final audit records before publishing.

The numbers tell a consistent story about the full-stack fintech SaaS after the rebuild. The clearest signal was the audit result, where open access-control findings fell to zero and the SOC 2 assessment cleared those criteria without repeating an earlier exception. Token exposure narrowed sharply once the access window dropped to fifteen minutes and every session became revocable on demand. Moving all permission checks to the backend closed the client-side gaps that an attacker could previously reach through the browser. The leaner role model also eased daily work, since support handled fewer permission tickets and engineers could add a role in minutes rather than staging a release. None of these gains slowed the product, because cached role lookups kept the per-request cost low and predictable.

Lessons for Teams Securing a Multi-tenant SaaS

A few lessons from this authentication and RBAC rebuild apply to any team building a fintech SaaS product, not only this one. Treat the frontend as a display layer and nothing more, because any security decision made in the browser can be unmade by an attacker. Model roles from real job functions rather than from feature requests, since roles built one customer ask at a time turn into debt within a year.

Make tokens short and revocable from day one, because retrofitting revocation into a live system is harder than building it in. Put tenant isolation in the database and not only in application code, so a single missed check does not cross customer boundaries. Most teams do not fail here for lack of tools. They fail because access control is added in pieces and never owned as one system, and owning it as one layer is what makes it both auditable and safe to extend.

Conclusion