能否弃用Keycloak用户管理？基于第三方非令牌系统生成令牌

Absolutely, this is totally feasible! You’re right that Keycloak’s out-of-the-box Identity Providers are focused on standard token-based protocols like OIDC and SAML, but there are custom approaches to integrate with non-token-based systems while avoiding storing user data in Keycloak’s database. Here’s how you can pull this off:

Option 1: Build a Custom Identity Provider #

This is the most direct approach, as it lets you hook Keycloak’s authentication flow directly into your third-party system’s validation logic without persisting users.

• How it works:
  1. Develop the custom provider: Create a Java class that implements Keycloak’s IdentityProvider and Authenticator interfaces (or extend AbstractIdentityProvider to skip boilerplate code). In this class, write logic to call your third-party system’s authentication endpoint (e.g., a REST API that validates username/password).
  2. Handle user validation: When a user attempts to log in, Keycloak triggers your custom provider, which sends the user’s credentials to the third-party system. If validation passes, construct a transient UserModel (Keycloak’s in-memory user representation) — this won’t get saved to Keycloak’s database.
  3. Deploy and configure: Package your provider as a JAR, drop it into Keycloak’s providers directory, and restart Keycloak. Then, in your target Realm, add the custom identity provider, configure settings like the third-party system’s API URL, and add it to your realm’s authentication flow.
  4. Enable Broker Only mode: Toggle the "Broker Only" setting for your provider — this ensures Keycloak never syncs or stores the user’s data locally.

Option 2: Use Direct Grant with a Middleman Service #

If building a custom Java provider feels too heavy, you can use a lightweight intermediate service to bridge your third-party system and Keycloak’s Direct Grant (Resource Owner Password Credentials) flow.

• How it works:
  1. Set up Keycloak client: Create a client in your Realm, enable the "Direct Grant Access" setting, and note the client ID/secret.
  2. Build the middleman service: Create a simple service (e.g., Spring Boot, Node.js) that accepts user credentials (username/password) from your application.
  3. Validate against third-party system: First, the middleman calls your third-party system’s validation endpoint to confirm the user is legitimate.
  4. Request token from Keycloak: If validation passes, the middleman uses the client credentials plus a unique user identifier (from the third-party system) to call Keycloak’s POST /realms/{realm}/protocol/openid-connect/token endpoint. Pair this with a read-only User Storage SPI that fetches user details on-demand from the third-party system (no local storage required) to avoid pre-creating users in Keycloak.

Key Notes #

• Always use HTTPS for all communication between Keycloak, your middleman service, and the third-party system to keep credentials secure.
• When constructing the transient user in the custom provider, populate token claims (like user roles, email, etc.) with data fetched from the third-party system to make the token useful for your applications.
• For refresh tokens, ensure your custom provider handles refresh requests by re-validating the user with the third-party system before issuing a new token.

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