Modern Authentication Is an Architecture Decision, Not a Feature

Every application eventually needs to answer the same two questions: Who is this user? and What are they allowed to do? These questions sound simple. The decisions behind them are not.

Authentication and authorisation are two distinct problems that are frequently conflated — and that conflation is the source of most security vulnerabilities in custom software. Getting this architecture right from the start is far cheaper than retrofitting it later, when users, data, and integrations are already in production.

Authentication vs Authorisation — The Distinction That Matters

Authentication is the process of verifying identity. It answers the question: is this person actually who they claim to be? A login form with a password check is authentication. So is Google Sign-In. So is a fingerprint prompt on a mobile device.

Authorisation is the process of controlling access. Once we know who the user is, what are they permitted to do? Can they view this invoice? Can they edit this record? Can they access the admin panel? These are authorisation questions.

Building secure software requires treating these as separate, independent layers — each with its own implementation strategy, its own tokens, and its own failure modes. Systems that conflate the two tend to have subtle but serious access control gaps that only become visible when exploited.

Why OAuth 2.0 Has Become the Industry Standard

OAuth 2.0 is the protocol that powers authentication and authorisation for most modern software — from consumer apps to enterprise platforms. It is not a login system. It is a framework for delegating access: a structured way for users to grant an application limited, controlled access to their data or identity without sharing passwords.

It is the protocol behind every "Sign in with Google" button, every "Connect your Stripe account" flow, and every "Authorise this app" prompt you have encountered. It solves a problem that is deceptively hard:

• How does a third-party app access your calendar without knowing your Google password? OAuth 2.0. The user consents, Google issues a scoped token, the app uses that token — your password never leaves Google.
• How does a mobile app call your backend API securely without storing credentials on the device? OAuth 2.0 with PKCE — a flow specifically designed for environments where secrets cannot be stored safely.
• How does a background service authenticate to another internal service without any user involved? OAuth 2.0 Client Credentials grant — machine-to-machine authentication with no user session required.

Each of these scenarios requires a different grant type — a different flow through the protocol. Choosing the wrong grant for the context introduces security vulnerabilities. Choosing the right one is an architectural decision.

OpenID Connect: The Identity Layer on Top

OAuth 2.0 handles access delegation. But it does not, by itself, tell you who the user is. That is the role of OpenID Connect (OIDC) — a thin identity layer built on top of OAuth 2.0 that allows applications to authenticate users and retrieve basic profile information: name, email address, profile picture.

When your application shows a "Sign in with Google" button and greets the user by name, that is OpenID Connect at work. The application never stores a password. It never handles credentials directly. Google — the identity provider — asserts that this user is who they claim to be, and your application trusts that assertion.

Delegating identity verification to a trusted, purpose-built provider is meaningfully more secure than managing credentials in-house, and significantly reduces the compliance surface for regulations like GDPR and SOC 2.

Tokens: What They Are and Where They Live

OAuth 2.0 issues different types of tokens for different purposes. Understanding the distinction is essential for building a system that is both secure and usable.

• Access Token A short-lived credential that grants access to specific resources. It should live in application memory — not in localStorage or a cookie — to minimise exposure. Typically expires within minutes to an hour.
• Refresh Token A long-lived credential used to obtain new access tokens without requiring the user to re-authenticate. Because it is more powerful, it should be stored server-side — never in the browser. Treat it with the same sensitivity as a password.
• ID Token (OIDC) A structured JSON Web Token (JWT) containing verified claims about the user's identity — who they are, not what they can access. Used to establish a session, then discarded.

Where tokens are stored and how long they live directly affects your security posture. These decisions compound: a system that stores refresh tokens in the browser is one XSS vulnerability away from a complete account takeover.

The PKCE Pattern: Security for Public Clients

Single-page applications and mobile apps present a specific challenge: they run on the user's device, which means any secret embedded in the code can be extracted. You cannot safely store a client secret in a browser-side React application or a native mobile app.

PKCE — Proof Key for Code Exchange — is the solution. Rather than relying on a stored secret, it generates a one-time cryptographic challenge for each authentication attempt. Even if an attacker intercepts the authorisation code, they cannot exchange it for tokens without the corresponding verifier, which only the legitimate client holds.

PKCE is now the recommended approach for all public clients — SPAs, mobile apps, and desktop applications. Applications still using the older Implicit Grant for these contexts have outdated, less secure authentication architectures and should be migrated.

Enterprise Authentication: Beyond Individual Users

Products sold to businesses face a different set of authentication requirements. Enterprise clients expect to use their existing identity infrastructure — Microsoft Active Directory, Okta, Google Workspace — to manage user access to your product. They do not want to maintain a separate set of credentials in each SaaS tool their employees use.

This is where Single Sign-On (SSO) becomes a commercial requirement, not just a technical preference. A B2B product without SSO support frequently hits a ceiling with enterprise deals — IT and security teams will not approve a tool for company-wide rollout if it falls outside their identity management perimeter.

OAuth 2.0 and OIDC are the protocols that make SSO work across modern systems. Designing the authentication layer with enterprise federation in mind from the start — even if SSO is not launched on day one — prevents an expensive architectural rewrite when that first enterprise client asks for it. And they will ask.

When to Build vs When to Buy

One of the most consequential decisions in authentication architecture is whether to implement the OAuth 2.0 server yourself or delegate to a managed identity provider. The answer is almost always to delegate — but understanding why matters.

• Managed providers (Auth0, Okta, AWS Cognito, Supabase Auth) Handle protocol implementation, token management, MFA, brute-force protection, compliance, and enterprise federation. Appropriate for the vast majority of custom applications. Fast to implement and maintained by dedicated security teams whose sole focus is keeping this infrastructure safe.
• Custom OAuth server implementation Reserved for platforms that are themselves identity providers — companies building products where other applications authenticate against their server. Significantly more complex to build and requires ongoing security expertise to maintain safely over time.

The risk of building authentication in-house is not the initial implementation — it is the ongoing maintenance. Security vulnerabilities are discovered continuously. A managed provider absorbs that operational burden. A custom implementation means your team owns it indefinitely.

Authentication Is Not a Checkbox

Authentication is one of the highest-stakes components in any application. A misconfigured token strategy, an incorrect grant type, or a poorly scoped permission model can expose user data, enable account takeover, or create compliance liabilities — often with no visible indication that anything is wrong until it is too late.

The decisions made at the start of a project — which grants to use, where tokens live, how sessions are managed, how enterprise federation is handled — define the security ceiling of the entire system. That ceiling is expensive to raise once users and data are in production.

Getting It Right From the Start

Whether you are building a new product, migrating an existing application to a modern authentication model, or preparing for enterprise sales that require SSO — authentication architecture is one of the first and most important conversations to have.

If you want to get this right before it becomes a problem, get in touch. We have designed and implemented production authentication systems across a range of stacks and product types — and we can help you figure out exactly what yours needs.