La configuración del selector de autenticación dinámica no es válida o un despliegue de varias autorizaciones posteriormente no puede hacer coincidir las solicitudes con un servidor de autenticación

Cuando esto sucede

Es posible que vea uno o ambos de los siguientes síntomas:

• API Gateway rechaza el despliegue con un error Invalid Dynamic Authentication Selector.

• El despliegue se ha creado correctamente, pero algunas solicitudes devuelven posteriormente 401 Unauthorized porque ningún servidor de autenticación coincide con la solicitud.

El problema a menudo se produce en despliegues que utilizan diferentes métodos de autenticación para diferentes patrones de solicitud, como la autenticación de clave de API para un patrón de ruta y la autenticación de OAuth2 para otro patrón de ruta.

Funcionamiento de la autenticación dinámica

Un despliegue de autenticación dinámica utiliza el valor selectionSource.selector para decidir qué servidor de autenticación maneja cada solicitud. Para cada solicitud, API Gateway resuelve el valor de selector de la solicitud y compara ese valor con las claves de servidor de autenticación configuradas.

Utilice una de las siguientes formas de selector soportadas:

• request.auth[<key>]

• request.path[<key>]

• request.query[<key>]

• request.headers[<key>]

• request.subdomain[<key>]

• request.host

Después de que API Gateway resuelva el valor del selector, selecciona el servidor de autenticación coincidente. Si no hay ninguna clave de servidor de autenticación que coincida, API Gateway utiliza el servidor de autenticación por defecto si se configura uno. De lo contrario, la solicitud falla con 401 Unauthorized.

Parte 1: La creación del despliegue falla porque el selector no es válido

Este fallo se produce cuando la expresión del selector no es válida y no se puede crear el despliegue.

Cómo se ve esto

El despliegue se rechaza con el siguiente error:

• Invalid Dynamic Authentication Selector

Por qué sucede esto

La expresión de selector debe utilizar un formulario de selector soportado y una sintaxis de selector válida. Los siguientes ejemplos de selector no son válidos:

• random

• request.header[]]

• request.path[path1]*request.path[path2]

Estos errores de configuración se deben corregir antes de que se pueda crear o actualizar el despliegue.

Requisito de selector de ruta

Si utiliza request.path[<key>], el valor <key> debe ser el nombre de un parámetro de ruta de acceso que esté definido en la ruta.

El siguiente selector y ruta utilizan el mismo nombre de parámetro de ruta:

• Ruta: /DMPServices/{serviceType}

• Selector: request.path[serviceType]

El selector request.path[/] no es válido porque / no es un nombre de parámetro de ruta.

Cómo solucionarlo

Utilice las siguientes comprobaciones para corregir la sintaxis de selector no válida:

• Sustituya el selector no válido por uno de los formularios de selector soportados.

• Si utiliza request.path[<key>], defina el mismo parámetro de ruta con nombre en la ruta.

• Si el patrón de solicitud no se basa en un parámetro de ruta de acceso estable, utilice en su lugar un selector de cabecera o de parámetro de consulta.

Parte 2: El despliegue se realiza correctamente, pero las solicitudes posteriores fallan sin ningún servidor de autenticación coincidente

Este fallo se produce en tiempo de ejecución. La configuración de despliegue es válida, pero una solicitud entrante no produce un valor de selector que coincida con cualquier servidor de autenticación configurado.

Cómo se ve esto

En tiempo de ejecución, las solicitudes fallan con el siguiente mensaje:

• Request unauthorized as no authentication server matched the request and no default is specified

El mensaje significa que el gateway de API ha alcanzado el despliegue pero no ha podido seleccionar un servidor de autenticación para la solicitud.

Por qué sucede esto

El fallo suele producirse porque el valor del selector está presente en la primera solicitud, pero falta en las solicitudes posteriores. Por ejemplo, la solicitud inicial puede incluir un parámetro de consulta que seleccione el servidor de autenticación, mientras que las solicitudes posteriores para archivos .js, archivos .css, imágenes o llamadas de API omiten ese parámetro de consulta.

Si no se configura ningún servidor de autenticación por defecto, una solicitud que no incluye un valor de selector coincidente falla con 401 Unauthorized.

Cómo encajan las cookies y el estado de OAuth2

