Validación de tokens para agregar autenticación y autorización a despliegues de API

Puede agregar la funcionalidad de autenticación y autorización a un gateway de API haciendo que el propio gateway de API valide los tokens incluidos en una solicitud (como se describe en este tema). También puede hacer que el gateway de API transfiera un token de acceso de varios argumentos o de un solo argumento incluido en una solicitud a una función de autorizador desplegada en OCI Functions para su validación (como se describe en Transferencia de tokens a funciones de autorizador para agregar autenticación y autorización a despliegues de API).

Para que el gateway de API valide el token incluido en una solicitud, cree una política de solicitud de autenticación de tipo TOKEN_AUTHENTICATION. Los tokens que utiliza para controlar el acceso a las API son, a menudo, pero no siempre, tokens web JSON (JWT).

Al utilizar una política TOKEN_AUTHENTICATION, permite que un despliegue de API utilice tokens para la autenticación y autorización mediante la inclusión de dos tipos diferentes de política de solicitud en la especificación de despliegue de API:

Una política de solicitud de autentificación para todo el despliegue de API que especifica el uso de tokens, incluyendo cómo validarlos y si los usuarios finales no autenticados pueden acceder a rutas en el despliegue de API.
Una política de solicitud de autorización para cada ruta que especifica las operaciones que puede realizar un usuario final, según los valores especificados para la reclamación scope de un JWT.

Puede agregar políticas de solicitud de autorización y autenticación a una especificación de despliegue de API mediante las siguientes opciones:

Uso de la consola.
Edición de un archivo JSON.

Nota

En versiones anteriores, ha creado políticas de solicitud de autenticación de tipo JWT_AUTHENTICATION para utilizar JWT para la autenticación. Las políticas de solicitud de autenticación JWT_AUTHENTICATION existentes aún están soportadas (consulte Notas sobre el uso de políticas de solicitud JWT_AUTHENTICATION). Sin embargo, si está creando nuevas políticas de solicitud de autenticación para autenticar JWT, le recomendamos que cree políticas de solicitud de autenticación como políticas TOKEN_AUTHENTICATION. El uso de políticas TOKEN_AUTHENTICATION permite:

Valide los tokens JWT y los tokens que no sean JWT.
Valide los tokens mediante un proveedor de identidad para obtener un punto final de introspección.
Especifique políticas de fallo de validación, incluida la generación de un nuevo token de JWT en caso de que falte un token de JWT o no sea válido en la solicitud original.

¿Qué sucede durante la autenticación de token?

Cuando un gateway de API recibe una solicitud de un cliente de API y usted ha especificado una política de autenticación de token, el gateway de API localiza un token (por ejemplo, en una cabecera de token) y utiliza ese token.

Especifique cómo el gateway de API valida el token que ha obtenido definiendo la política de validación de la política de autenticación de token como uno de los siguientes tipos:

OAuth Punto final de introspección 2.0: especifique este tipo de política de validación si desea que el gateway de API valide un token JWT o no JWT con el punto final de introspección de un proveedor de identidad. Debe especificar la URL de detección del proveedor de identidad desde el que obtener el punto final de introspección. En este caso, el gateway de API transfiere las credenciales de cliente (el ID de cliente, junto con el secreto de cliente recuperado del servicio Vault) al proveedor de identidad para validar el token. El token se valida sin el uso de claves públicas. Para acelerar la validación futura, puede especificar que desea que el gateway de API almacene en caché la respuesta del punto final de introspección durante entre 1 hora (valor por defecto) y 24 horas. Si está definiendo la especificación de despliegue de API en un archivo JSON y desea este comportamiento, incluya una política de validación de tipo REMOTE_DISCOVERY.
JWKS remoto: especifique este tipo de política de validación si desea que el gateway de API utilice claves de verificación públicas recuperadas de un proveedor de identidad en tiempo de ejecución para verificar un JWT. En este caso, el gateway de API se pone en contacto con el proveedor de identidad para verificar el JWT. El proveedor de identidad actúa como servidor de autorización. Si está definiendo la especificación de despliegue de API en un archivo JSON y desea este comportamiento, incluya una política de validación de tipo REMOTE_JWKS.
Claves estáticas: especifique este tipo de política de validación si desea que el gateway de API utilice claves de verificación públicas ya emitidas por un proveedor de identidad (denominadas "claves estáticas") para verificar un JWT. En este caso, el gateway de API puede verificar el JWT localmente en tiempo de ejecución sin tener que ponerse en contacto con el proveedor de identidad. El resultado es una validación de token más rápida. Si está definiendo la especificación de despliegue de API en un archivo JSON y desea este comportamiento, incluya una política de validación de tipo STATIC_KEYS

Si la validación se realiza correctamente, el gateway de API enruta la solicitud al punto final de API adecuado.

Si la validación falla debido a un token no válido o faltante en la solicitud original, especifique el comportamiento del gateway de API definiendo la política de fallos de validación de la política de autenticación de token como uno de los siguientes tipos:

Por defecto (HTTP 401 no autorizado): especifique este tipo de política de fallo de validación si desea que el gateway de API devuelva una respuesta HTTP-401 al cliente de API. Esta es la respuesta por defecto. Si está definiendo la especificación de despliegue de API en un archivo JSON y desea este comportamiento, simplemente no incluya una política de fallo de validación.
Respuesta personalizada: especifique este tipo de política de fallo de validación si desea que el gateway de API devuelva una respuesta alternativa (una respuesta modificada) al cliente de API, en lugar de una respuesta HTTP-401. Si está definiendo la especificación de despliegue de API en un archivo JSON y desea este comportamiento, incluya una política de fallo de validación de tipo MODIFY_RESPONSE.
OAuth 2.0: especifique este tipo de política de fallo de validación si desea que el gateway de API obtenga un token JWT nuevo y válido del proveedor de identidad para las solicitudes GET (después de haber almacenado primero de forma segura los parámetros de consulta de solicitud originales). Para las solicitudes PUT y POST, puede especificar una ruta de acceso relativa en el despliegue de API actual a la que redirigir clientes de API. Mediante este tipo de política de fallos de validación, también puede definir un backend de desconexión para eliminar las cookies de sesión asociadas, revocar tokens llamando al punto final de sesión final del proveedor de identidad y redirigir a una URL posterior a la desconexión permitida. Si está definiendo la especificación de despliegue de API en un archivo JSON y desea este comportamiento, incluya una política de fallo de validación de tipo OAUTH2.
Tenga en cuenta que las políticas de fallo de validación de tipo OAuth 2.0 actualmente solo soportan el flujo de autorización de Connect OpenID y solo la generación de token de JWT (consulte Notas sobre OAuth 2.0 y OpenID Connect). En el caso del flujo de autorización de Connect OpenID, se devuelven dos tokens denominados id_token (siempre con codificación JWT) y access_token (se puede codificar JWT). El gateway de API guarda los valores de token en las variables de contexto request.auth[id_token] y request.auth[access_token], junto con las reclamaciones personalizadas en las variables de contexto request.auth[id_token_claims][<claim-name>] y request.auth[access_token_claims][<claim-name>] respectivamente (consulte Adición de variables de contexto a políticas y definiciones de backend HTTP). Al recibir el nuevo token de JWT id_token, el gateway de API recupera los detalles de la solicitud y reanuda el procesamiento de la solicitud mediante el token.

La ubicación desde la que el gateway de API obtiene un token depende tanto del tipo de política de validación (una de las OAuth 2.0 introspection endpoint, Remote JWKS o Static keys) como del tipo de política de fallo de validación (una de las siguientes opciones: Default (HTTP 401 Unauthorized), Custom response o OAuth 2.0:

Si especifica una política de validación de tipo OAuth 2.0 punto final de introspección y una política de fallo de validación de tipo OAuth 2.0, el gateway de API inicialmente intenta obtener el token de uno u otro de los siguientes elementos:
- Si ha seleccionado la opción Usar Cookies para Sesión en la política de fallos de validación, desde una cookie de sesión.
- De lo contrario, desde el encabezado X-APIGW-TOKEN en la solicitud.
Si el gateway de API no puede obtener un token de la ubicación inicial, el gateway de API obtiene el token de la cabecera de solicitud o el parámetro de consulta que especifique en la política de autenticación de token.
Si la validación de token se realiza correctamente posteriormente y ha seleccionado la opción Usar cookies para sesión, el gateway de API almacena el token generado como una cadena no legible por el usuario en una cookie de sesión. Si el cliente de API realiza una solicitud posterior, el token se obtiene de la cookie de sesión. Para evitar ataques CSRF, cuando el TOKEN generado se almacena en una cookie de sesión, el gateway de API también devuelve un TOKEN CSRF en una cabecera de respuesta X-CSRF-TOKEN (consulte Notas sobre la protección contra la falsificación de solicitudes entre sitios (CSRF)).
Si no especifica una política de validación de tipo OAuth 2.0 punto final de introspección y una política de fallo de validación de tipo OAuth 2.0, el gateway de API obtiene el token de la cabecera de solicitud o del parámetro de consulta que especifique en la política de autenticación de token.

Notas sobre los tokens web JSON (JWT)

Los tokens que utiliza para controlar el acceso a las API suelen ser tokens web JSON (JWT). Un JWT es un token de acceso basado en JSON enviado en una solicitud HTTP de un cliente de API a un recurso. Los proveedores de identidad emiten los JWT. API Gateway soporta el uso de cualquier proveedor de identidad compatible con OAuth2, como OCI IAM con dominios de identidad, Oracle Identity Cloud Service (IDCS), Auth0 y Okta. Si se necesita un JWT para acceder a un recurso, el recurso valida el JWT con un servidor de autorización mediante una clave de verificación pública correspondiente, ya sea llamando a un punto final de validación en el servidor de autorización o mediante una clave de verificación local proporcionada por el servidor de autorización.

Un JWT comprende:

Una cabecera que identifica el tipo de token y el algoritmo criptográfico utilizado para generar la firma.
Una carga útil, que contiene reclamaciones sobre la identidad del usuario final y las propiedades del propio JWT. Una reclamación es un par clave-valor donde la clave es el nombre de la reclamación. Se recomienda una carga útil (aunque no es necesaria) para contener determinadas reclamaciones reservadas con nombres particulares, como tiempo de caducidad (exp), público (aud), emisor (iss) y "no antes de" (nbf). Una carga útil también puede contener reclamaciones personalizadas con nombres definidos por el usuario.
Una firma para validar la autenticidad del JWT (derivada de base64 que codifica la cabecera y la carga útil).

Al utilizar JWT para controlar el acceso a las API, puede especificar que las reclamaciones reservadas en la carga útil de JWT deben tener valores concretos antes de que el gateway de API considere que el JWT es válido. Por defecto, los gateways de API validan los JWT utilizando las reclamaciones de caducidad (exp), público (aud) y emisor (iss), junto con la reclamación de "no antes de" (nbf) si está presente. También puede especificar valores aceptables para reclamaciones personalizadas. Consulte Detalles del proveedor de identidad para usar en reclamaciones iss y aud y para el URI de JWKS.

Cuando se ha validado un JWT, el gateway de API extrae reclamaciones de la carga útil de los JWT como pares clave-valor y las guarda como registros en la tabla de contexto request.auth para que el despliegue de API las utilice. Por ejemplo, como variables de contexto para su uso en una definición de backend HTTP (consulte Agregación de variables de contexto a políticas y definiciones de backend HTTP). Si la carga útil del JWT contiene la reclamación scope, puede utilizar los valores de la reclamación en las políticas de solicitud de autorización para rutas individuales para especificar las operaciones que puede realizar un usuario final.

Notas sobre OAuth 2.0 y OpenID Connect

El protocolo OAuth 2.0 permite la recuperación segura de recursos seguros al tiempo que protege las credenciales del cliente. OAuth 2.0 es un protocolo flexible y seguro que se basa en SSL (Secure Sockets Layer) para garantizar que los datos entre servidores web y navegadores permanezcan privados. Aunque OAuth 2.0 es diferente de JWT y se utiliza para diferentes fines, OAuth 2.0 y JWT son compatibles. Dado que el protocolo OAuth2 no especifica el formato de los tokens, los JWT se pueden incorporar al uso de OAuth2. Para obtener más información sobre OAuth 2.0, consulte la documentación de OAuth 2.0.

OpenID Connect es una capa de identidad simple sobre el protocolo OAuth 2.0. El uso de OpenID Connect permite a los gateways de API verificar la identidad de un cliente de API según la autenticación realizada por un servidor de autorización. OpenID Connect también permite a los gateways de API obtener información de perfil básica sobre el cliente de API. Para obtener más información sobre OpenID Connect, consulte la documentación de OpenID Connect.

Notas sobre la protección contra la falsificación de solicitudes entre centros (CSRF)

Un atacante puede montar un ataque CSRF aprovechando la existencia de una cookie del explorador para hacer que un usuario envíe un comando no deseado a una aplicación web, como un gateway de API. Si la aplicación determina que el usuario ya se ha autenticado correctamente debido a la existencia de la cookie del explorador, la aplicación ejecuta el comando con consecuencias potencialmente dañinas.

Al definir una política de validación de tipo OAuth 2.0 punto final de introspección y una política de fallo de validación de tipo OAuth 2.0, especifique cómo un gateway de API almacena un nuevo token de JWT que ha obtenido mediante el flujo de autorización de Connect OpenID:

Seleccione la opción Usar Cookies para la Sesión si desea almacenar el nuevo token de JWT en una cookie de sesión. Para evitar posibles ataques CSRF, cuando el gateway de API almacena el TOKEN en una cookie de sesión, también devuelve un TOKEN CSRF en una cabecera de respuesta X-CSRF-TOKEN. Las solicitudes de mutación posteriores al gateway de API (como las solicitudes POST, PUT y DELETE, pero no las solicitudes GET) deben incluir el TOKEN CSRF en una cabecera de solicitud X-CSRF-TOKEN, además del TOKEN JWT en la cookie de sesión que se incluye automáticamente.
Tenga en cuenta que el gateway de API también almacena el token CSRF en la variable de contexto request.auth[apigw_csrf_token]. Si el cliente de API no puede leer la cabecera de respuesta inicial de X-CSRF-TOKEN por algún motivo, puede incluir la variable de contexto request.auth[apigw_csrf_token] en una política de respuesta de transformación de cabecera para agregar una cabecera de respuesta que contenga el token CSRF a cada respuesta devuelta al cliente de API. Este enfoque garantiza que el cliente de API pueda extraer correctamente el token CSRF de la cabecera de respuesta para su inclusión en las siguientes cabeceras de solicitud de mutación X-CSRF-TOKEN que envía al gateway de API. A continuación, se muestra un ejemplo de una política de respuesta de transformación de cabecera adecuada:
```
"responsePolicies": {
        "headerTransformations": {
          "setHeaders": {
            "items": [
              {
                "name": "MY-CSRF-TOKEN",
                "values": ["${request.auth[apigw_csrf_token]}"],
                "ifExists": "OVERWRITE"              }
            ]
          }
        }
      }
```
Para obtener más información sobre las políticas de respuesta de transformación de cabecera, consulte Adición de Políticas de Respuesta de Transformación de Cabecera.
No seleccione la opción Usar Cookies para Sesión si no desea almacenar el nuevo token de JWT en una cookie de sesión. En su lugar, el gateway de API devuelve un TOKEN no legible por humanos en una cabecera de respuesta X-APIGW-TOKEN. Las solicitudes posteriores al gateway de API deben incluir el mismo TOKEN en una cabecera de solicitud X-APIGW-TOKEN.

Para obtener más información sobre CSRF, busque en línea.

Notas sobre el uso de políticas de solicitud JWT_AUTHENTICATION

En versiones anteriores, es posible que haya creado políticas de solicitud de autenticación de tipo JWT_AUTHENTICATION para utilizar JWT para la autenticación.

Si está creando nuevas políticas de solicitud de autenticación para utilizar JWT, ahora recomendamos que cree políticas de solicitud de autenticación de tipo TOKEN_AUTHENTICATION en su lugar (consulte Uso de la consola para agregar políticas de solicitud de autorización y autenticación de token y Edición de un archivo JSON para agregar políticas de solicitud de autorización y autenticación de token). También recomendamos migrar las políticas de solicitud JWT_AUTHENTICATION existentes a las políticas TOKEN_AUTHENTICATION.

Tenga en cuenta que las políticas de solicitud JWT_AUTHENTICATION existentes aún están soportadas. Tenga en cuenta también que, aunque puede crear nuevas políticas de solicitud JWT_AUTHENTICATION (como se describe en las instrucciones originales de la sección Uso de una política de solicitud de autenticación JWT_AUTHENTICATION (ya no se recomienda)), le recomendamos que, en su lugar, cree políticas de solicitud de autenticación de tipo TOKEN_AUTHENTICATION.

Requisitos para la Autenticación de Token

Tenga en cuenta los siguientes puntos antes de activar la autenticación y autorización para despliegues de API mediante JWT:

Ya se debe haber configurado un proveedor de identidad compatible con OAuth2 (por ejemplo, OCI IAM con dominios de identidad, Oracle Identity Cloud Service (IDCS), Auth0) para emitir JWT para los usuarios con permiso para acceder al despliegue de API.
Si desea utilizar reclamaciones personalizadas en las políticas de autorización, se debe configurar el proveedor de identidad para agregar las reclamaciones personalizadas a los JWT que emite.

Consulte la documentación del proveedor de identidad para obtener más información. Por ejemplo, documentación de OCI IAM con dominios de identidad, la documentación de Oracle Identity Cloud Service (IDCS) y la documentación de Auth0).

