OAuth服务器与资源服务器分离时的用户注册及管理员建用户方案咨询

Great question—this is a common pain point when splitting OAuth and resource servers with separate databases. Let’s break down how to handle admin-initiated user registration smoothly, while keeping both systems in sync and secure.

Core Problem Recap #

Your admin dashboard creates users, but:

• The OAuth server needs the user’s credentials (username/password) to issue access tokens via Password Grant.
• The resource server needs the user’s role and business-related data to enforce permissions and serve API requests.
• Their databases are completely separate, so we need a way to sync user data between them without breaking security or consistency.

Recommended Solutions #

1. Web Server as a Central Coordinator (Most Straightforward) #

Have your admin dashboard’s web server act as the middleman: it first creates the user on the OAuth server, then syncs the user’s business data to the resource server. This keeps your integration points clean and gives you full control over the flow.

Step-by-Step Flow:

• Admin submits the new user form (username, password, role, email, etc.) on the dashboard.
• Web server validates the input, then calls an internal OAuth server endpoint to create the user (this endpoint should not be public).
• If the OAuth user creation succeeds, the web server calls an internal resource server endpoint to store the user’s role and other business data, linking it to the OAuth user ID.
• If either step fails, roll back the successful operation (e.g., delete the OAuth user if the resource server sync fails).

Example Code Snippets:

Web Server (PHP) - Handling Form Submission

// Capture form data
$userData = [
    'username' => $_POST['username'],
    'password' => $_POST['password'],
    'email' => $_POST['email'],
    'role' => $_POST['role'] // e.g., "editor", "viewer"
];

// Internal API key for authenticating between services
$internalApiKey = getenv('INTERNAL_SERVICE_API_KEY');

// 1. Create user on OAuth server
$oauthCreateUrl = 'https://your-oauth-server.internal/api/users';
$oauthHeaders = [
    "Authorization: Bearer {$internalApiKey}",
    'Content-Type: application/json'
];

$ch = curl_init($oauthCreateUrl);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($userData));
curl_setopt($ch, CURLOPT_HTTPHEADER, $oauthHeaders);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$oauthResponse = json_decode(curl_exec($ch), true);
curl_close($ch);

if (!isset($oauthResponse['user_id'])) {
    die('Failed to create user on OAuth server: ' . $oauthResponse['error'] ?? 'Unknown error');
}

// 2. Sync user data to resource server
$resourceCreateUrl = 'https://your-resource-server.internal/api/users';
$resourcePayload = [
    'oauth_user_id' => $oauthResponse['user_id'],
    'username' => $userData['username'],
    'role' => $userData['role'],
    'email' => $userData['email']
];

$ch = curl_init($resourceCreateUrl);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($resourcePayload));
curl_setopt($ch, CURLOPT_HTTPHEADER, $oauthHeaders);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$resourceResponse = curl_exec($ch);
curl_close($ch);

if ($resourceResponse === false) {
    // Rollback: Delete the OAuth user since resource sync failed
    $oauthDeleteUrl = "https://your-oauth-server.internal/api/users/{$oauthResponse['user_id']}";
    $ch = curl_init($oauthDeleteUrl);
    curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'DELETE');
    curl_setopt($ch, CURLOPT_HTTPHEADER, $oauthHeaders);
    curl_exec($ch);
    curl_close($ch);

    die('Failed to sync user to resource server; rolled back OAuth user creation');
}

// Success!
echo 'User created successfully.';

OAuth Server (Slim Framework) - Internal User Creation Endpoint

$app->post('/api/users', function (Request $request, Response $response) {
    // Validate internal API key
    $authHeader = $request->getHeaderLine('Authorization');
    $validApiKey = getenv('INTERNAL_SERVICE_API_KEY');
    if (!str_starts_with($authHeader, 'Bearer ') || substr($authHeader, 7) !== $validApiKey) {
        return $response->withStatus(403)->write('Forbidden: Internal access only');
    }

    $data = $request->getParsedBody();
    // Hash password immediately (never store plaintext!)
    $hashedPassword = password_hash($data['password'], PASSWORD_DEFAULT);

    // Insert into OAuth server's users table
    $pdo = $this->get('db');
    $stmt = $pdo->prepare('INSERT INTO users (username, password_hash, email) VALUES (?, ?, ?)');
    $stmt->execute([$data['username'], $hashedPassword, $data['email']]);

    return $response->withJson([
        'user_id' => $pdo->lastInsertId(),
        'username' => $data['username']
    ]);
});

Resource Server (Slim Framework) - Internal User Sync Endpoint

$app->post('/api/users', function (Request $request, Response $response) {
    // Validate internal API key
    $authHeader = $request->getHeaderLine('Authorization');
    $validApiKey = getenv('INTERNAL_SERVICE_API_KEY');
    if (!str_starts_with($authHeader, 'Bearer ') || substr($authHeader, 7) !== $validApiKey) {
        return $response->withStatus(403)->write('Forbidden: Internal access only');
    }

    $data = $request->getParsedBody();
    // Insert into resource server's user table (stores role/business data)
    $pdo = $this->get('db');
    $stmt = $pdo->prepare('INSERT INTO app_users (oauth_user_id, username, role, email) VALUES (?, ?, ?, ?)');
    $stmt->execute([$data['oauth_user_id'], $data['username'], $data['role'], $data['email']]);

    return $response->withStatus(201)->write('User synced successfully');
});

2. Resource Server Triggers OAuth Sync (Alternative) #

If you want to reduce the web server’s responsibilities, you can have the admin dashboard call the resource server first. The resource server then creates the user in its database, and immediately calls the OAuth server’s internal endpoint to create the credentials.

This works well if your resource server is the source of truth for user roles, but you’ll still need to handle rollbacks (e.g., delete the resource server user if OAuth creation fails).

3. Background Sync with Webhooks (For Loose Consistency) #

For scenarios where strict real-time sync isn’t critical, you can have the OAuth server send a webhook to the resource server whenever a user is created. However, since your users are admin-initiated, this is less ideal than the first two options—you’d still need the web server to trigger the OAuth user creation first.

Critical Best Practices #

• Secure Internal Endpoints: Use strong API keys, IP whitelisting, or mutual TLS to ensure only trusted services can call these internal endpoints. Never expose them to public users.
• Password Security: Always hash passwords on the OAuth server immediately after receiving them. Never transmit plaintext passwords unless using HTTPS (which you should be doing anyway).
• Consistency & Rollbacks: Implement retry logic or rollback procedures for failed syncs. For example, if the resource server sync fails, delete the OAuth user to avoid orphaned records.
• Dual-Way Sync: Don’t forget about updates/deletes! If an admin changes a user’s password or deletes a user, you’ll need to sync those actions to both servers.
• Bulk Sync as a Safety Net: Add a daily cron job that compares user lists between the two servers and fixes any discrepancies (e.g., missing users, mismatched roles).

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