多客户端OAuth2登录：凭证传递、客户端及API URL校验方案咨询

First, let's recap your setup to make sure we're aligned: you're building a multi-client system where each client has its own user base, uses OAuth2 Password Grant for login, and has unique client_id, client_secret, and API base URL (e.g., xyz.example.com/api/ for Client xyz). You're referencing Slack's workflow of validating workspaces first before showing login pages.

1. How do clients (mobile/web) validate the client identity and its API URL? #

Following the Slack-style workflow, here's a practical, scalable approach:

• Start with client/workspace identification: Ask users to input a unique identifier for their client (like the "xyz" in xyz.example.com or a custom workspace name).
• Use a centralized client discovery endpoint: Set up a public, trusted endpoint (e.g., https://your-platform-domain.com/discover-client) that accepts the client identifier as input. This endpoint will return:
  • The valid API base URL for that client
  • The associated client_id
  • (Optional) OAuth2 metadata (like the token endpoint URL) via {api_url}/.well-known/oauth-authorization-server to confirm the API is a legitimate OAuth2 server
• Validate the API URL: Once you have the API URL, call a lightweight check (like a /health endpoint or the OAuth2 metadata endpoint) to ensure the API is reachable and authorized.

This avoids hardcoding all client details in your app (which is inflexible) and ensures only approved clients are accessed.

2. How do clients get client_id and client_secret for login API validation? #

Critical rule: Never expose client_secret to frontend/mobile clients—these environments are not secure, and exposing secrets risks credential theft or abuse. Here's the right way to handle this:

• Web clients: Build a backend proxy layer. Your frontend will collect the user's username, password, and client identifier, then send these to your backend. Your backend uses the pre-stored client_id and client_secret for that client to make the OAuth2 password grant request to the client's API. It then returns the access token to the frontend.
• Mobile clients: Stick with the proxy approach too. Don't embed client_secret in your app bundle (it can be extracted easily with basic tools). Instead, your app sends user credentials + client identifier to your backend, which handles the OAuth2 request securely.
• If you must let mobile clients call the OAuth2 endpoint directly, switch to the Authorization Code Flow with PKCE instead of Password Grant—this eliminates the need for a client_secret in the mobile app while maintaining security.

3. How to pass client_id from server to client, and does the current scheme fit this scenario? #

Passing client_id securely #

As outlined in question 1, use the centralized client discovery endpoint:

• When the user inputs their client/workspace identifier, your client app calls this endpoint. The server returns the valid client_id (and API URL) for that client. This ensures the client only gets client_ids for approved clients, and you avoid the hassle of hardcoding values that might need to change later.
• For closed ecosystems with a fixed small set of clients, you could embed client_ids in the app—but this is not recommended for scalability (you'd have to push app updates if a client rotates their client_id).

Does your current scheme fit the scenario? #

Your core setup (multi-client with unique OAuth2 credentials) fits the business need, but the direct Password Grant from frontend/mobile needs adjustment:

• The Password Grant is designed for trusted clients (like your own backend services), not untrusted frontend/mobile apps. By adding the proxy layer and Slack-style discovery workflow, you adapt the scheme to be secure and scalable for multi-client use.
• The Slack-style workspace validation is a perfect fit here—it adds that first layer of client verification before users even enter their credentials, which aligns perfectly with your goal of separating user groups per client.

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