In modern application development, authentication often becomes a technical maze where tokens, cookies, and redirect flows coexist. Many teams meet this challenge by replicating generic recipes that, while working in controlled environments, collapse in the face of real threats. The key is not to choose a single technology—JWT, sessions, or OAuth—but to combine them as layers of a shield, similar to the defense-in-depth architecture used by critical systems. At Q2BSTUDIO, where we develop custom software for businesses, we understand that every application requires an authentication model that balances security, performance, and user experience.
The problem with monolithic solutions
For years, the usual approach was to store a JWT in localStorage or sessionStorage, relying on the frontend to send it on every request. However, any XSS vulnerability allowed that token to be mined and impersonated for days, as the tokens tended to have excessive validity. On the other hand, classic sessions, although secure against XSS (as they reside in httpOnly cookies), forced the server to maintain state, complicating horizontal scalability. This is where a layered approach proves its value.
The Three Layers of Modern Authentication
The first layer is the access token, usually a short-lived JWT (5-15 minutes). This token contains the claims required for the backend to validate the identity without querying a database. Being ephemeral, even if an attacker intercepts it, the damage is minimal. Ideally, you should keep it only in frontend memory (React state, JS variable) and never in script-accessible persistent storage.
The second layer is the refresh token, an opaque identifier that is stored in a cookie with the flags httpOnly, Secure, and SameSite=Strict. This cookie is only sent to the server when the access token needs to be renewed. The refresh token must be rotated: each time it is used, the old one is invalidated and a new one is issued. If an attacker manages to steal the cookie (which is difficult thanks to httpOnly), the rotation detects it because the token will have already been used by the legitimate one.
The third layer is OAuth 2.0, which outsources authentication to trusted providers (Google, GitHub, Azure AD). OAuth is not a session mechanism, but a delegation protocol. Secure deployment consists of performing the authorization flow on the backend, exchanging the code for vendor tokens, and then issuing our own access and refresh tokens. Thus, the frontend never handles the provider's credentials directly.
Sessions or JWT? No Choice
Sessions are still useful in server-side applications where persistent state is needed (for example, for CSRF). However, in microservices architectures or public APIs, JWTs allow stateless validation without relying on a centralized store. The optimal combination uses sessions for the traditional UI (with cookies) and JWT for API calls, supported by a backend that manages token renewal. In cloud environments, with AWS and Azure cloud services, this architecture is easily deployed using systems such as Redis for the invalidation of refresh tokens.
Practical implementation
An example with Express shows how to build this system. The login endpoint verifies credentials, generates a random refresh token (jti) stored in Redis with 30-day TTL, sends it as an httpOnly cookie, and returns a 5-minute JWT access token. The /token endpoint receives the cookie, verifies the jti in Redis, deletes it (rotation), issues a new refresh token and a new access token. The logout simply removes the jti from Redis. To secure paths, the middleware validates the access token with the corresponding public key.
If OAuth is integrated, the flow changes: the backend redirects the user to the provider, receives the authorization code, redeems it for a provider access token, obtains the user's identity, and then issues our own tokens as described. This way, the OAuth layer is only used for initial authentication, while session management remains the responsibility of the application.
Risk Management & Cybersecurity
This multi-layered model mitigates the most common attacks. XSS can no longer steal refresh tokens (httpOnly cookie). CSRF is prevented with SameSite=Strict and, if necessary, additional anti-CSRF tokens. The rotation of refresh tokens limits the window of a possible cookie theft. In addition, by using rotating secrets and storing them in environment variables (not in code), the impact of a repository leak is reduced.
For companies that need to protect sensitive data, Q2BSTUDIO offers cybersecurity and pentesting services that evaluate this type of architecture, identifying possible token leaks or insecure configurations in AWS or Azure. Likewise, using artificial intelligence to detect anomalous patterns in token usage (e.g., multiple renewals in a short time) can bolster defense.
Beyond Authentication: Business Intelligence and Automation
Once identity is secured, authentication usage data (when, where, how users access it) becomes a valuable source for business intelligence. For example, Power BI can use you to view metrics for logins, token renewal rates, or geographic access patterns. These dashboards allow you to detect suspicious behavior and optimize the user experience. In addition, AI agents can automate responses to security events, such as massively revoking tokens from a compromised session.
Conclusion
Authentication should not be a monolith, but an orchestration of mechanisms that complement each other. By combining JWT for quick access, refresh tokens in secure cookies, and OAuth for federated identity, a robust, scalable, and maintainable system is built. In custom applications developed by Q2BSTUDIO, we apply this philosophy by design, adapting it to the needs of each client, whether in the cloud with AWS and Azure cloud services, in cybersecurity environments, or by integrating business intelligence with Power BI. Because every layer counts, and only together do they build the Security Matrix that every application deserves.
.jpg)
.jpg)
.jpg)
.jpg)