基于Laravel5.6+Vue的多医疗应用共享登录与用户资料方案咨询

Hey there! Let's break down your problem step by step since you're working with three medical apps on Laravel 5.6 + Vue.js using JWT, wanting unified login and synced user profiles.

First off: using a single database for three medical apps is totally reasonable, especially for your core need of real-time user profile sync. Here's why:

• Built-in data consistency: All apps interact with the same users table. When a user updates their password or profile in any app, the changes are immediately reflected across all others—no extra sync logic needed, which is perfect for the strict data integrity requirements of the medical industry.
• Lower maintenance overhead: You avoid the complexity of managing cross-database sync mechanisms, reducing the chance of bugs or data discrepancies.
• Scalable with prep work: If user volume grows later, you can split business data into separate databases while keeping the core users table in the unified database, or add table sharding for the users table.

Just keep two things in mind:

• Permission isolation: Since the three apps likely have different business permissions, add an app_user_permissions table that links user_id to app_id to store role/permission data per app, preventing cross-app permission leaks.
• Database performance: Ensure proper indexing (e.g., on users.id, users.email) and consider read-write splitting if traffic is high—use the primary database for write operations (profile/password updates) and replicas for read operations (fetching user info).

With a single database, you can quickly build a unified user center without heavy refactoring:

1. Unified Authentication Entry #

• Pick one app as the main authentication service (or spin up a lightweight user center API), and route all login/registration/profile update requests from the three apps to this unified interface.
• Configure the same JWT_SECRET in the .env file of all Laravel apps so they can all validate the same JWT tokens.

2. JWT Login Flow #

• Frontend (Vue.js): Reuse the same login component across all three apps, which calls the unified login API. On success, store the JWT in localStorage or an HttpOnly cookie (cookies are more secure for auth tokens).
• Backend (Laravel): Use the tymon/jwt-auth package to handle JWT issuance. After successful login, return a token containing user_id, basic profile data, and expiration time. Other apps can validate the token with JWTAuth::parseToken()->authenticate() to fetch user info.

3. Profile Sync & Password Update Handling #

• Profile sync: Since all apps use the same users table, updating a user's name, phone number, etc., in any app directly modifies the table—other apps will pull the latest data on their next user info request.
• Invalidate old tokens after password changes: To prevent users from accessing apps with old tokens after a password reset, use the tymon/jwt-auth blacklist mechanism:

  // Add this to your password update endpoint
  $token = JWTAuth::getToken();
  JWTAuth::invalidate($token);
  

  Also, have the frontend clear the stored token and redirect the user to log in again.

4. Frontend State Sync #

• Add a storage event listener across all Vue apps to sync user state in real-time. For example, in a global Vue mixin:

  window.addEventListener('storage', (e) => {
    if (e.key === 'user_profile') {
      // Refresh the current app's user profile state
      this.$store.dispatch('fetchUserProfile');
    }
  });
  

  This way, when one app updates the user profile in local storage, others will automatically refresh their state.

If you need to deploy the apps independently later (e.g., separate teams, database splitting), SSO is a better fit. Here's how to share the user table in this setup:

1. Architecture Design #

• Build an independent SSO Identity Provider (IdP): This service manages the core users table, login authentication, and profile updates.
• Treat the three apps as Service Providers (SPs): They won't maintain their own user tables—only store a user's unique user_id and app-specific business data (like medical records, appointment info).

2. User Table Sharing Logic #

• All core user data (account, password, basic info) lives only in the SSO database. SPs fetch user profiles via APIs provided by the SSO service.
• Login flow: When a user visits an SP app, they're redirected to the SSO login page. After successful login, the SSO returns an authorization code. The SP uses this code to exchange for a JWT/session token, then calls the SSO API to fetch basic user data and stores it in local cache (e.g., Redis) to avoid frequent SSO API calls.

3. Profile Sync Mechanism #

• When a user updates their profile (either via SSO or an SP app), the request must go through the SSO's profile update API, which modifies the core user table.
• The SSO can use webhooks to notify all SPs: when a user's profile is updated, the SSO sends an event to each SP's designated endpoint, and the SP updates its local cached user data to keep things consistent.

• Stick with the single database solution for now: It's low-cost, ensures data consistency, and fully meets your current needs.
• Plan for SSO as a future step: If you need to scale or decouple the apps later, migrate to an SSO architecture where the core user table is managed by the IdP, and SPs sync data via APIs.

内容的提问来源于stack exchange，提问作者user6780526