Error OAUTH_WWW_AUTHENTICATE_CHALLENGE al iniciar sesión mediante SSO OIDC personalizado (Oracle IAM) en v2.35.4

Preguntas
, ,
1

Después de configurar SSO, me encontré con el siguiente error al intentar iniciar sesión usando SSO. ¿Alguien ha experimentado un problema similar?

2026-08-26T08:08:46.663Z | error | Failed to exchange authorization code for tokens server responded with a challenge in the WWW-Authenticate HTTP Header {“code”:“OAUTH_WWW_AUTHENTICATE_CHALLENGE”,“file”:“oidc.service.ee.js”,“function”:“logTokenExchangeError”}
ResponseError: Invalid authorization code
at OidcService.loginUser (/usr/local/lib/node_modules/n8n/src/modules/sso-oidc/oidc.service.ee.ts:284:10)
at processTicksAndRejections (node:internal/process/task_queues:104:5)
at OidcController.callbackHandler (/usr/local/lib/node_modules/n8n/src/modules/sso-oidc/oidc.controller.ee.ts:144:29)
at handler (/usr/local/lib/node_modules/n8n/src/controller.registry.ts:115:12)
at /usr/local/lib/node_modules/n8n/src/controller.registry.ts:124:7
2026-08-26T08:08:48.586Z | debug | Heartbeat updated {“scopes”:[“instance-registry”],“file”:“instance-registry.service.js”}
2026-08-26T08:08:58.384Z | error | Failed to exchange authorization code for tokens server responded with a challenge in the WWW-Authenticate HTTP Header {“code”:“OAUTH_WWW_AUTHENTICATE_CHALLENGE”,“file”:“oidc.service.ee.js”,“function”:“logTokenExchangeError”}
ResponseError: Invalid authorization code
at OidcService.loginUser (/usr/local/lib/node_modules/n8n/src/modules/sso-oidc/oidc.service.ee.ts:284:10)
at processTicksAndRejections (node:internal/process/task_queues:104:5)
at OidcController.callbackHandler (/usr/local/lib/node_modules/n8n/src/modules/sso-oidc/oidc.controller.ee.ts:144:29)
at handler (/usr/local/lib/node_modules/n8n/src/controller.registry.ts:115:12)
at /usr/local/lib/node_modules/n8n/src/controller.registry.ts:124:7
2026-08-26T08:09:18.587Z | debug | Heartbeat updated {“scopes”:[“instance-registry”],“file”:“instance-registry.service.js”}
2026-08-26T08:09:23.377Z | error | Failed to exchange authorization code for tokens server responded with a challenge in the WWW-Authenticate HTTP Header {“code”:“OAUTH_WWW_AUTHENTICATE_CHALLENGE”,“file”:“oidc.service.ee.js”,“function”:“logTokenExchangeError”}
ResponseError: Invalid authorization code
at OidcService.loginUser (/usr/local/lib/node_modules/n8n/src/modules/sso-oidc/oidc.service.ee.ts:284:10)
at processTicksAndRejections (node:internal/process/task_queues:104:5)
at OidcController.callbackHandler (/usr/local/lib/node_modules/n8n/src/modules/sso-oidc/oidc.controller.ee.ts:144:29)
at handler (/usr/local/lib/node_modules/n8n/src/controller.registry.ts:115:12)
at /usr/local/lib/node_modules/n8n/src/controller.registry.ts:124:7
2026-08-26T08:09:44.879Z | debug | Querying database for waiting executions {“scopes”:[“waiting-executions”],“file”:“wait-tracker.js”,“function”:“getWaitingExecutions”}

¡Gracias!

2

Hola @yushaojian, mientras esperas una respuesta, aquí hay algunas cosas que podrían ayudarte:

Recursos sugeridos

Coincidencia automática con tu pregunta.

Documentación:

Foro:

@anon61017519, @Gustavo_Ariel_Recha, @tamy.santos - ya han ayudado con problemas similares antes, ¿pueden echar un vistazo?

Sugerido automáticamente por el bot comunitario de n8n. Es una versión piloto - por favor comparte tu opinión aquí.

3

¡Hola @yushaojian Bienvenido!
Un desafío WWW-Authenticate en el punto final del token es el proveedor de identidad rechazando la autenticación del cliente de n8n, no el código. n8n lanza “Invalid authorization code” (Código de autorización inválido) para cada intercambio de token fallido, por lo que esa cadena no es lo que Oracle devolvió.
Prueba las credenciales por su cuenta contra el mismo punto final:

curl -i -u '<client-id>:<client-secret>' -d 'grant_type=client_credentials' <token_endpoint from your discovery document>

Un 401 allí significa que Oracle rechaza el par de ID y secreto; cualquier otro estado significa que la autenticación del cliente pasó. Regenera el secreto en la aplicación confidencial, confirma que esté Activado con Authorization Code en Allowed Grant Types, luego vuelve a pegar ambos valores en Settings > SSO.

4

Gracias por tu apoyo.

El uso del comando resultará en el siguiente error:

HTTP/1.1 400
Date: Fri, 28 Aug 2026 06:47:46 GMT
Content-Type: application/json;charset=UTF-8
Content-Length: 105
Connection: keep-alive
X-Content-Type-Options: nosniff
Cache-Control: no-store
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Access-Control-Allow-Headers: *
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: *
Access-Control-Max-Age: 3600
Strict-Transport-Security: max-age=31536000; includeSubDomains;preload

