The system we have designed follows a well-established and robust architectural pattern known as the Centralized Authentication Service or Identity Provider (IdP) Model.

It is a form of microservices architecture where the responsibility of user authentication is completely decoupled from your individual applications and handled by one authoritative service.

Here is a breakdown of this architecture and its components.

Core Components of the Architecture

1. Identity Provider (IdP):
   • This is your new auth.holidaylandmark.com application built with Laravel Passport.
   • It is the single source of truth for all user identities, credentials, and master login sessions.
   • It owns the master users database.
   • Its only job is to answer one question for other services: “Are these credentials valid?” and “Is this user currently logged in?”. It provides secure API endpoints (/login, /logout, /user) for this purpose.
2. Service Providers (SPs):
   • These are your five existing applications: the Laravel dashboard, the two Eventmie sites, the Flarum forum, and the WordPress blog.
   • In this architecture, the SPs no longer manage passwords. They become “clients” of the IdP.
   • They are responsible for protecting their own pages and resources, but they delegate the authentication decision to the IdP.
   • They still maintain a local users table, but it’s used primarily for local data relationships (e.g., to link a blog post to a user ID), not for authentication.
3. The SSO Cookie (The “Master Key”):
   • This is the technical mechanism that enables the seamless experience.
   • It is a standard HTTP cookie set by the IdP on the root domain (.holidaylandmark.com).
   • This scope makes it accessible to all your applications.
   • It is configured to be HttpOnly and Secure to prevent access from client-side scripts and to ensure it’s only transmitted over HTTPS.
4. The User’s Browser:
   • The browser acts as the passive carrier of the SSO cookie, automatically sending it with every request to any service on the holidaylandmark.com domain.

Key Architectural Principles

• Decoupling: Authentication logic is completely removed (decoupled) from the Service Providers. This means your blog doesn’t need to know how to securely hash and compare passwords; it only needs to know how to ask the IdP. This makes the client applications simpler and more secure.
• Centralization: All user management and security policies are centralized at the IdP. If you need to implement a new password policy (e.g., require longer passwords), you only have to change it in one place—the IdP—instead of five.
• API-Driven Communication: The entire system operates via secure, server-to-server API calls. This is what allows you to keep each service’s login page without redirecting to a central one. The communication is invisible to the end-user.
• Local User Provisioning: When a user logs in to a service for the first time via the IdP, a “stub” user profile is automatically created in that service’s local database. This process, called provisioning, ensures that local data integrity (e.g., foreign keys) is maintained.

Advantages of this Architecture

• Seamless User Experience: This is your primary requirement. Users log in once and gain access everywhere.
• Improved Security: By centralizing authentication, you concentrate your security efforts on one hardened service (the IdP) instead of defending five separate applications.
• Simplified Management: Managing your user base becomes much easier. A user’s account can be disabled or deleted from one central location.
• Scalability: It’s easy to add a sixth, seventh, or eighth service to this SSO system. You simply teach the new application how to speak to the IdP, without modifying any of the other existing applications.

Disadvantages of this Architecture

• Single Point of Failure: This is the most significant drawback. If your Central Auth Service (auth.holidaylandmark.com) goes down, no one can log in to any part of your platform. This service must be treated as mission-critical and hosted on high-availability infrastructure.
• Initial Complexity: As you’ve seen from the guides, retrofitting this architecture onto existing applications is a complex initial project, especially regarding data migration.