Las cookies y el parámetro state de OAuth2 pueden ayudar a preservar la información de sesión o flujo, pero no sustituyen el requisito del selector de tiempo de ejecución para las solicitudes de seguimiento ordinarias.

Problemas del Selector de Parámetros de Consulta

Un selector de parámetros de consulta puede fallar cuando la solicitud inicial incluye el valor del selector, pero las solicitudes posteriores lo omiten. Por ejemplo, las solicitudes del explorador para activos como archivos .js, archivos .css e imágenes a menudo no incluyen los mismos parámetros de consulta que la solicitud inicial.

Durante el paso de redirección o devolución de llamada de OAuth2, API Gateway puede utilizar el parámetro state de OAuth2 para recuperar el servidor de autenticación que se utilizó para ese flujo. Después de la devolución de llamada, las solicitudes de seguimiento comunes aún deben coincidir con el comportamiento de selección de autenticación de despliegue.

Cómo elegir un mejor selector

Utilice un valor de selector que esté presente en cada solicitud que se deba autenticar de forma coherente. Los siguientes tipos de selector suelen ser más fiables que un selector de parámetros de consulta:

• Una cabecera de solicitud, con request.headers[<key>].

• Parámetro de ruta estable, mediante request.path[<key>].

• El nombre de host, mediante request.host, si se requiere la selección de autenticación basada en host.

En el caso de las aplicaciones basadas en explorador, una cabecera de solicitud suele ser más fiable que un parámetro de consulta porque las solicitudes de seguimiento pueden incluir la misma cabecera de forma consistente.

Cómo solucionar fallos de coincidencia en tiempo de ejecución

Utilice las siguientes comprobaciones para corregir los fallos de coincidencia del servidor de autenticación en tiempo de ejecución:

• Si el selector utiliza un parámetro de consulta que no está presente en solicitudes posteriores, cambie el selector a un valor de solicitud estable, como un parámetro de cabecera o ruta de acceso.

• Si se espera que algunas solicitudes omitan el valor del selector, configure un servidor de autenticación predeterminado adecuado.

• Si el selector utiliza un parámetro de ruta, confirme que las solicitudes posteriores incluyen el mismo parámetro de ruta.

• Si su aplicación utiliza cookies, utilícelas solo para la continuidad de la sesión. No confíe únicamente en las cookies para seleccionar el servidor de autenticación para las solicitudes de seguimiento habituales.

Qué comprobar

Para un despliegue que ya está activo, compare la solicitud que se realiza correctamente con la solicitud que falla. Confirme los siguientes detalles:

• Selector configurado en selectionSource.

• Valor de selector que se resuelve a partir de la solicitud correcta.

• Valor de selector que se resuelve a partir de la solicitud fallida.

• Si el valor del selector está presente en ambas solicitudes.

• Si una clave de servidor de autenticación coincide con cada valor de selector resuelto.

• Si se configura un servidor de autenticación predeterminado.

Qué se debe buscar en los logs

Utilice logs de ejecución para identificar el modo de fallo:

• Invalid Dynamic Authentication Selector indica un problema de configuración de despliegue.

• Request unauthorized as no authentication server matched the request and no default is specified indica un problema de coincidencia de solicitudes en tiempo de ejecución.

Solucione los problemas de estos modos de fallo por separado. Una configuración de despliegue válida aún puede fallar en tiempo de ejecución si las solicitudes posteriores no incluyen un valor de selector coincidente.

Verificación de corrección

Después de corregir el selector o la asignación del servidor de autenticación, verifique el despliegue y el flujo de solicitud:

• Vuelva a crear o actualizar el despliegue si ha cambiado la configuración del selector.

• Vuelva a enviar la solicitud inicial.

• Envíe las solicitudes de seguimiento que anteriormente fallaron.

• Confirme que API Gateway ya no rechaza el despliegue para la sintaxis del selector.

• Confirme que las solicitudes de tiempo de ejecución ya no fallan porque ningún servidor de autenticación coincide con la solicitud.

Para obtener más información

Para obtener más información, consulte:

• Adición de varios servidores de autenticación al mismo despliegue de API

• Agregación de autenticación y autorización a despliegues de API

• Despliegue de una API en un gateway de API mediante la creación de un despliegue de API

• Errores varios al llamar a las API