Para validar un JWT mediante una clave de verificación pública correspondiente proporcionada por el proveedor de identidad emisor:

el algoritmo de firma utilizado para generar la firma del JWT debe ser RS256, RS384 o RS512;
la clave de verificación pública debe tener una longitud mínima de 2048 bits y no debe superar los 4096 bits.

Para validar tokens mediante un punto final de introspección de un servidor de autorización:

Debe haber creado y registrado una aplicación de cliente con el servidor de autorización para obtener credenciales de cliente (un ID de cliente y un secreto de cliente). Consulte la documentación del servidor de autorización para obtener más información. Por ejemplo, documentación de OCI IAM con dominios de identidad, la documentación de Oracle Identity Cloud Service (IDCS) y la documentación de Auth0).
Ya debe haber almacenado el secreto de cliente que ha obtenido del servidor de autorización como secreto en un almacén del servicio Vault (consulte Creación de un secreto en un almacén) y debe conocer el OCID y el número de versión del secreto.
Ya debe haber configurado una política para otorgar gateways de API en un grupo dinámico permiso para acceder al secreto de almacén que contiene el secreto de cliente (consulte Creación de una política para otorgar a los gateways de API acceso a las credenciales almacenadas como secretos en el servicio Vault).

Uso de la consola para agregar políticas de solicitud de autenticación y autorización de token

Siga estos pasos para agregar políticas de solicitud de autorización y autenticación a una especificación de despliegue de API mediante la consola:

Cree o actualice un despliegue de API con la consola, seleccione la opción Desde cero e introduzca los detalles en la página Información básica.

Para obtener más información, consulte Despliegue de una API en un gateway de API mediante la creación de un despliegue de API y Actualización de un gateway de API.
Seleccione Siguiente para mostrar la página Autenticación.
Seleccione Autenticación única para especificar que desea utilizar un único servidor de autenticación para todas las solicitudes.

En estas instrucciones, se asume que desea utilizar un único servidor de autenticación. Como alternativa, si desea utilizar varios servidores de autenticación, seleccione Autenticación múltiple y siga las instrucciones de Uso de la consola para agregar varios servidores de autenticación al mismo despliegue de API.
Seleccione o anule la selección de la casilla de control Activar acceso anónimo: para especificar si los usuarios finales no autenticados (es decir, anónimos) pueden acceder a rutas en el despliegue de API.

Por defecto, esta opción no está seleccionada. Si desea que los usuarios anónimos no puedan acceder a rutas, no seleccione esta opción. Tenga en cuenta que si selecciona esta opción, también deberá especificar explícitamente cada ruta en la que se permite el acceso anónimo, seleccionando Anónimo como Tipo de autorización en la política de autorización de cada ruta.
Seleccione OAuth 2.0 / OpenID Connect en la lista de opciones Tipo de autenticación y especifique:
- Ubicación del token: indica si los tokens están incluidos en una cabecera de solicitud o en un parámetro de consulta.
- Detalles del token de autenticación: en función de si los tokens están incluidos en una cabecera de solicitud o en un parámetro de consulta, especifique:
  - Nombre de cabecera de token y Esquema de autenticación: si los tokens están contenidos en una cabecera de solicitud, introduzca el nombre de la cabecera (por ejemplo Authorization) y el esquema de autenticación HTTP (actualmente solo soporta Bearer).
  - Nombre de parámetro de token: si los tokens están incluidos en un parámetro de consulta, introduzca el nombre del parámetro de consulta.
Especifique cómo desea que el gateway de API valide los tokens:
1. Si desea que el gateway de API valide tanto tokens JWT como tokens no JWT con un punto final de introspección del servidor de autorización OAuth 2.0 mediante credenciales de cliente (incluido un secreto de cliente recuperado de un almacén en el servicio Vault), seleccione punto final de introspección OAuth 2.0 en la lista Tipo y especifique:
  - ID de cliente: ID de cliente que se enviará al punto final de introspección. Para obtener un ID de cliente, cree y registre una aplicación cliente con el servidor de autorización. Por ejemplo, 5hsti38yhy5j2a4tas455rsu6ru8yui3wrst4n1 . Consulte Requisitos para la autenticación de token.
  - Almacén en <compartment-name>: nombre de un almacén en el servicio Vault que contiene el secreto de cliente que se enviará al punto final de introspección. Para obtener un secreto de cliente, cree y registre una aplicación cliente con el servidor de autorización. Consulte Requisitos para la autenticación de token.
  - Secreto de almacén en <compartment name>: nombre de un secreto de almacén que contiene el secreto de cliente que se enviará al punto final de introspección.
  - Número de versión del secreto de almacén: versión del secreto de almacén que contiene el secreto de cliente que se enviará al punto final de introspección.
  - URL de detección: URL conocida del servidor de autorización desde el que el gateway de API va a obtener puntos finales de metadatos de autorización. Por ejemplo, https://my-idp/oauth2/default/.well-known/openid-configuration.
    Tenga en cuenta que la URL debe poder dirigirse desde la subred que contiene el gateway de API en el que se despliega la API.
  - Duración máxima de la caché en horas: número de horas (entre 1 y 24) que el gateway de API debe almacenar en la caché la respuesta del punto final de introspección.
  - Sesgo de reloj máximo en segundos: (opcional) diferencia de tiempo máxima entre los relojes del sistema del servidor de autorización que emitió un token y el gateway de API. El valor introducido aquí se tiene en cuenta cuando el gateway de API valida un JWT para determinar si sigue siendo válido, utilizando la reclamación de "no antes de" (nbf) (si está presente) y la reclamación de caducidad (exp) en el JWT. El mínimo (por defecto) es 0 y el máximo, 120.
  - Desactivar verificación SSL: indica si se debe desactivar la verificación SSL al comunicarse con el servidor de autorización. Por defecto, esta opción no está seleccionada. Oracle recomienda no seleccionar esta opción porque puede comprometer la validación de tokens. El gateway de API confía en certificados de varias autoridades de certificación emitidas para OCI IAM con dominios de identidad, Oracle Identity Cloud Service (IDCS), Auth0 y Okta.
2. Si desea que el gateway de API valide los JWT recuperando claves de verificación públicas del proveedor de identidad en tiempo de ejecución, seleccione JWKS remoto en la lista Tipo y especifique:
  - URI JWKS: URI desde el que recuperar el juego de claves web JSON (JWKS) que desea utilizar para verificar la firma en los JWT. Por ejemplo, https://www.somejwksprovider.com/oauth2/v3/certs. Para obtener más información sobre el URI que se va a especificar, consulte Detalles del proveedor de identidad para usar en reclamaciones iss y aud y para el URI de JWKS.
    
    Tenga en cuenta que:
    - El URI debe poder dirigirse desde la subred que contiene el gateway de API en el que se despliega la API.
    - Si el gateway de API no recupera el JWKS, todas las solicitudes al despliegue de API devolverán un código de respuesta HTTP 500. Consulte el log de ejecución del gateway de API para obtener más información sobre el error (consulte Agregación de registro a despliegues de API).
    - Algunos parámetros de clave deben estar presentes en el JWKS para verificar la firma del JWT (consulte Parámetros de clave necesarios para verificar las firmas de JWT).
    - El JWKS puede contener hasta diez claves.
  - Duración máxima de la caché en horas: número de horas (entre 1 y 24) que el gateway de API debe almacenar en la caché JWKS después de recuperarlo.
  - Desactivar verificación SSL: indica si se debe desactivar la verificación SSL al comunicarse con el proveedor de identidad. Por defecto, esta opción no está seleccionada. Oracle recomienda no seleccionar esta opción porque puede comprometer la validación de JWT. El gateway de API confía en certificados de varias autoridades de certificación emitidas para OCI IAM con dominios de identidad, Oracle Identity Cloud Service (IDCS), Auth0 y Okta.
3. Si desea que el gateway de API valide los JWT con claves de verificación públicas ya emitidas por un proveedor de identidad (lo que permite al gateway de API verificar los JWT localmente sin tener que ponerse en contacto con el proveedor de identidad), seleccione Claves estáticas en la lista Tipo y especifique hasta diez claves estáticas:
  - ID de clave: identificador de la clave estática utilizada para firmar el JWT. El valor debe coincidir con la reclamación kid en la cabecera de JWT. Por ejemplo, master_key.
  - Formato de clave: formato de la clave estática, como clave web JSON o clave pública codificada por PEM.
    - Clave web JSON: si la clave estática es JSON, pegue la clave en este campo.
      
      Por ejemplo:
```
{
  "kty": "RSA",
  "n": "0vx7agoebGc...KnqDKgw",
  "e": "AQAB",
  "alg": "RS256",
  "use": "sig"
}
```
      Tenga en cuenta que ciertos parámetros deben estar presentes en la clave estática para verificar la firma del JWT (consulte Parámetros de clave necesarios para verificar las firmas de JWT). Tenga en cuenta también que RSA es actualmente el único tipo de clave soportado (kty).
    - clave pública codificada por PEM: si la clave estática es una clave pública codificada por PEM, pegue la clave en este campo. Por ejemplo:
