Authenticate users through a self-hosted Keycloak realm.
Enterprise identity
Auth.js · Const
Keycloak is a built-in Auth.js OpenID Connect provider. Add it to the providers list and configure the client ID, secret, and realm-specific issuer.
Auth.js provides a built-in OpenID Connect integration for Keycloak. Register the provider in your Auth.js configuration, supply its client ID, secret, and realm-containing issuer through environment variables or explicit options, and configure Keycloak to use the matching callback URL.
Keycloak(options?: OIDCUserConfig<P>)| Name | Type | Description |
|---|---|---|
options | OIDCUserConfig<P> | Provider options, including OIDC client configuration such as client ID, client secret, and issuer. |
A configured Keycloak provider definition suitable for the Auth.js providers array.
AUTH_KEYCLOAK_ID, AUTH_KEYCLOAK_SECRET, and AUTH_KEYCLOAK_ISSUER./api/auth/callback/keycloak.import NextAuth from "next-auth"
import Keycloak from "next-auth/providers/keycloak"
export const { handlers, auth, signIn, signOut } = NextAuth({
providers: [Keycloak],
})Register the built-in provider; Auth.js reads the Keycloak client settings from the documented environment variables.
Enterprise identity
Next.js application
OIDC integration
Keycloak is configured as a built-in Auth.js provider using Keycloak in the providers list. The provider follows OpenID Connect and can infer its settings from AUTH_KEYCLOAK_ID, AUTH_KEYCLOAK_SECRET, and AUTH_KEYCLOAK_ISSUER.
Follow-up: What must the issuer value contain? It must include the Keycloak realm, such as /realms/My_Realm.
The callback path is /api/auth/callback/keycloak in the documented example. The exact externally reachable URL must match the callback configured for the Keycloak client.
Follow-up: What should be checked if sign-in returns a redirect error? Compare the configured callback URL and issuer realm with the Keycloak client configuration.
The provider accepts an OIDCUserConfig<P> options object when called directly. Explicit configuration can provide clientId, clientSecret, and issuer, while the built-in provider can use the documented environment variables.
Follow-up: When would explicit options be useful? Use them when the defaults inferred from environment variables need to be overridden.
OIDCUserConfigOAuth providerscustomizing a built-in OAuth providerAUTH_KEYCLOAK_IDAUTH_KEYCLOAK_SECRETAUTH_KEYCLOAK_ISSUER