Debug School

rakesh kumar
rakesh kumar

Posted on

End-to-End SSO Architecture with Google Login, Keycloak, Laravel Middleware, and Cross-Domain Logout

Introduction
Core Components of the Architecture
Authentication Flow (Login)
Middleware-Based Auto Login
Cross-Domain Session Control
Global Logout Architecture
Own Client Logout vs Peer Logout
Security Principles Behind the Design
Benefits of This Architecture

Introduction

Modern applications rarely live in isolation. Organizations often operate multiple web applications across different domains, all serving the same users. Requiring users to log in separately to each application leads to poor user experience, security risks, and operational complexity.

To solve this, we implement Single Sign-On (SSO) — a system where users authenticate once and gain access to multiple applications seamlessly.

This document explains a real-world, end-to-end SSO architecture built using:

Google OAuth for user-friendly authentication

Keycloak as the central identity provider (IdP)

Laravel applications acting as service providers

Middleware-based auto-login

Cross-domain token exchange

Global (broadcast) logout

The architecture focuses on security, scalability, and domain isolation, while still providing a smooth user experience.

Core Components of the Architecture

Google OAuth (User Authentication Layer)

Google OAuth acts as the external authentication mechanism.
It answers one simple question:

“Is this user who they claim to be?”
Enter fullscreen mode Exit fullscreen mode

Key responsibilities:

Provides a trusted login mechanism

Handles identity verification

Returns verified user attributes (email, name)

Google OAuth does not manage sessions across your applications — it only authenticates the user once.

  1. Keycloak (Central Identity Layer)

Keycloak sits at the heart of the architecture as the Identity Provider (IdP).

Its responsibilities include:

Managing realms, clients, and roles

Issuing access tokens

Validating tokens (introspection)

Acting as a central authority for identity trust

In this system:

Keycloak is not the UI login page

It operates behind the scenes

Laravel apps interact with it server-to-server

Keycloak becomes the single source of truth for identity and authorization.

  1. Laravel Applications (Service A, B, C…)

Each Laravel application represents an independent service:

Separate domain

Separate database

Separate user sessions

Separate cookies

Despite this separation, all services trust Keycloak-issued identity.

Roles of Laravel apps:

Maintain local user records

Store token references

Enforce authorization rules

Manage sessions

Authentication Flow (Login)

Step 1: User Logs In Using Google

The authentication journey starts when the user clicks “Login with Google” in the primary application (Service A).

Google authenticates the user

The application receives verified user information

A local Laravel session is created

At this stage:

The user is logged into one application only

Other applications are unaware of this login

Step 2: Synchronization with Keycloak

After local login, the application synchronizes the user with Keycloak.

Key actions:

Ensures the user exists in Keycloak

Obtains Keycloak-issued tokens

Stores token metadata securely in the database

This step establishes federated identity trust:

Google proves who the user is

Keycloak becomes the authority for all services

Step 3: Broadcasting Authentication to Other Domains

Once authenticated, the browser triggers a controlled broadcast to peer applications.

This broadcast:

Sends minimal identity context (email reference)

Does not expose sensitive credentials

Triggers identity setup in other domains

Each peer application:

Resolves the user locally

Establishes its own Keycloak trust

Sets its own secure authentication cookie

This preserves:

Domain isolation

Independent sessions

Shared identity trust

Middleware-Based Auto Login

Why Middleware Is Critical

Users should not manually log in again when visiting another application.

This is handled by Laravel middleware, which runs before protected routes.

What the Middleware Does

On every request:

Reads the authentication cookie

Validates the token structure

Checks token validity (expiry, issuer, audience)

Extracts user identity

Confirms the token has not been revoked

Automatically logs the user into Laravel

The middleware acts as a security gatekeeper:

Prevents expired or forged tokens

Ensures revoked sessions cannot reappear

Maintains stateless verification logic

This design enables transparent SSO without sharing sessions across domains.

Cross-Domain Session Control

Token Storage as a Kill Switch

Each application stores token references in its own database.

This allows:

Centralized revocation

Session invalidation

Protection against replay attacks

Even if a browser still holds a cookie:

Middleware checks database state

Revoked tokens are immediately rejected

This ensures logout consistency and security.

Global Logout Architecture

Why Logout Is Hard in SSO

Logout is more complex than login because:

Multiple applications are involved

Sessions exist across domains

Browsers enforce cookie isolation

A simple local logout is insufficient.

Broadcast Logout Strategy

When a user logs out:

A browser-side broadcast notifies all peer applications

Each application:

Revokes its local token

Destroys its session

The originating application performs its own logout

This ensures:

No application remains authenticated

No stale session survives

User trust is maintained

Own Client Logout vs Peer Logout

The architecture distinguishes between:

Own client logout
The application where the logout originated

Peer logout
Other applications that must also revoke access

Both paths:

Clear token records

Destroy sessions

Prevent re-authentication via middleware

Security Principles Behind the Design

This architecture follows key security principles:

Zero Trust between services

No shared sessions

Token-based authentication

Database-backed revocation

Minimal data exchange

Defense-in-depth via middleware

Each application can independently enforce security without relying on others.

Benefits of This Architecture

Seamless user experience

Strong security boundaries

Scales across many domains

No cookie sharing hacks

Clear audit and revocation control

Easy to extend with roles and permissions

Conclusion

This end-to-end SSO architecture demonstrates how modern applications can implement secure, scalable, and user-friendly authentication across multiple domains.

By combining:

Google OAuth for user trust

Keycloak for identity authority

Laravel middleware for enforcement

Token-based session control

Broadcast logout for consistency

chatgpt

Top comments (0)