```
-----BEGIN PUBLIC KEY-----
XsEiCeYgglwW/KAhSSNRVdD60QlXYMWHOhXzSFDZCLf1WXxKMZCiMvVrsBIzmFEXnFmcsO2mxwlL5/8qQudomoP+yycJ2gWPIgqsZcQRheJWxVC5ep0MeEHlvLnEvCi9utpAnjrsZCQ7plfZVPX7XORvezwqQhBfYzwA27M2FgOOs8DOIYfqQ1Ki3DMqEppFnjLcjgQtknbTlT7YgG6tzobwig8M2KIrPjJ0BmbJAFH
-----END PUBLIC KEY-----
```
      Tenga en cuenta que los marcadores -----BEGIN PUBLIC KEY----- y -----END PUBLIC KEY----- son necesarios.
  - Otra clave: seleccione esta opción para agregar claves adicionales (hasta un máximo de diez).
(Opcional) Especifique detalles adicionales para la validación de token de JWT:
1. En la sección Emisores, especifique los valores permitidos en la reclamación de emisor (iss) de un JWT que se esté utilizando para acceder al despliegue de API:
  - Emisores permitidos: especifique la URL (o una cadena de texto) para un proveedor de identidad que esté permitido en la reclamación de emisor (iss) de un JWT que se utilizará para acceder al despliegue de API. Por ejemplo, para permitir que un JWT emitido por OCI IAM con dominios de identidad se utilice para acceder al despliegue de API, introduzca https://identity.oraclecloud.com/. Consulte Detalles del proveedor de identidad para usar en reclamaciones iss y aud y para el URI de JWKS.
  - Otro emisor: seleccione esta opción para agregar proveedores de identidad adicionales (hasta un máximo de cinco).
2. En la sección Públicos, especifique los valores permitidos en la reclamación de público (aud) de un JWT que se esté utilizando para acceder al despliegue de API:
  - Públicos permitidos: especifique un valor permitido en la reclamación de público (aud) de un JWT para identificar el destinatario deseado del token. Por ejemplo, el público puede ser, pero no necesita ser, el nombre de host del gateway de API. Consulte Detalles del proveedor de identidad para usar en reclamaciones iss y aud y para el URI de JWKS.
  - Otro público: seleccione esta opción para agregar públicos adicionales (hasta un máximo de cinco).
3. Validación de reclamaciones: (opcional) además de los valores para las reclamaciones de público aud y emisor iss que ya ha especificado, puede especificar nombres y valores para una o más reclamaciones adicionales que validar en un JWT. Tenga en cuenta que los nombres y valores clave introducidos se manejan simplemente como cadenas y deben coincidir exactamente con los nombres y valores del JWT. No se soporta la coincidencia de patrones y otros tipos de datos.
  - La reclamación es necesaria: especifique si la reclamación en el campo Clave de reclamación debe incluirse en el JWT.
  - clave de reclamación: (opcional) especifique el nombre de una reclamación que puede o debe incluirse en un JWT. Si la reclamación se debe incluir en el JWT, seleccione Necesario. El nombre de reclamación que especifique puede ser un nombre de reclamación reservado, como la reclamación de asunto (sub) o un nombre de reclamación personalizado emitido por un proveedor de identidad concreto.
  - Valores de reclamación: (opcional) especifique un valor aceptable para la reclamación en el campo clave de reclamación. Seleccione el signo más (+) para introducir otro valor aceptable. Si especifica uno o más valores aceptables para la reclamación, el gateway de API valida que la reclamación tenga uno de los valores especificados.
  Tenga en cuenta que puede especificar una reclamación en un JWT sin especificar un valor para él. Para ello, introduzca el nombre de la reclamación en el campo Clave de reclamación, deje el campo Valores de reclamación en blanco y defina La reclamación es necesaria según corresponda.
Especifique cómo desea que el gateway de API maneje una respuesta de autenticación fallida (devuelta después de un intento incorrecto de validar un token que falta o no es válido) mediante la configuración de una política de fallo de validación:
1. Si desea que el gateway de API envíe un código de estado HTTP 401 y la cabecera WWW-Authenticate en la respuesta (la respuesta por defecto a un token que falta o no es válido), seleccione Por defecto (HTTP 401 no autorizado).
2. Si desea que el gateway de API utilice un flujo de autorización de Connect OpenID para obtener un nuevo token de acceso de JWT, seleccione OAuth 2.0. Tenga en cuenta que esta opción solo está disponible si ha seleccionado OAuth 2.0 punto final de introspección en la lista Tipo de validación anterior. Especifique:
  - Ámbitos: uno o más ámbitos de acceso para incluir en una reclamación scope enviada al servidor de autorización. Para utilizar el flujo de autorización de Connect OpenID, debe incluir openid como uno de los ámbitos. Por ejemplo, openid, email:read, profile.
  - Tipo de respuesta: tipo de respuesta necesaria del flujo de autorización. Introduzca code como tipo de respuesta.
  - Ruta de redirección de Fallback: (opcional) ruta relativa en el despliegue de API actual a la que redirigir clientes de API si la solicitud original era una solicitud PUT o una solicitud POST. Por ejemplo, /home
    Si la solicitud original era una solicitud GET, el procesamiento de solicitudes se reanuda con un nuevo token de acceso JWT, por lo que no se utiliza una ruta de acceso de reserva.
  - Ruta de desconexión: (opcional) ruta relativa a un backend de desconexión en el despliegue de API actual. La ruta que especifique debe coincidir con la ruta de ruta definida para el backend de desconexión. Por ejemplo, /revoke
    Un cliente de API puede llamar al backend de desconexión para revocar tokens. Una llamada al backend de desconexión puede incluir una URL posterior a la desconexión como parámetro de consulta denominado postLogoutUrl. Consulte Adición de desconexión como backend de gateway de API.
  - Caducidad de la respuesta en horas: (opcional) tiempo que se tarda en almacenar en caché el token de JWT generado por el flujo de autorización. El valor por defecto es 1 hora.
  - Utilice las credenciales de cliente de punto final de introspección OAuth2: especifique si desea utilizar los mismos detalles de cliente especificados anteriormente para el punto final de introspección OAuth 2.0 para obtener un nuevo token de acceso de JWT (que suele ser el caso). Si no desea utilizar los detalles especificados anteriormente, introduzca diferentes detalles de cliente para obtener un nuevo token de acceso de JWT del servidor de autorización, de la siguiente manera:
    - ID de cliente: ID de cliente que se enviará al punto final de introspección. Por ejemplo, 5hsti38yhy5j2a4tas455rsu6ru8yui3wrst4n1
    - Almacén en <compartment-name>: nombre de un almacén en el servicio Vault que contiene el secreto de cliente que se enviará al punto final de introspección.
    - Secreto de almacén en <compartment name>: nombre del secreto de almacén que contiene el secreto de cliente que se enviará al punto final de introspección.
    - Número de versión del secreto de almacén: versión del secreto de almacén que contiene el secreto de cliente que se enviará al punto final de introspección.
  Opcionalmente, puede elegir almacenar en cookies los tokens y valores obtenidos durante los flujos de autorización de OpenID, seleccionando Mostrar opciones avanzadas y seleccionando:
  - Usar cookies para la sesión: (opcional) especifique cómo almacenar tokens JWT recién generados como cadenas no legibles por el usuario al final de un flujo de autorización de Connect OpenID:
    - Seleccione esta opción si desea almacenar el nuevo token de JWT en una cookie de sesión. Para evitar posibles ataques de CSRF, cuando el gateway de API almacena el token en una cookie de sesión, también devuelve un token CSRF en una cabecera de respuesta X-CSRF-TOKEN. Las solicitudes posteriores al gateway de API (aparte de las solicitudes GET) deben incluir el token CSRF en una cabecera de solicitud X-CSRF-TOKEN, además del token JWT en la cookie de sesión que se incluye automáticamente.
    - No seleccione esta opción si no desea almacenar el nuevo token de JWT en una cookie de sesión. En su lugar, el gateway de API devuelve un token no legible por el usuario en una cabecera de respuesta de X-APIGW-TOKEN. Las solicitudes posteriores al gateway de API deben incluir el mismo token en una cabecera de solicitud de X-APIGW-TOKEN.
    Consulte Notas sobre la protección contra la falsificación de solicitudes entre sitios (CSRF)
  - Utilizar cookies para pasos intermedios: (opcional) especifique cómo almacenar los valores de pasos intermedios del flujo de autorización (por ejemplo, parámetros de solicitud). Seleccione esta opción para almacenar los valores en las cookies del explorador. Anule la selección de esta opción para almacenar los valores con el gateway de API.
  - Usar PKCE: (opcional) especifique si desea utilizar PKCE (clave de prueba para el intercambio de código) para mayor seguridad. PKCE es una extensión de seguridad OAuth 2.0 para evitar ataques de inyección de código de autorización y CSRF (falsificación de solicitudes entre sitios). PKCE no sustituye un secreto de cliente y se recomienda PKCE incluso si se utiliza un secreto de cliente. Para obtener más información sobre PKCE, consulte la OAuth 2.0 documentation.
3. Si desea personalizar la respuesta a un intento incorrecto de validar un token que falta o no es válido, seleccione Respuesta personalizada y especifique un código de estado (y un cuerpo de mensaje opcional) para volver al cliente de API:
  - Código de estado HTTP: introduzca un código de estado HTTP alternativo. Por ejemplo, 500.
  - Cuerpo del mensaje: introduzca un cuerpo del mensaje. Por ejemplo, Unfortunately, authentication failed.El cuerpo del mensaje puede incluir cualquier variable de contexto (excepto request.body).
  - Opcionalmente, modifique las cabeceras de la respuesta que devuelve el gateway de API al cliente de API especificando una política de respuesta de transformación de cabecera. Para obtener más información sobre las políticas de transformación de cabecera, consulte Adición de políticas de respuesta de transformación de cabecera.
Seleccione Siguiente para introducir detalles de rutas individuales en el despliegue de API en la página Rutas.
En la sección Ruta 1, especifique la primera ruta del despliegue de API que asigna una ruta de acceso y uno o varios métodos a un servicio de backend:
- Ruta de acceso: ruta de acceso al servicio de backend para llamadas de API mediante los métodos enumerados. Tenga en cuenta que la ruta de acceso especificada:
  - Es relativa al prefijo de ruta de acceso de despliegue.
  - Debe estar precedida de una barra inclinada (/) y puede ser simplemente esa barra inclinada.
  - Puede contener varias barras inclinadas (siempre que no sean adyacentes) y puede terminar con una barra inclinada.
  - Puede incluir caracteres alfanuméricos en mayúscula y minúscula.
  - Puede incluir los caracteres especiales $ - _ . + ! * ' ( ) , % ; : @ & = .
  - Puede incluir parámetros y comodines (consulte Agregación de parámetros de ruta y comodines a rutas de acceso).
- Métodos: uno o más métodos aceptados por el servicio backend, separados por comas. Por ejemplo, GET, PUT.
- Agregar un único backend o Agregar varios backends: indica si se deben enrutar todas las solicitudes al mismo backend o si se deben enrutar a diferentes backends según la variable de contexto y las reglas introducidas.
  
  En estas instrucciones se supone que desea utilizar un único backend, por lo que seleccione Agregar un único backend. Como alternativa, si desea utilizar diferentes backends, seleccione Agregar varios backends y siga las instrucciones de Uso de la consola para agregar una selección de backend dinámica a una especificación de despliegue de API.
- Tipo de backend: tipo del servicio de backend, como uno de los siguientes:
  - HTTP: para un backend HTTP, también debe especificar una URL, detalles de timeout, e indicar si se va a desactivar la verificación SSL (consulte Agregación de una URL de HTTP o HTTPS como un backend de gateway de API).
  - Oracle Functions: para el backend de OCI Functions, también debe especificar la aplicación y la función (consulte Agregación de una función en OCI Functions como backend de gateway de API).
  - Respuesta de stock: para un backend de respuesta de stock, también debe especificar el código de estado HTTP, el contenido del cuerpo de la respuesta y uno o varios campos de cabecera HTTP (consulte Agregación de respuestas de stock como backend de gateway de API).
  - Desconexión: para un backend de desconexión, también debe especificar una lista de URL permitidas a las que se puede redirigir una solicitud para revocar tokens y, opcionalmente, datos para transferir a la URL de desconexión (consulte Adición de desconexión como backend de gateway de API).
Para especificar una política de autorización que se aplique a una ruta individual, seleccione Show Route Request Policies y seleccione el botón Add situado junto a Authorization y especifique:
- Tipo de autorización: indica cómo otorgar acceso a la ruta. Especifique:
  - Cualquiera: solo otorga acceso a usuarios finales que se hayan autenticado correctamente, siempre que JWT tenga una reclamación scope que incluya al menos uno de los ámbitos de acceso especificados en el campo Ámbito permitido. En este caso, la opción Activar acceso anónimo de la política de autenticación no tiene ningún efecto.
  - Anónimo: otorga acceso a todos los usuarios finales, incluso si el JWT no los ha autenticado correctamente. En este caso, debe haber seleccionado la opción Activar acceso anónimo de la política de autenticación.
  - Solo autenticación: solo otorga acceso a los usuarios finales que se hayan autenticado correctamente mediante el JWT. En este caso, la opción Activar acceso anónimo de la política de autenticación no tiene ningún efecto.