{“error_description”:“The client is not authorized to use this grant type”,“error”:“unauthorized_client”}

Actualmente, IDP solo soporta modo code y no soporta modo client_credentials.

¿Cómo debo ajustar?

5

Ese 400 es la sonda teniendo éxito, no fallando. unauthorized_client es un error posterior a la autenticación, Oracle verificó el par de id y secret, lo aceptó, y solo entonces rechazó el tipo de concesión que la sonda estaba tomando prestado como verificación de credenciales. Tus credenciales son correctas, y n8n nunca usa client_credentials en su flujo de inicio de sesión, así que no hay nada que ajustar en el lado de la concesión.
La diferencia entre tu curl y n8n es dónde viaja el secret. Tu curl lo envió en el encabezado Authorization. n8n no pasa ningún método de autenticación de cliente a su biblioteca OIDC, y el descubrimiento de openid-client por defecto es client_secret_post, el secret como parámetro de cuerpo de formulario. El punto final de token de Oracle documenta autenticación de cliente a través del encabezado Basic Authorization, con un client_id en el cuerpo reservado para aserciones de cliente, así que trata el intercambio autenticado por cuerpo de n8n como no autenticado y responde con el desafío WWW-Authenticate de tu registro.
Confírmalo en tu dominio moviendo el secret al cuerpo:

curl -i -d 'grant_type=client_credentials' -d 'client_id=<client-id>' -d 'client_secret=<client-secret>' <token_endpoint>

Un desafío o 401 aquí, donde tu versión de encabezado obtuvo el 400, lo prueba. n8n no expone ninguna configuración para el método de autenticación del punto final de token, así que la corrección pertenece a n8n. Abre un problema (bug) en Issues · n8n-io/n8n · GitHub pidiendo que SSO OIDC admita client_secret_basic, e incluye ambos resultados de curl como evidencia.
openid-client/docs/functions/discovery.md at main · panva/openid-client · GitHub

6

¡Gracias por tu apoyo!

El bot de GitHub (asistente n8n) ha rechazado mi solicitud. ¿Puedo preguntarte si hay otras soluciones? ¡Por ejemplo, ajustar la configuración de Oracle IAM!

7

OIDC SSO es una función empresarial, y Enterprise autohospedado incluye soporte por correo electrónico con SLA para problemas técnicos, por lo que esto corresponde a help@n8n.io en lugar del rastreador de problemas público. Envíales tanto los resultados de curl como las líneas de registro de tu primer mensaje.
Antes de eso, el documento de descubrimiento que n8n ya lee te indicará si Oracle tiene algo que cambiar:

curl -s <your discovery endpoint>

Busca token_endpoint_auth_methods_supported en la respuesta. Si client_secret_post está ausente de esa lista, el dominio no lo acepta en absoluto y ninguna configuración de aplicación lo añadirá, lo que hace que esa línea sea la evidencia más clara para el ticket.

8

El resultado de ejecutar el comando es:

"token_endpoint_auth_methods_supported": [
    "client_secret_basic",
    "client_secret_post",
    "client_secret_jwt",
    "private_key_jwt",
    "self_signed_tls_client_auth",
    "none"
  ]

El error de la respuesta es:

2026-08-31T02:21:56.485Z | debug | Heartbeat updated {"scopes":["instance-registry"],"file":"instance-registry.service.js"}
2026-08-31T02:22:12.013Z | error | Failed to exchange authorization code for tokens server responded with a challenge in the WWW-Authenticate HTTP Header {"code":"OAUTH_WWW_AUTHENTICATE_CHALLENGE","file":"oidc.service.ee.js","function":"logTokenExchangeError"}
ResponseError: Invalid authorization code
    at OidcService.loginUser (/usr/local/lib/node_modules/n8n/src/modules/sso-oidc/oidc.service.ee.ts:284:10)
    at processTicksAndRejections (node:internal/process/task_queues:104:5)
    at OidcController.callbackHandler (/usr/local/lib/node_modules/n8n/src/modules/sso-oidc/oidc.controller.ee.ts:144:29)
    at handler (/usr/local/lib/node_modules/n8n/src/controller.registry.ts:115:12)
    at /usr/local/lib/node_modules/n8n/src/controller.registry.ts:124:7
2026-08-31T02:22:26.485Z | debug | Heartbeat updated {"scopes":["instance-registry"],"file":"instance-registry.service.js"}

Por favor, ayúdame. ¡Muchas gracias!

9

¿Hay alguna forma de habilitar información de registro más detallada?

@Anshul_Namdev @n8n

10

No hay un nivel de registro que lo muestre, y ya estás en debug, las líneas Heartbeat en tu envío son salida de depuración. El controlador de intercambio de tokens de n8n registra oauthError, oauthErrorDescription, code y message, y omite el cause del error por diseño. Un desafío WWW-Authenticate no lleva un error o error_description de nivel superior, la razón se encuentra solo en cause, por lo que ambos campos se resuelven en undefined y tu línea imprime code por sí sola.
Oracle conservó la razón. En el dominio de identidad, abre Reports > Audit Log, establece Event description en “Application access failed” y filtra por tu aplicación confidencial. Esa entrada contiene la razón de rechazo que n8n está descartando.