- Ámbito permitido si ha seleccionado Cualquiera en Tipo de autorización, introduzca una lista delimitada por comas de una o varias cadenas correspondientes a los ámbitos de acceso en el JWT. Solo se les otorgará acceso a los usuarios finales autenticados correctamente si el JWT tiene una reclamación de scope que incluya uno de los ámbitos de acceso que especifique. Por ejemplo, read:hello
Nota

Si no incluye ninguna política de autorización para una ruta concreta, se otorga el acceso como si esa política existiera y Tipo de autorización se define en Solo autenticación. Es decir, con independencia de la configuración de la opción Activar acceso anónimo de la política de autenticación:
- solo pueden acceder a la ruta los usuarios finales autenticados
- todos los usuarios finales autenticados pueden acceder a la ruta independientemente de los ámbitos de acceso en la reclamación de scope de JWT
- los usuarios finales anónimos no pueden acceder a la ruta
Seleccione Aplicar cambios y, a continuación, seleccione Siguiente para revisar los detalles introducidos para el despliegue de API.
Seleccione Crear o Guardar cambios para crear o actualizar el despliegue de API.
(Opcional) Confirme que la API se ha desplegado correctamente llamándola. Para ello, consulte Llamada a una API desplegada en un gateway de API.

Edición de un archivo JSON para agregar políticas de solicitud de autorización y autenticación de token

Siga estos pasos para agregar políticas de solicitud de autorización y autenticación a una especificación de despliegue de API en un archivo JSON:

Con el editor de JSON de su elección, modifique la especificación de despliegue de API existente a la que desea agregar la funcionalidad de autenticación y autorización o cree una nueva especificación de despliegue de API (consulte Creación de una especificación de despliegue de API).

Como mínimo, la especificación de despliegue de API incluirá una sección routes que contiene:
- Una ruta de acceso. Por ejemplo, /hello.
- Uno o varios métodos. Por ejemplo, GET
- Una definición de backend. Por ejemplo, una URL o el OCID de una función en OCI Functions.
Por ejemplo, la siguiente especificación básica de despliegue de API define una función sencilla de Hello World sin servidor en OCI Functions como un único backend:
```
{
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```

Inserte una sección requestPolicies antes de la sección routes (si no existe ninguna) para crear una política de solicitud authentication que se aplique a todas las rutas de la especificación de despliegue de API. Por ejemplo:


{
  "requestPolicies": {},
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
         "type": "ORACLE_FUNCTIONS_BACKEND",
         "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}

Agregue la política de solicitud authentication de la siguiente manera
```
{
  "requestPolicies": {
    "authentication": {
      "type": "TOKEN_AUTHENTICATION",
      <"tokenHeader"|"tokenQueryParam">: <"<token-header-name>"|"<token-query-param-name>">,
      "tokenAuthScheme": "<authentication-scheme>",
      "isAnonymousAccessAllowed": <true|false>,
      "maxClockSkewInSeconds": <seconds-difference>,
      "validationPolicy": {<validation-policy-config>},
    }
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
         "type": "ORACLE_FUNCTIONS_BACKEND",
         "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```
donde:
- "authentication": {"type": "TOKEN_AUTHENTICATION"... especifica que desea utilizar tokens para la autenticación.
- <"tokenHeader"|"tokenQueryParam">: <"<token-header-name>"|"<token-query-param-name>"> indica si se trata de una cabecera de solicitud que contiene el token (y, si lo contiene, también indica el nombre de la cabecera) o un parámetro de consulta que contiene el token (y, si lo contiene, también indica el nombre del parámetro de consulta). Tenga en cuenta que puede especificar "tokenHeader": "<token-header-name>" o "tokenQueryParam": "<token-query-param-name>">, pero no los dos. Por ejemplo, "tokenHeader": "Authorization"
- <tokenAuthScheme> es el nombre del esquema de autenticación que se va a utilizar si el token está incluido en una cabecera de solicitud. Por ejemplo, "Bearer".
- "isAnonymousAccessAllowed": <true|false> opcionalmente indica si los usuarios finales no autenticados (es decir, anónimos) pueden acceder a rutas en la especificación de despliegue de API. Si desea que los usuarios finales anónimos no puedan acceder a rutas, defina esta propiedad en false. Si no incluye esta propiedad en la política authentication, se utilizará el valor por defecto false. Tenga en cuenta que si incluye esta propiedad y la define en true, también tendrá que especificar explícitamente cada ruta en la que se permite el acceso anónimo, definiendo la propiedad type en "ANONYMOUS" en la política authorization de cada ruta.
- maxClockSkewInSeconds: <seconds-difference> especifica opcionalmente la diferencia de tiempo máxima entre los relojes del sistema del proveedor de identidad que emitió un JWT y el gateway de API. El valor especificado se tiene en cuenta cuando el gateway de API valida el JWT para determinar si sigue siendo válido, utilizando la reclamación de "no antes de" (nbf) (si existe) y la reclamación de caducidad (exp) en el JWT. El mínimo (por defecto) es 0 y el máximo, 120.
- "validationPolicy": {<validation-policy-config>} especifica una política de validación para validar tokens, como se describe en los siguientes pasos.
Si desea que el gateway de API valide tanto tokens JWT como tokens no JWT con un punto final de introspección del servidor de autorización OAuth 2.0 mediante credenciales de cliente (incluido un secreto de cliente recuperado de un almacén en el servicio Vault), agregue la siguiente política de validación a la sección validationPolicy vacía:
```
      "validationPolicy": {
        "type": "REMOTE_DISCOVERY",          
        "clientDetails": {
          "type": "CUSTOM",
          "clientId": "<client-id>",
          "clientSecretId": "<secret-ocid>",
          "clientSecretVersionNumber": <secret-version-number>
        },          
        "sourceUriDetails": {
          "type": "DISCOVERY_URI",
          "uri": "<well-known-uri>"
        },
        "isSslVerifyDisabled": <true|false>,
        "maxCacheDurationInHours": <cache-time>,
        "additionalValidationPolicy": {
          "issuers": ["<issuer-url>", "<issuer-url>"],
          "audiences": ["<intended-audience>"],
          "verifyClaims": [{
            "key": "<claim-name>",
            "values": ["<acceptable-value>", "<acceptable-value>"],
            "isRequired": <true|false>
          }]
        }
      }
```
donde:
- "validationPolicy": {"type": "REMOTE_DISCOVERY"...} especifica que desea validar tokens con un punto final de introspección del servidor de autorización OAuth 2.0 mediante credenciales de cliente (incluido un secreto de cliente recuperado de un almacén en el servicio Vault).
- clientDetails": {"type": "CUSTOM"...} especifica los detalles del secreto de cliente que se va a recuperar de un almacén en el servicio Vault:
  - "clientId": "<client-ID>" especifica el identificador de cliente que se enviará al punto final de introspección. Para obtener un ID de cliente, cree y registre una aplicación cliente con el servidor de autorización. Por ejemplo, 5hsti38yhy5j2a4tas455rsu6ru8yui3wrst4n1 . Consulte Requisitos para la autenticación de token.
  - "clientSecretId": "<secret-ocid>" especifica el OCID del secreto de almacén que contiene el secreto de cliente que se enviará al punto final de introspección. Por ejemplo, ocid1.vaultsecret.oc1.iad.amaaaaaa______cggit3q
  - "clientSecretVersionNumber": <secret-version-number> especifica la versión del secreto de almacén que contiene el secreto de cliente que se enviará al punto final de introspección. Por ejemplo, 1.
- "uri": "<well-known-uri>" especifica la URL conocida de un servidor de autorización desde el que el gateway de API va a obtener puntos finales de metadatos de autorización. Por ejemplo, https://my-idp/oauth2/default/.well-known/openid-configuration. Tenga en cuenta que la URL debe poder dirigirse desde la subred que contiene el gateway de API en el que se despliega la API.
- "isSslVerifyDisabled": <true|false> indica si se debe desactivar la verificación SSL al comunicarse con el servidor de autorización. Oracle recomienda no definir esta opción en true porque puede comprometer la validación de JWT. El gateway de API confía en certificados de varias autoridades de certificación emitidas para OCI IAM con dominios de identidad, Oracle Identity Cloud Service (IDCS), Auth0 y Okta.
- "maxCacheDurationInHours": <cache-time> especifica el número de horas (entre 1 y 24) que el gateway de API almacenará en caché la respuesta del punto final de introspección.
- "additionalValidationPolicy": {"issuers": ...} especifica detalles adicionales para la validación de token:
  - <issuer-url> es la URL (o una cadena de texto) de un servidor de autorización que está permitido en la reclamación de emisor (iss) de un JWT que se utilizará para acceder al despliegue de API. Por ejemplo, para permitir que un JWT emitido por OCI IAM con dominios de identidad se utilice para acceder al despliegue de API, especifique https://identity.oraclecloud.com/. Puede especificar uno o varios servidores de autorización (hasta un máximo de cinco). Consulte Detalles del proveedor de identidad para usar en reclamaciones iss y aud y para el URI de JWKS.
  - <intended-audience> es un valor que se permite en la reclamación de público (aud) de un JWT para identificar el destinatario deseado del token. Por ejemplo, el público puede ser, pero no necesita ser, el nombre de host del gateway de API. Puede especificar uno o varios públicos (hasta un máximo de cinco). Consulte Detalles del proveedor de identidad para usar en reclamaciones iss y aud y para el URI de JWKS.
  - "verifyClaims": {...} especifica opcionalmente nombres y valores de reclamación adicionales para una o más reclamaciones adicionales que se validarán en un JWT (hasta un máximo de diez):
    - "key": "<claim-name>" es el nombre de una reclamación que puede o debe incluirse en un JWT. El nombre de reclamación que especifique puede ser un nombre de reclamación reservado, como la reclamación de asunto (sub) o un nombre de reclamación personalizado emitido por un servidor de autorización concreto.
    - "values": ["<acceptable-value>", "<acceptable-value>"] (opcionalmente) indica uno o más valores aceptables para la reclamación.
    - "isRequired": <true|false> indica si la reclamación se debe incluir en el JWT.
    Tenga en cuenta que los nombres y valores clave introducidos se manejan simplemente como cadenas y deben coincidir exactamente con los nombres y valores del JWT. No se soporta la coincidencia de patrones y otros tipos de datos
Por ejemplo, la siguiente política authentication configura el gateway de API para validar un token en la cabecera de solicitud de autorización mediante credenciales de cliente (incluido un secreto de cliente recuperado de un almacén en el servicio Vault) transferidas a un punto final de introspección OAuth 2.0):
```
{
  "requestPolicies": {
    "authentication": {
      "type": "TOKEN_AUTHENTICATION",
      "tokenHeader": "Authorization",
      "tokenAuthScheme": "Bearer",
      "isAnonymousAccessAllowed": false,
      "maxClockSkewInSeconds": 10,
      "validationPolicy": {
        "type": "REMOTE_DISCOVERY",
        "clientDetails": {
          "type": "CUSTOM",
          "clientId": "5hsti38yhy5j2a4tas455rsu6ru8yui3wrst4n1",
          "clientSecretId": "ocid1.vaultsecret.oc1.iad.amaaaaaa______cggit3q",
          "clientSecretVersionNumber": 1
        },          
        "sourceUriDetails": {
          "type": "DISCOVERY_URI",
          "uri": "https://my-idp/oauth2/default/.well-known/openid-configuration"
        },
        "isSslVerifyDisabled": false,
        "maxCacheDurationInHours": 2,
        "additionalValidationPolicy": {
          "issuers": ["https://identity.oraclecloud.com/"],
          "audiences": ["api.dev.io"],
          "verifyClaims": [{
            "key": "is_admin",
            "values": ["service:app", "read:hello"],
            "isRequired": true
          }]
        }
      }
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```
Si desea que el gateway de API valide los JWT mediante la recuperación de claves de verificación públicas del proveedor de identidad en tiempo de ejecución, agregue la siguiente política de validación a la sección validationPolicy vacía:
```
      "validationPolicy": {
        "type": "REMOTE_JWKS",
        "uri": "<uri-for-jwks>",
        "isSslVerifyDisabled": <true|false>,
        "maxCacheDurationInHours": <cache-time>,
        "additionalValidationPolicy": {
          "issuers": ["<issuer-url>", "<issuer-url>"],
          "audiences": ["<intended-audience>"],
          "verifyClaims": [{
            "key": "<claim-name>",
            "values": ["<acceptable-value>", "<acceptable-value>"],
            "isRequired": <true|false>
          }]
        }
      }
```
donde:
- "validationPolicy": {"type": "REMOTE_JWKS"... especifica que desea configurar el gateway de API para recuperar hasta diez claves de verificación públicas del proveedor de identidad en tiempo de ejecución.
- "uri": "<uri-for-jwks>" especifica el URI desde el que se va a recuperar el juego de claves web JSON (JWKS) que se va a utilizar para verificar la firma en los JWT. Para obtener más información sobre el URI que se va a especificar, consulte Detalles del proveedor de identidad para usar en reclamaciones iss y aud y para el URI de JWKS. Tenga en cuenta que:
  - El URI debe poder dirigirse desde la subred que contiene el gateway de API en el que se despliega la API.
  - Si el gateway de API no recupera el JWKS, todas las solicitudes al despliegue de API devolverán un código de respuesta HTTP 500. Consulte el log de ejecución del gateway de API para obtener más información sobre el error (consulte Agregación de registro a despliegues de API).
  - Algunos parámetros de clave deben estar presentes en el JWKS para verificar la firma del JWT (consulte Parámetros de clave necesarios para verificar las firmas de JWT).
  - El JWKS puede contener hasta diez claves.
- "isSslVerifyDisabled": <true|false> indica si se debe desactivar la verificación SSL al comunicarse con el proveedor de identidad. Oracle recomienda no definir esta opción en true porque puede comprometer la validación de JWT. El gateway de API confía en certificados de varias autoridades de certificación emitidas para OCI IAM con dominios de identidad, Oracle Identity Cloud Service (IDCS), Auth0 y Okta.
- "maxCacheDurationInHours": <cache-time> especifica el número de horas (entre 1 y 24) que el gateway de API debe almacenar en la caché el JWKS después de recuperarlo.
- "additionalValidationPolicy": {"issuers": ...} especifica detalles adicionales para la validación de token:
  - <issuer-url> es la URL (o una cadena de texto) de un proveedor de identidad que está permitido en la reclamación de emisor (iss) de un JWT que se utilizará para acceder al despliegue de API. Por ejemplo, para permitir que un JWT emitido por OCI IAM con dominios de identidad se utilice para acceder al despliegue de API, introduzca https://identity.oraclecloud.com/. Puede especificar uno o varios proveedores de identidad (hasta un máximo de cinco). Consulte Detalles del proveedor de identidad para usar en reclamaciones iss y aud y para el URI de JWKS.
  - <intended-audience> es un valor que se permite en la reclamación de público (aud) de un JWT para identificar el destinatario deseado del token. Por ejemplo, el público puede ser, pero no necesita ser, el nombre de host del gateway de API. Puede especificar uno o varios públicos (hasta un máximo de cinco). Consulte Detalles del proveedor de identidad para usar en reclamaciones iss y aud y para el URI de JWKS.
  - verifyClaims especifica opcionalmente nombres y valores de reclamación adicionales para una o más reclamaciones adicionales que se validarán en un JWT (hasta un máximo de diez).
    - "key": "<claim-name>" es el nombre de una reclamación que puede o debe incluirse en un JWT. El nombre de reclamación que especifique puede ser un nombre de reclamación reservado, como la reclamación de asunto (sub) o un nombre de reclamación personalizado emitido por un proveedor de identidad concreto.
    - "values": ["<acceptable-value>", "<acceptable-value>"] (opcionalmente) indica uno o más valores aceptables para la reclamación.
    - "isRequired": <true|false> indica si la reclamación se debe incluir en el JWT.
    Tenga en cuenta que los nombres y valores clave introducidos se manejan simplemente como cadenas y deben coincidir exactamente con los nombres y valores del JWT. No se soporta la coincidencia de patrones y otros tipos de datos
Por ejemplo, la siguiente política authentication configura el gateway de API para validar el JWT en la cabecera de solicitud de autorización mediante la recuperación de claves de verificación públicas del proveedor de identidad en tiempo de ejecución:
```
{
  "requestPolicies": {
    "authentication": {
      "type": "TOKEN_AUTHENTICATION",
      "tokenHeader": "Authorization",
      "tokenAuthScheme": "Bearer",
      "isAnonymousAccessAllowed": false,
      "validationPolicy": {
        "type": "REMOTE_JWKS",
        "uri": "https://my-tenant-id.identity.oraclecloud.com/admin/v1/SigningCert/jwk",
        "isSslVerifyDisabled": false,
        "maxCacheDurationInHours": 2,
        "additionalValidationPolicy": {
          "issuers": ["https://identity.oraclecloud.com/"],
          "audiences": ["api.dev.io"],
          "verifyClaims": [{
            "key": "is_admin",
            "values": ["service:app", "read:hello"],
            "isRequired": true
          }]
        }
      }
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```
Si desea que el gateway de API valide los JWT con claves de verificación públicas ya emitidas por un proveedor de identidad (lo que permite al gateway de API verificar los JWT localmente sin tener que ponerse en contacto con el proveedor de identidad), agregue la siguiente política de validación a la sección validationPolicy vacía:
```
      "validationPolicy": {
        "type": "STATIC_KEYS",
        "keys": [{<key-config>}],
        "isSslVerifyDisabled": <true|false>,
        "maxCacheDurationInHours": <cache-time>,
        "additionalValidationPolicy": {
          "issuers": ["<issuer-url>", "<issuer-url>"],
          "audiences": ["<intended-audience>"],
          "verifyClaims": [{
            "key": "<claim-name>",
            "values": ["<acceptable-value>", "<acceptable-value>"],
            "isRequired": <true|false>
          }]
        }
      }
```
donde:
- "validationPolicy": {"type": "STATIC_KEYS"... especifica que desea configurar el gateway de API con hasta diez claves de verificación públicas ya emitidas por un proveedor de identidad (lo que permite al gateway de API verificar los JWT localmente sin tener que ponerse en contacto con el proveedor de identidad).
- "keys": [{<key-config>}] especifique el identificador de la clave estática utilizada para firmar el JWT. Los detalles que se deben proporcionar dependen del formato de la clave ya emitida por el proveedor de identidad (independientemente del formato, puede especificar hasta diez claves):
  - Si la clave estática es una clave web JSON, especifique "format": "JSON_WEB_KEY", especifique el identificador de la clave estática utilizada para firmar el JWT como valor del parámetro "kid" y proporcione valores para otros parámetros para verificar la firma del JWT.
    
    Por ejemplo:
```
        "keys": [
          {
            "format": "JSON_WEB_KEY",
            "kid": "master_key",
            "kty": "RSA",
            "n": "0vx7agoebGc...KnqDKgw",
            "e": "AQAB",
            "alg": "RS256",
            "use": "sig"
          }
        ]
```
    Tenga en cuenta que ciertos parámetros deben estar presentes en la clave estática para verificar la firma del JWT (consulte Parámetros de clave necesarios para verificar las firmas de JWT). Tenga en cuenta también que RSA es actualmente el único tipo de clave soportado (kty).
  - Si la clave estática es una clave pública codificada por PEM, especifique "format": "PEM", especifique el identificador de la clave estática utilizada para firmar el JWT como valor "kid" y proporcione la clave como valor "key".
    
    Por ejemplo:
```
        "keys": [
          {
            "format": "PEM",
            "kid": "master_key"
            "key": -----BEGIN PUBLIC KEY-----XsEiCeYgglwW/KAhSSNRVdD60QlXYMWHOhXzSFDZCLf1WXxKMZCiMvVrsBIzmFEXnFmcsO2mxwlL5/8qQudomoP+yycJ2gWPIgqsZcQRheJWxVC5ep0MeEHlvLnEvCi9utpAnjrsZCQ7plfZVPX7XORvezwqQhBfYzwA27M2FgOOs8DOIYfqQ1Ki3DMqEppFnjLcjgQtknbTlT7YgG6tzobwig8M2KIrPjJ0BmbJAFH-----END PUBLIC KEY-----
          }
        ]
```
    Tenga en cuenta que los marcadores -----BEGIN PUBLIC KEY----- y -----END PUBLIC KEY----- son necesarios.
- "isSslVerifyDisabled": <true|false> indica si se debe desactivar la verificación SSL al comunicarse con el proveedor de identidad. Oracle recomienda no definir esta opción en true porque puede comprometer la validación de JWT. El gateway de API confía en certificados de varias autoridades de certificación emitidas para OCI IAM con dominios de identidad, Oracle Identity Cloud Service (IDCS), Auth0 y Okta.
- "maxCacheDurationInHours": <cache-time> especifica el número de horas (entre 1 y 24) que el gateway de API debe almacenar en la caché el JWKS después de recuperarlo.
- "additionalValidationPolicy": {"issuers": ...} especifica detalles adicionales para la validación de token:
  - <issuer-url> es la URL (o una cadena de texto) de un proveedor de identidad que está permitido en la reclamación de emisor (iss) de un JWT que se utilizará para acceder al despliegue de API. Por ejemplo, para permitir que un JWT emitido por OCI IAM con dominios de identidad se utilice para acceder al despliegue de API, introduzca https://identity.oraclecloud.com/. Puede especificar uno o varios proveedores de identidad (hasta un máximo de cinco). Consulte Detalles del proveedor de identidad para usar en reclamaciones iss y aud y para el URI de JWKS.
  - <intended-audience> es un valor que se permite en la reclamación de público (aud) de un JWT para identificar el destinatario deseado del token. Por ejemplo, el público puede ser, pero no necesita ser, el nombre de host del gateway de API. Puede especificar uno o varios públicos (hasta un máximo de cinco). Consulte Detalles del proveedor de identidad para usar en reclamaciones iss y aud y para el URI de JWKS.
  - verifyClaims especifica opcionalmente nombres y valores de reclamación adicionales para una o más reclamaciones adicionales que se validarán en un JWT (hasta un máximo de diez).
    - "key": "<claim-name>" es el nombre de una reclamación que puede o debe incluirse en un JWT. El nombre de reclamación que especifique puede ser un nombre de reclamación reservado, como la reclamación de asunto (sub) o un nombre de reclamación personalizado emitido por un proveedor de identidad concreto.
    - "values": ["<acceptable-value>", "<acceptable-value>"] (opcionalmente) indica uno o más valores aceptables para la reclamación.
    - "isRequired": <true|false> indica si la reclamación se debe incluir en el JWT.
    Tenga en cuenta que los nombres y valores clave introducidos se manejan simplemente como cadenas y deben coincidir exactamente con los nombres y valores del JWT. No se soporta la coincidencia de patrones y otros tipos de datos
Por ejemplo, la siguiente política authentication configura el gateway de API con una clave de verificación pública ya emitida por un proveedor de identidad para validar el JWT en la cabecera de solicitud de autorización:
```
{
  "requestPolicies": {
    "authentication": {
      "type": "TOKEN_AUTHENTICATION",
      "tokenHeader": "Authorization",
      "tokenAuthScheme": "Bearer",
      "isAnonymousAccessAllowed": false,
      "validationPolicy": {
        "type": "STATIC_KEYS",
        "keys": [
          {
            "format": "JSON_WEB_KEY",
            "kid": "master_key",
            "kty": "RSA",
            "n": "0vx7agoebGc...KnqDKgw",
            "e": "AQAB",
            "alg": "RS256",
            "use": "sig"
          }
        ],
        "isSslVerifyDisabled": false,
        "maxCacheDurationInHours": 2,
        "additionalValidationPolicy": {
          "issuers": ["https://identity.oraclecloud.com/"],
          "audiences": ["api.dev.io"],
          "verifyClaims": [{
            "key": "is_admin",
            "values": ["service:app", "read:hello"],
            "isRequired": true
          }]
        }
      }
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```
(Opcional) Puede especificar cómo desea que el gateway de API maneje una respuesta de autenticación fallida (devuelta después de un intento incorrecto de validar un token faltante o no válido) mediante la configuración de una política de fallo de validación:
1. Si desea que el gateway de API envíe un código de estado HTTP 401 y la cabecera WWW-Authenticate en la respuesta (la respuesta por defecto a un token que falta o no es válido), no defina una política de fallo de validación.
2. Si desea que el gateway de API utilice un flujo de autorización de OpenID Connect para obtener un nuevo token de acceso de JWT, defina una política de fallo de validación de tipo OAUTH2. Tenga en cuenta que esta opción solo está disponible si ha especificado un validationPolicy de tipo REMOTE_DISCOVERY anteriormente. Especifique:
```
{
  "requestPolicies": {
    "authentication": {
      "type": "TOKEN_AUTHENTICATION",
      ...
      "validationPolicy": {
        "type": "REMOTE_DISCOVERY",
        ...
      },
      "validationFailurePolicy": {
        "type": "OAUTH2",
        "scopes": ["<scope>", "<scope"],
        "clientDetails": {
          "type": "<VALIDATION_BLOCK|CUSTOM>",
          "clientId": "<client-id>",
          "clientSecretId": "<secret-ocid>",
          "clientSecretVersionNumber": <secret-version-number>
          },
        "sourceUriDetails": {
          "type": "VALIDATION_BLOCK"
          },
        "maxExpiryDurationInHours": <number-of-hours>,
        "useCookiesForSession": <true|false>,
        "useCookiesForIntermediateSteps": <true|false>,
        "usePkce": <true|false>,
        "responseType": "code",
        "fallbackRedirectPath": "<redirect-path>",
        "logoutPath": "<logout-path>"
      }
    }
  },
  "routes": [
    ...
  ]
}
```
  donde:
  - "scopes": ["<scope>", "<scope"] especifica uno o más ámbitos de acceso para incluir en una reclamación scope enviada al servidor de autorización. Para utilizar el flujo de autorización OpenID Connect, debe incluir openid como uno de los ámbitos. Por ejemplo, "scopes": ["openid", "email:read", "profile"]
  - clientDetails": {...} especifica los detalles del cliente que se utilizarán para obtener un nuevo token de acceso de JWT del servidor de autorización, de la siguiente manera:
    - "type": "<VALIDATION_BLOCK|CUSTOM>" especifica si se deben utilizar los mismos detalles de cliente o diferentes a los especificados en el validationPolicy anterior. Si desea utilizar los mismos detalles de cliente que antes (que suele ser el caso), especifique "type": "VALIDATION_BLOCK" y no proporcione detalles adicionales. Si desea utilizar diferentes detalles de cliente, especifique "type": "CUSTOM" y defina valores para "clientId", "clientSecretId" y "clientSecretVersionNumber".
    - "clientId": "<client-ID>" especifica el identificador de cliente que se enviará al punto final de introspección. Solo se utiliza si "type": "CUSTOM". Por ejemplo, 5hsti38yhy5j2a4tas455rsu6ru8yui3wrst4n1
    - "clientSecretId": "<secret-ocid>" especifica el OCID del secreto de almacén que contiene el secreto de cliente que se enviará al punto final de introspección. Solo se utiliza si "type": "CUSTOM". Por ejemplo, ocid1.vaultsecret.oc1.iad.amaaaaaa______cggit3q
    - "clientSecretVersionNumber": <secret-version-number> especifica la versión del secreto de almacén que contiene el secreto de cliente que se enviará al punto final de introspección. Solo se utiliza si "type": "CUSTOM". Por ejemplo, 1.
  - "sourceUriDetails": {"type": "VALIDATION_BLOCK"} especifica que desea utilizar la misma dirección URL que la especificada en la anterior validationPolicy y la dirección URL conocida de un servidor de autorización desde el que el gateway de API va a obtener puntos finales de metadatos de autorización.
  - "maxExpiryDurationInHours": <number-of-hours> especifica el tiempo que se tarda en almacenar en caché el token de JWT generado por el flujo de autorización. Por defecto es 1.
  - "useCookiesForSession": <true|false> especifica cómo almacenar los tokens de JWT recién generados como cadenas no legibles por el usuario al final de un flujo de autorización de conexión OpenID:
    - Defina esta opción en true si desea almacenar el nuevo token de JWT en una cookie de sesión. Para evitar posibles ataques de CSRF, cuando el gateway de API almacena el token en una cookie de sesión, también devuelve un token CSRF en una cabecera de respuesta X-CSRF-TOKEN. Las solicitudes posteriores (aparte de las solicitudes GET) deben incluir el token CSRF en una cabecera de solicitud X-CSRF-TOKEN, además del token JWT en la cookie de sesión que se incluye automáticamente.
    - Defina esta opción en false si no desea almacenar el nuevo token de JWT en una cookie de sesión. En su lugar, el gateway de API devuelve un token no legible por el usuario en una cabecera de respuesta de X-APIGW-TOKEN. Las solicitudes posteriores al gateway de API deben incluir el mismo token en una cabecera de solicitud de X-APIGW-TOKEN.
    Consulte Notas sobre la protección contra la falsificación de solicitudes entre sitios (CSRF)
  - "useCookiesForIntermediateSteps": <true|false> especifica cómo almacenar los valores de paso intermedio del flujo de autorización (por ejemplo, parámetros de solicitud). Defina esta opción en true para almacenar los valores en las cookies del explorador. Defina esta opción en false para almacenar los valores con el gateway de API.
  - "usePkce": <true|false> especifica si se debe utilizar PKCE (clave de prueba para el intercambio de código) para mayor seguridad. PKCE es una extensión de seguridad OAuth 2.0 para evitar ataques de inyección de código de autorización y CSRF (falsificación de solicitudes entre sitios). PKCE no sustituye un secreto de cliente y se recomienda PKCE incluso si se utiliza un secreto de cliente. Para obtener más información sobre PKCE, consulte la OAuth 2.0 documentation.
  - "responseType": "code" especifica el tipo de respuesta necesaria del flujo de autorización. Especifique code como tipo de respuesta.
  - "fallbackRedirectPath": "/home" especifica opcionalmente una ruta de acceso relativa en el despliegue de API actual a la que redirigir clientes de API si la solicitud original era una solicitud PUT o una solicitud POST. Por ejemplo, /home.
    Si la solicitud original era una solicitud GET, el procesamiento de solicitudes se reanuda con un nuevo token de acceso JWT, por lo que no se utiliza una ruta de acceso de reserva.
  - "logoutPath": "<revoke-path>"opcionalmente especifica una ruta de acceso relativa a un backend de desconexión en el despliegue de API actual. La ruta que especifique debe coincidir con la ruta definida para el backend de desconexión. Por ejemplo, "logoutPath": "/revoke".
    Un cliente de API puede llamar al backend de desconexión para revocar tokens. Una llamada al backend de desconexión puede incluir una URL posterior a la desconexión como parámetro de consulta denominado postLogoutUrl. Consulte Adición de desconexión como backend de gateway de API.
  Por ejemplo:
```
{
  "requestPolicies": {
    "authentication": {
      "type": "TOKEN_AUTHENTICATION",
      ...
      "validationPolicy": {
        "type": "REMOTE_DISCOVERY",
        ...
      },
      "validationFailurePolicy": {
        "type": "OAUTH2",
        "scopes": ["openid", "email:read", "profile"],
        "clientDetails": {
          "type": "VALIDATION_BLOCK"
          },
        "sourceUriDetails": {
          "type": "VALIDATION_BLOCK"
        },
        "maxExpiryDurationInHours": 2,
        "useCookiesForSession": true,
        "useCookiesForIntermediateSteps": true,
        "usePkce": true,
        "responseType": "code",
        "fallbackRedirectPath": "/home",
        "logoutPath": "/revoke"
      }
    }
  },
  "routes": [
    ...
  ]
}
```
3. Si desea personalizar la respuesta a un intento incorrecto de validar un token que falta o no es válido, defina una política de fallo de validación de tipo MODIFY_RESPONSE y especifique un código de estado (y un cuerpo de mensaje opcional) para volver al cliente de API, de la siguiente manera:
```
{
  "requestPolicies": {
    "authentication": {
      "type": "TOKEN_AUTHENTICATION",
      ...
      "validationPolicy": {
        ...
      },
      "validationFailurePolicy": {
        "type": "MODIFY_RESPONSE",
        "responseCode": "<alternative-response-code>",
        "responseMessage": "<custom-message-body>",
        "responseTransformations": {
          "headerTransformations": {
            <valid-header-transformation-response-policy>
          }
        }
      }
    }
  },
  "routes": [
    ...
  ]
}
```
  donde:
  - responseCode: especifica un código de estado HTTP alternativo. Por ejemplo, 500.
  - responseMessage: (opcionalmente) especifica un cuerpo de mensaje. Por ejemplo, Unfortunately, authentication failed. El cuerpo del mensaje puede incluir cualquier variable de contexto (excepto request.body).
  - responseTransformations: (opcionalmente) modifica las cabeceras de la respuesta que el gateway de API devuelve al cliente de API especificando una política de respuesta de transformación de cabecera. Para obtener más información sobre las políticas de transformación de cabecera, consulte Adición de políticas de respuesta de transformación de cabecera.
  Por ejemplo:
```
{
  "requestPolicies": {
    "authentication": {
      "type": "TOKEN_AUTHENTICATION",
      ...
      "validationPolicy": {
        ...
      },
      "validationFailurePolicy": {
        "type": "MODIFY_RESPONSE",
        "responseCode": "500",
        "responseMessage": "Unfortunately, authentication failed.",
      }
    }
  },
  "routes": [
    ...
  ]
}
```
Agregue una política de solicitud authorization para cada ruta en la especificación de despliegue de API:
1. Inserte una sección requestPolicies después de la sección backend de la primera ruta, si no existe ninguna. Por ejemplo:
```
{
  "requestPolicies": {
    "authentication": {
      "type": "TOKEN_AUTHENTICATION",
      "tokenHeader": "Authorization",
      "tokenAuthScheme": "Bearer",
      "isAnonymousAccessAllowed": false,
      "validationPolicy": {
        "type": "STATIC_KEYS",
        "keys": [
          {
            "format": "JSON_WEB_KEY",
            "kid": "master_key",
            "kty": "RSA",
            "n": "0vx7agoebGc...KnqDKgw",
            "e": "AQAB",
            "alg": "RS256",
            "use": "sig"
          }
        ],
        "isSslVerifyDisabled": false,
        "maxCacheDurationInHours": 2,
        "additionalValidationPolicy": {
          "issuers": ["https://identity.oraclecloud.com/"],
          "audiences": ["api.dev.io"],
          "verifyClaims": [{
            "key": "is_admin",
            "values": ["service:app", "read:hello"],
            "isRequired": true
          }]
        }
      }
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      },
      "requestPolicies": {}
    }
  ]
}
```
2. Agregue la siguiente política authorization a la nueva sección requestPolicies:
```
      "requestPolicies": {
        "authorization": {
          "type": <"AUTHENTICATION_ONLY"|"ANY_OF"|"ANONYMOUS">, 
          "allowedScope": [ "<scope>" ]
        }
      }
```
  donde:
  - "type": <"AUTHENTICATION_ONLY"|"ANY_OF"|"ANONYMOUS"> indica cómo otorgar acceso a la ruta:
    - "AUTHENTICATION_ONLY": solo otorga acceso a usuarios finales que se hayan autenticado correctamente En este caso, la propiedad "isAnonymousAccessAllowed" de la política authentication de la especificación de despliegue de API no tiene ningún efecto.
    - "ANY_OF": solo otorga acceso a usuarios finales que se hayan autenticado correctamente, siempre que la reclamación scope del JWT incluya uno de los ámbitos de acceso que especifique en la propiedad allowedScope. En este caso, la propiedad "isAnonymousAccessAllowed" de la política authentication de la especificación de despliegue de API no tiene ningún efecto.
    - "ANONYMOUS": otorga acceso a todos los usuarios finales, incluso si no se han autenticado correctamente. En este caso, debe definir explícitamente la propiedad "isAnonymousAccessAllowed" en true en la política authentication de la especificación de despliegue de API.
  - "allowedScope": [ "<scope>" ] es una lista delimitada por comas de una o varias cadenas que corresponden a ámbitos de acceso incluidos en la reclamación scope del JWT. En este caso, debe definir la propiedad type en "ANY_OF" (la propiedad "allowedScope" se ignora si la propiedad type se define en "AUTHENTICATION_ONLY" o "ANONYMOUS"). También debe tener en cuenta que si especifica más de un ámbito, se otorga acceso a la ruta si cualquiera de los ámbitos que ha especificado se incluye en la reclamación scope del JWT.
  Por ejemplo, la siguiente política de solicitud define una ruta /hello que solo permite el acceso a los usuarios finales autenticados con el ámbito read:hello:
```
{
  "requestPolicies": {
    "authentication": {
      "type": "TOKEN_AUTHENTICATION",
      "tokenHeader": "Authorization",
      "tokenAuthScheme": "Bearer",
      "isAnonymousAccessAllowed": false,
      "validationPolicy": {
        "type": "STATIC_KEYS",
        "keys": [
          {
            "format": "JSON_WEB_KEY",
            "kid": "master_key",
            "kty": "RSA",
            "n": "0vx7agoebGc...KnqDKgw",
            "e": "AQAB",
            "alg": "RS256",
            "use": "sig"
          }
        ],
        "isSslVerifyDisabled": false,
        "maxCacheDurationInHours": 2,
        "additionalValidationPolicy": {
          "issuers": ["https://identity.oraclecloud.com/"],
          "audiences": ["api.dev.io"],
          "verifyClaims": [{
            "key": "is_admin",
            "values": ["service:app", "read:hello"],
            "isRequired": true
          }]
        }
      }
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      },
      "requestPolicies": {
        "authorization": {
          "type": "ANY_OF",
          "allowedScope": [ "read:hello" ]
        }
      }
    }
  ]
}
```
3. Agregue una política de solicitud authorization para el resto de rutas de la especificación de despliegue de API.
Nota

Si no incluye ninguna política authorization para una ruta concreta, se otorga el acceso como si esa política existiera y la propiedad type se define en "AUTHENTICATION_ONLY". Es decir, independientemente de la configuración de la propiedad isAnonymousAccessAllowed en la política authentication de la especificación de despliegue de API:
- solo pueden acceder a la ruta los usuarios finales autenticados
- todos los usuarios finales autenticados pueden acceder a la ruta independientemente de los ámbitos de acceso en la reclamación de scope de JWT
- los usuarios finales anónimos no pueden acceder a la ruta
Guarde el archivo JSON que contiene la especificación de despliegue de API.
Utilice la especificación de despliegue de API al crear o actualizar un despliegue de API de las siguientes formas:
- Especificando el archivo JSON en la consola al seleccionar la opción Cargar API.
- Especificando el archivo JSON en una solicitud para la API REST de gateway de API.
Para obtener más información, consulte Despliegue de una API en un gateway de API mediante la creación de un despliegue de API y Actualización de un gateway de API.
(Opcional) Confirme que la API se ha desplegado correctamente llamándola. Para ello, consulte Llamada a una API desplegada en un gateway de API.

Detalles del proveedor de identidad para usar en reclamaciones iss y aud y para el URI de JWKS

El proveedor de identidad que emitió el JWT determina los valores permitidos que debe especificar para las reclamaciones de emisor (iss) y público (aud) en el JWT. El proveedor de identidad que emitió el JWT también determina el URI desde el que recuperar el juego de claves web JSON (JWKS) para verificar la firma en el JWT.

Tenga en cuenta que, independientemente del proveedor de identidad, un JWKS puede contener un máximo de diez claves.

Utilice la siguiente tabla para averiguar qué especificar para los JWT emitidos por OCI IAM con dominios de identidad, Oracle Identity Cloud Service (IDCS), Okta y los proveedores de identidad Auth0.


Proveedor de identidad	Reclamación de emisor (`iss`)	Reclamación de público (`aud`)	Formato de URI desde el que recuperar el JWKS
IAM de OCI con dominios de identidad	https://identity.oraclecloud.com	Específico del cliente. Consulte Gestión de aplicaciones en la documentación de OCI IAM con dominios de identidad.	https://<tenant-base-url>/admin/v1/SigningCert/jwk
IDCS	https://identity.oraclecloud.com/	Específico del cliente. Consulte Validación de tokens de acceso en la documentación de Oracle Identity Cloud Service.	https://<tenant-base-url>/admin/v1/SigningCert/jwk Para obtener el JWKS sin conectarse a Oracle Identity Cloud Service, consulte Cambiar configuración por defecto en la documentación de Oracle Identity Cloud Service.
Okta	https://<your-okta-tenant-name>.com	Específico del cliente. Público configurado para el servidor de autorización en la consola del desarrollador de Okta. Consulte Validación adicional para tokens de acceso en la documentación de Okta.	https://<your-okta-tenant-name>.com/oauth2/<auth-server-id> /v1/keys Consulte la documentación de Okta.
Auth0	https://<your-account-name>.auth0.com/	Específico del cliente. Consulte Público en la documentación de Auth0.	https://<your-account-name>.auth0.com/.well-known/jwks.json

Parámetros de clave necesarios para verificar las firmas de JWT

Para verificar la firma en un JWT, los gateways de API requieren que los siguientes parámetros de clave estén presentes en el JWKS devuelto de un URI o en la clave web JSON estática especificada.


Parámetro de clave	Notas
`kid`	Identificador de la clave utilizada para firmar el JWT. El valor debe coincidir con la reclamación `kid` en la cabecera de JWT. Por ejemplo, `master_key`.
`kty`	Tipo de clave utilizada para firmar el JWT. Tenga en cuenta que RSA es actualmente el único tipo de clave soportado.
`use` o `key_ops`	Si el parámetro `use` está presente, debe definirse en `sig`. Si el parámetro `key-ops` está presente, `verify` debe ser uno de los valores válidos.
`n`	Módulo de clave pública.
`e`	Exponente de la clave pública.
`alg`	El algoritmo de firma (si está presente) se debe definir en RS256, RS384 o RS512.

Uso de una política de solicitud de autenticación JWT_AUTHENTICATION (ya no se recomienda)

Nota

En versiones anteriores, es posible que haya creado políticas de solicitud de autenticación de tipo JWT_AUTHENTICATION para utilizar JWT para la autenticación.

Tenga en cuenta que las políticas de solicitud JWT_AUTHENTICATION existentes aún están soportadas. Tenga en cuenta también que, aunque puede crear nuevas políticas de solicitud JWT_AUTHENTICATION definiendo la especificación de despliegue de API en un archivo JSON (como se describe en las instrucciones originales de esta sección), le recomendamos que cree políticas de solicitud de autenticación de tipo TOKEN_AUTHENTICATION en su lugar.

Al utilizar una política de solicitud de autenticación de tipo JWT_AUTHENTICATION, antes de que un usuario final pueda acceder a un despliegue de API que utilice JWT para la autenticación y autorización, debe obtener un JWT de un proveedor de identidad.

Al llamar a una API desplegada en un gateway de API, el cliente de API proporciona el JWT como parámetro de consulta o en la cabecera de la solicitud. El gateway de API valida el JWT mediante una clave de verificación pública correspondiente proporcionada por el proveedor de identidad emisor. Mediante la política de solicitud de autenticación JWT_AUTHENTICATION del despliegue de API, puede configurar cómo valida los JWT el gateway de API:

Puede configurar el gateway de API para recuperar claves de verificación públicas del proveedor de identidad en tiempo de ejecución. En este caso, el proveedor de identidad actúa como servidor de autorización.
Puede configurar el gateway de API con antelación con claves de verificación públicas ya emitidas por un proveedor de identidad (denominadas "claves estáticas"), lo que permite al gateway de API verificar los JWT localmente en tiempo de ejecución sin tener que ponerse en contacto con el proveedor de identidad. El resultado es una validación de token más rápida.

Para agregar una nueva política de solicitud de autorización y autenticación JWT_AUTHENTICATION a una especificación de despliegue de API en un archivo JSON:

Agregue una política de solicitud authentication que se aplique a todas las rutas de la especificación de despliegue de API:
1. Inserte una sección requestPolicies antes de la sección routes si no existe ninguna. Por ejemplo:
```
{
  "requestPolicies": {},
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
         "type": "ORACLE_FUNCTIONS_BACKEND",
         "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```
2. Agregue la siguiente política authentication a la nueva sección requestPolicies.
```
{
  "requestPolicies": {
    "authentication": {
      "type": "JWT_AUTHENTICATION",
      "isAnonymousAccessAllowed": <true|false>,
      "issuers": ["<issuer-url>", "<issuer-url>"],
      <"tokenHeader"|"tokenQueryParam">: <"<token-header-name>"|"<token-query-param-name>">,
      "tokenAuthScheme": "<authentication-scheme>",
      "audiences": ["<intended-audience>"],
      "publicKeys": {
        "type": <"REMOTE_JWKS"|"STATIC_KEYS">,
        <public-key-config>
      },
      "verifyClaims": [
        {"key": "<claim-name>",
         "values": ["<acceptable-value>", "<acceptable-value>"],
         "isRequired": <true|false>
        }
      ],
      "maxClockSkewInSeconds": <seconds-difference>
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```
  donde:
  - "isAnonymousAccessAllowed": <true|false> opcionalmente indica si los usuarios finales no autenticados (es decir, anónimos) pueden acceder a rutas en la especificación de despliegue de API. Si desea que los usuarios finales anónimos no puedan acceder a rutas, defina esta propiedad en false. Si no incluye esta propiedad en la política authentication, se utilizará el valor por defecto false. Tenga en cuenta que si incluye esta propiedad y la define en true, también tendrá que especificar explícitamente cada ruta en la que se permite el acceso anónimo, definiendo la propiedad type en "ANONYMOUS" en la política authorization de cada ruta.
  - <issuer-url> es la URL (o una cadena de texto) de un proveedor de identidad que está permitido en la reclamación de emisor (iss) de un JWT que se utilizará para acceder al despliegue de API. Por ejemplo, para permitir que un JWT emitido por OCI IAM con dominios de identidad se utilice para acceder al despliegue de API, introduzca https://identity.oraclecloud.com/. Puede especificar uno o varios proveedores de identidad (hasta un máximo de cinco). Consulte Detalles del proveedor de identidad para usar en reclamaciones iss y aud y para el URI de JWKS.
  - <"tokenHeader"|"tokenQueryParam">: <"<token-header-name>"|"<token-query-param-name>"> indica si se trata de una cabecera de solicitud que contiene el JWT (y, si lo contiene, también indica el nombre de la cabecera) o un parámetro de consulta que contiene el JWT (y, si lo contiene, también indica el nombre del parámetro de consulta). Tenga en cuenta que puede especificar "tokenHeader": "<token-header-name>" o "tokenQueryParam": "<token-query-param-name>">, pero no los dos.
  - <tokenAuthScheme> es el nombre del esquema de autenticación que se va a utilizar si una cabecera de solicitud contiene el JWT. Por ejemplo, "Bearer".
  - <intended-audience> es un valor que se permite en la reclamación de público (aud) de un JWT para identificar el destinatario deseado del token. Por ejemplo, el público puede ser, pero no necesita ser, el nombre de host del gateway de API. Puede especificar uno o varios públicos (hasta un máximo de cinco). Consulte Detalles del proveedor de identidad para usar en reclamaciones iss y aud y para el URI de JWKS.
  - "type": <"REMOTE_JWKS"|"STATIC_KEYS"> indica cómo desea que el gateway de API valide los JWT mediante claves de verificación públicas. Especifique REMOTE_JWKS para configurar el gateway de API para recuperar hasta diez claves de verificación públicas del proveedor de identidad en tiempo de ejecución. Especifique STATIC_KEYS para configurar el gateway de API con hasta diez claves de verificación públicas ya emitidas por un proveedor de identidad (lo que permite al gateway de API verificar los JWT localmente sin tener que ponerse en contacto con el proveedor de identidad).
  - <public-key-config> proporciona los detalles de la validación de JWT, según si especificó "REMOTE_JWKS" o "STATIC_KEYS" como el valor de "type": de la siguiente manera:
    - Si ha especificado "type": "REMOTE_JWKS" para configurar el gateway de API para validar los JWT recuperando claves de verificación públicas del proveedor de identidad en tiempo de ejecución, proporcione los detalles siguientes:
      "publicKeys": { "type": "REMOTE_JWKS", "uri": "<uri-for-jwks>", "maxCacheDurationInHours": <cache-time>, "isSslVerifyDisabled": <true|false> }
      donde:
      - "uri": "<uri-for-jwks>" especifica el URI desde el que se va a recuperar el juego de claves web JSON (JWKS) que se va a utilizar para verificar la firma en los JWT. Para obtener más información sobre el URI que se va a especificar, consulte Detalles del proveedor de identidad para usar en reclamaciones iss y aud y para el URI de JWKS. Tenga en cuenta que:
        
        El URI debe poder dirigirse desde la subred que contiene el gateway de API en el que se despliega la API.
        
        Si el gateway de API no recupera el JWKS, todas las solicitudes al despliegue de API devolverán un código de respuesta HTTP 500. Consulte el log de ejecución del gateway de API para obtener más información sobre el error (consulte Agregación de registro a despliegues de API).
        
        Algunos parámetros de clave deben estar presentes en el JWKS para verificar la firma del JWT (consulte Parámetros de clave necesarios para verificar las firmas de JWT).
        
        El JWKS puede contener hasta diez claves.
      - "maxCacheDurationInHours": <cache-time> especifica el número de horas (entre 1 y 24) que el gateway de API debe almacenar en la caché el JWKS después de recuperarlo.
      - "isSslVerifyDisabled": <true|false> indica si se debe desactivar la verificación SSL al comunicarse con el proveedor de identidad. Oracle recomienda no definir esta opción en trueporque puede comprometer la validación de JWT. El gateway de API confía en certificados de varias autoridades de certificación emitidas para OCI IAM con dominios de identidad, Oracle Identity Cloud Service (IDCS), Auth0 y Okta.
      Por ejemplo:
      "publicKeys": { "type": "REMOTE_JWKS", "uri": "https://www.somejwksprovider.com/oauth2/v3/certs", "maxCacheDurationInHours": 3, "isSslVerifyDisabled": false }
    - Si ha especificado "type": "STATIC_KEYS", los detalles que debe proporcionar dependen del formato de la clave ya emitida por el proveedor de identidad (independientemente del formato, puede especificar hasta diez claves):
      - Si la clave estática es una clave web JSON, especifique "format": "JSON_WEB_KEY", especifique el identificador de la clave estática utilizada para firmar el JWT como valor del parámetro "kid" y proporcione valores para otros parámetros para verificar la firma del JWT.
        
        Por ejemplo:
        
        "publicKeys": { "type": "STATIC_KEYS", "keys": [ { "format": "JSON_WEB_KEY", "kid": "master_key", "kty": "RSA", "n": "0vx7agoebGc...KnqDKgw", "e": "AQAB", "alg": "RS256", "use": "sig" } ]
        
        Tenga en cuenta que ciertos parámetros deben estar presentes en la clave estática para verificar la firma del JWT (consulte Parámetros de clave necesarios para verificar las firmas de JWT). Tenga en cuenta también que RSA es actualmente el único tipo de clave soportado (kty).
      - Si la clave estática es una clave pública codificada por PEM, especifique "format": "PEM", especifique el identificador de la clave estática utilizada para firmar el JWT como valor "kid" y proporcione la clave como valor "key".
        
        Por ejemplo:
        
        "publicKeys": { "type": "STATIC_KEYS", "keys": [ { "format": "PEM", "kid": "master_key" "key": -----BEGIN PUBLIC KEY-----XsEiCeYgglwW/KAhSSNRVdD60QlXYMWHOhXzSFDZCLf1WXxKMZCiMvVrsBIzmFEXnFmcsO2mxwlL5/8qQudomoP+yycJ2gWPIgqsZcQRheJWxVC5ep0MeEHlvLnEvCi9utpAnjrsZCQ7plfZVPX7XORvezwqQhBfYzwA27M2FgOOs8DOIYfqQ1Ki3DMqEppFnjLcjgQtknbTlT7YgG6tzobwig8M2KIrPjJ0BmbJAFH-----END PUBLIC KEY----- } ]
        
        Tenga en cuenta que los marcadores -----BEGIN PUBLIC KEY----- y -----END PUBLIC KEY----- son necesarios.
  - verifyClaims especifica opcionalmente nombres y valores de reclamación adicionales para una o más reclamaciones adicionales que se validarán en un JWT (hasta un máximo de diez).
    - "key": "<claim-name>" es el nombre de una reclamación que puede o debe incluirse en un JWT. El nombre de reclamación que especifique puede ser un nombre de reclamación reservado, como la reclamación de asunto (sub) o un nombre de reclamación personalizado emitido por un proveedor de identidad concreto.
    - "values": ["<acceptable-value>", "<acceptable-value>"] (opcionalmente) indica uno o más valores aceptables para la reclamación.
    - "isRequired": <true|false> indica si la reclamación se debe incluir en el JWT.
    Tenga en cuenta que los nombres y valores clave introducidos se manejan simplemente como cadenas y deben coincidir exactamente con los nombres y valores del JWT. No se soporta la coincidencia de patrones y otros tipos de datos
  - maxClockSkewInSeconds: <seconds-difference> especifica opcionalmente la diferencia de tiempo máxima entre los relojes del sistema del proveedor de identidad que emitió un JWT y el gateway de API. El valor especificado se tiene en cuenta cuando el gateway de API valida el JWT para determinar si sigue siendo válido, utilizando la reclamación de "no antes de" (nbf) (si está presente) y la reclamación de caducidad (exp) en el JWT. El mínimo (por defecto) es 0, el máximo, 120.
  Por ejemplo, la siguiente política authentication configura el gateway de API con una clave de verificación pública ya emitida por un proveedor de identidad para validar el JWT en la cabecera de solicitud de autorización:
```
{
  "requestPolicies": {
    "authentication": {
      "type": "JWT_AUTHENTICATION",
      "isAnonymousAccessAllowed": false,
      "issuers": ["https://identity.oraclecloud.com/"],
      "tokenHeader": "Authorization",
      "tokenAuthScheme": "Bearer",
      "audiences": ["api.dev.io"],
      "publicKeys": {
        "type": "STATIC_KEYS",
        "keys": [
          {
            "format": "JSON_WEB_KEY",
            "kid": "master_key",
            "kty": "RSA",
            "n": "0vx7agoebGc...KnqDKgw",
            "e": "AQAB",
            "alg": "RS256",
            "use": "sig"
          }
        ]
      },
      "verifyClaims": [
        {
          "key": "is_admin",
          "values": ["service:app", "read:hello"],
          "isRequired": true
        }
      ],
      "maxClockSkewInSeconds": 10
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```

Agregue una política de solicitud authorization para cada ruta en la especificación de despliegue de API:

Inserte una sección requestPolicies después de la sección backend de la primera ruta, si no existe ninguna. Por ejemplo:

{
  "requestPolicies": {
    "authentication": {
      "type": "JWT_AUTHENTICATION",
      "isAnonymousAccessAllowed": false,
      "issuers": ["https://identity.oraclecloud.com/"],
      "tokenHeader": "Authorization",
      "tokenAuthScheme": "Bearer",
      "audiences": ["api.dev.io"],
      "publicKeys": {
        "type": "STATIC_KEYS",
        "keys": [
          {
            "format": "JSON_WEB_KEY",
            "kid": "master_key",
            "kty": "RSA",
            "n": "0vx7agoebGc...KnqDKgw",
            "e": "AQAB",
            "alg": "RS256",
            "use": "sig"
          }
        ]
      },
      "verifyClaims": [
        {
          "key": "is_admin",
          "values": ["service:app", "read:hello"],
          "isRequired": true
        }
      ],
      "maxClockSkewInSeconds": 10
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
         "type": "ORACLE_FUNCTIONS_BACKEND",
         "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      },
      "requestPolicies": {}
    }
  ]
}

Agregue la siguiente política authorization a la sección requestPolicies:

{
  "requestPolicies": {
    "authentication": {
      "type": "JWT_AUTHENTICATION",
      "isAnonymousAccessAllowed": false,
      "issuers": ["https://identity.oraclecloud.com/"],
      "tokenHeader": "Authorization",
      "tokenAuthScheme": "Bearer",
      "audiences": ["api.dev.io"],
      "publicKeys": {
        "type": "STATIC_KEYS",
        "keys": [
          {
            "format": "JSON_WEB_KEY",
            "kid": "master_key",
            "kty": "RSA",
            "n": "0vx7agoebGc...KnqDKgw",
            "e": "AQAB",
            "alg": "RS256",
            "use": "sig"
          }
        ]
      },
      "verifyClaims": [
        {
          "key": "is_admin",
          "values": ["service:app", "read:hello"],
          "isRequired": true
        }
      ],
      "maxClockSkewInSeconds": 10
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      },
      "requestPolicies": {
        "authorization": {
          "type": <"AUTHENTICATION_ONLY"|"ANY_OF"|"ANONYMOUS">, 
          "allowedScope": [ "<scope>" ]
        }
      }
    }
  ]
}

donde:

"type": <"AUTHENTICATION_ONLY"|"ANY_OF"|"ANONYMOUS"> indica cómo otorgar acceso a la ruta:
- "AUTHENTICATION_ONLY": solo otorga acceso a usuarios finales que se hayan autenticado correctamente En este caso, la propiedad "isAnonymousAccessAllowed" de la política authentication de la especificación de despliegue de API no tiene ningún efecto.
- "ANY_OF": solo otorga acceso a usuarios finales que se hayan autenticado correctamente, siempre que la reclamación scope del JWT incluya uno de los ámbitos de acceso que especifique en la propiedad allowedScope. En este caso, la propiedad "isAnonymousAccessAllowed" de la política authentication de la especificación de despliegue de API no tiene ningún efecto.
- "ANONYMOUS": otorga acceso a todos los usuarios finales, incluso si no se han autenticado correctamente. En este caso, debe definir explícitamente la propiedad "isAnonymousAccessAllowed" en true en la política authentication de la especificación de despliegue de API.
"allowedScope": [ "<scope>" ] es una lista delimitada por comas de una o varias cadenas que corresponden a ámbitos de acceso incluidos en la reclamación scope del JWT. En este caso, debe definir la propiedad type en "ANY_OF" (la propiedad "allowedScope" se ignora si la propiedad type se define en "AUTHENTICATION_ONLY" o "ANONYMOUS"). También debe tener en cuenta que si especifica más de un ámbito, se otorga acceso a la ruta si cualquiera de los ámbitos que ha especificado se incluye en la reclamación scope del JWT.

Por ejemplo, la siguiente política de solicitud define una ruta /hello que solo permite el acceso a los usuarios finales autenticados con el ámbito read:hello:

{
  "requestPolicies": {
    "authentication": {
      "type": "JWT_AUTHENTICATION",
      "isAnonymousAccessAllowed": false,
      "issuers": ["https://identity.oraclecloud.com/"],
      "tokenHeader": "Authorization",
      "tokenAuthScheme": "Bearer",
      "audiences": ["api.dev.io"],
      "publicKeys": {
        "type": "STATIC_KEYS",
        "keys": [
          {
            "format": "JSON_WEB_KEY",
            "kid": "master_key",
            "kty": "RSA",
            "n": "0vx7agoebGc...KnqDKgw",
            "e": "AQAB",
            "alg": "RS256",
            "use": "sig"
          }
        ]
      },
      "verifyClaims": [
        {
          "key": "is_admin",
          "values": ["service:app", "read:hello"],
          "isRequired": true
        }
      ],
      "maxClockSkewInSeconds": 10
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      },
      "requestPolicies": {
        "authorization": {
          "type": "ANY_OF",
          "allowedScope": [ "read:hello" ]
        }
      }
    }
  ]
}

Agregue una política de solicitud authorization para el resto de rutas de la especificación de despliegue de API.

Nota

Si no incluye ninguna política authorization para una ruta concreta, se otorga el acceso como si esa política existiera y la propiedad type se define en "AUTHENTICATION_ONLY". Es decir, independientemente de la configuración de la propiedad isAnonymousAccessAllowed en la política authentication de la especificación de despliegue de API:

solo pueden acceder a la ruta los usuarios finales autenticados
todos los usuarios finales autenticados pueden acceder a la ruta independientemente de los ámbitos de acceso en la reclamación de scope de JWT
los usuarios finales anónimos no pueden acceder a la ruta

Guarde el archivo JSON que contiene la especificación de despliegue de API.
Utilice la especificación de despliegue de API al crear o actualizar un despliegue de API de las siguientes formas:
- Especificando el archivo JSON en la consola al seleccionar la opción Cargar API.
- Especificando el archivo JSON en una solicitud para la API REST de gateway de API.
Para obtener más información, consulte Despliegue de una API en un gateway de API mediante la creación de un despliegue de API y Actualización de un gateway de API.
(Opcional) Confirme que la API se ha desplegado correctamente llamándola. Para ello, consulte Llamada a una API desplegada en un gateway de API.

Ejemplo: Migración de una política de solicitud JWT_AUTHENTICATION a una política de solicitud TOKEN_AUTHENTICATION

En esta sección se muestra un ejemplo de una política de solicitud JWT_AUTHENTICATION existente migrada a una política TOKEN_AUTHENTICATION.

Una forma de abordar la migración es crear una política de solicitud TOKEN_AUTHENTICATION vacía y, a continuación, rellenarla con valores de la política de solicitud JWT_AUTHENTICATION

Antes de migración:

La política de solicitud JWT_AUTHENTICATION original, antes de la migración:

{
  "requestPolicies": {
    "authentication": {
      "type": "JWT_AUTHENTICATION",
      "isAnonymousAccessAllowed": false,
      "issuers": ["https://identity.oraclecloud.com/"],
      "tokenHeader": "Authorization",
      "tokenAuthScheme": "Bearer",
      "audiences": ["api.dev.io"],
      "publicKeys": {
        "type": "STATIC_KEYS",
        "keys": [
          {
            "format": "JSON_WEB_KEY",
            "kid": "master_key",
            "kty": "RSA",
            "n": "0vx7agoebGc...KnqDKgw",
            "e": "AQAB",
            "alg": "RS256",
            "use": "sig"
          }
        ]
      },
      "verifyClaims": [
        {
          "key": "is_admin",
          "values": ["service:app", "read:hello"],
          "isRequired": true
        }
      ],
      "maxClockSkewInSeconds": 10
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      },
      "requestPolicies": {
        "authorization": {
          "type": "ANY_OF",
          "allowedScope": [ "read:hello" ]
        }
      }
    }
  ]
}

Después de la migración:

La nueva política de solicitud TOKEN_AUTHENTICATION rellena con valores de la política de solicitud JWT_AUTHENTICATION original:

{
  "requestPolicies": {
    "authentication": {
      "type": "TOKEN_AUTHENTICATION",
      "isAnonymousAccessAllowed": false,
      "tokenHeader": "Authorization",
      "tokenAuthScheme": "Bearer",
      "maxClockSkewInSeconds": 10,
      "validationPolicy": {
        "type": "STATIC_KEYS",
        "keys": [
          {
            "format": "JSON_WEB_KEY",
            "kid": "master_key",
            "kty": "RSA",
            "n": "0vx7agoebGc...KnqDKgw",
            "e": "AQAB",
            "alg": "RS256",
            "use": "sig"
          }
        ],
        "additionalValidationPolicy": {
          "audiences": [
            "api.dev.io"
          ],
          "verifyClaims": [
            {
              "key": "is_admin",
              "values": [
                "service:app",
                "read:hello"
              ],
              "isRequired": true
            }
          ],
          "issuers": [
            "https://identity.oraclecloud.com/"
          ]
        }
      }
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": [
        "GET"
      ],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      },
      "requestPolicies": {
        "authorization": {
          "type": "ANY_OF",
          "allowedScope": [
            "read:hello"
          ]
        }
      }
    }
  ]
}

Documentación de Oracle Cloud Infrastructure

Validación de tokens para agregar autenticación y autorización a despliegues de API

¿Qué sucede durante la autenticación de token?

Notas sobre los tokens web JSON (JWT)

Notas sobre OAuth 2.0 y OpenID Connect

Notas sobre la protección contra la falsificación de solicitudes entre centros (CSRF)

Notas sobre el uso de políticas de solicitud JWT_AUTHENTICATION

Requisitos para la Autenticación de Token

Uso de la consola para agregar políticas de solicitud de autenticación y autorización de token

Edición de un archivo JSON para agregar políticas de solicitud de autorización y autenticación de token

Detalles del proveedor de identidad para usar en reclamaciones iss y aud y para el URI de JWKS

Parámetros de clave necesarios para verificar las firmas de JWT

Uso de una política de solicitud de autenticación JWT_AUTHENTICATION (ya no se recomienda)

Ejemplo: Migración de una política de solicitud JWT_AUTHENTICATION a una política de solicitud TOKEN_AUTHENTICATION

Antes de migración:

Después de la migración: