---
title: "Enrutamiento dinámico basado en credenciales de usuario con API Gateway - API7.ai"
description: "En este artículo, aprenderás cómo enrutar dinámicamente las solicitudes de los clientes a los servicios backend responsables basándote en las reclamaciones (claims) del token JWT."
url: "https://api7.ai/es/blog/dynamic-routing-based-on-user-credentials"
---

[Blog](https://api7.ai/es/blog)

[Products](https://api7.ai/es/category/products)[Technology](https://api7.ai/es/category/technology)[Ecosystem](https://api7.ai/es/category/ecosystem)[Case Study](https://api7.ai/es/category/usercase)[Team & Community](https://api7.ai/es/category/community)

Search

⌘ + K

[Blog](https://api7.ai/blog)

Technology

# Enrutamiento dinámico basado en credenciales de usuario con API Gateway

[![Bobur Umurzokov](https://avatars.githubusercontent.com/u/14247607)](https://www.linkedin.com/in/boburumurzokov/)

[Bobur Umurzokov](https://www.linkedin.com/in/boburumurzokov/)

April 9, 2023

[Technology](https://api7.ai/category/technology)

## Enrutamiento dinámico basado en reclamaciones JWT con Apache APISIX y Okta

El enrutamiento dinámico es una característica poderosa de la mayoría de las puertas de enlace de API modernas que permite enrutar solicitudes entrantes en tiempo real a diferentes servicios backend según varios criterios, como encabezados HTTP, parámetros de consulta o incluso el cuerpo de la solicitud.

Al aprovechar los complementos integrados existentes de Apache APISIX, los desarrolladores también pueden crear reglas de enrutamiento dinámico basadas en varias credenciales de usuario, como tokens de acceso, claves de API o ID de usuario. En este artículo, exploraremos los beneficios de adoptar el **enrutamiento dinámico basado en atributos de autenticación** con [Apache APISIX](https://apisix.apache.org/) y te mostraremos un ejemplo de configuración de **cómo enrutar dinámicamente las solicitudes de los clientes** a los servicios backend responsables basándose en la reclamación del token [JWT](https://jwt.io/).

## Objetivos de aprendizaje

A lo largo del artículo aprenderás lo siguiente:

- Enrutar dinámicamente el tráfico con una puerta de enlace de API.
- ¿Por qué necesitamos el enrutamiento dinámico basado en credenciales de usuario?
- Enrutamiento dinámico basado en reclamaciones de tokens JWT con Apache APISIX.

## Puerta de enlace de API: Enrutamiento dinámico de tráfico

El enrutamiento dinámico de tráfico con la puerta de enlace de API se puede utilizar en una amplia gama de aplicaciones y escenarios para optimizar el rendimiento, mejorar la seguridad y garantizar que los usuarios tengan acceso a los recursos adecuados.

Al enrutar dinámicamente el tráfico, un sistema puede equilibrar la [carga entre diferentes servidores](https://apisix.apache.org/blog/2022/10/27/ten-use-cases-api-gateway/#api-fault-handling) o servicios. Puede ayudar a garantizar la alta disponibilidad al enrutar el tráfico a servicios o servidores disponibles. Si un servicio o servidor falla, el tráfico puede redirigirse automáticamente a otro servicio o servidor disponible.

![Enrutamiento dinámico de tráfico con Apache APISIX](https://static.api7.ai/uploads/2024/12/25/HTTlIPf1_comsuming-apps.png?imageMogr2/format/webp)

El enrutamiento dinámico también se puede utilizar para enrutar el tráfico [basado en la geolocalización](https://apisix.apache.org/blog/2022/11/09/georouting-apisix/) del usuario. Esto puede ayudar a garantizar que los usuarios se conecten al servidor o servicio más cercano, mejorando los tiempos de respuesta y reduciendo la latencia.

![Enrutamiento de tráfico basado en geolocalización con Apache APISIX](https://static.api7.ai/uploads/2024/12/25/SPlRD3zv_consuming-apps-1.png?imageMogr2/format/webp)

## Puerta de enlace de API: Enrutamiento dinámico basado en la identidad del usuario

A menudo, queremos enrutar el tráfico a servicios específicos, rutas o mostrar solo datos relacionados con el usuario basados en la identidad proporcionada por el usuario. Por ejemplo, en aplicaciones multiinquilino, diferentes inquilinos pueden tener acceso a diferentes servicios o recursos. En este caso, la puerta de enlace de API puede enrutar el tráfico solo a los recursos del inquilino adecuado basándose en las credenciales del usuario. O en aplicaciones móviles, puede enrutar el tráfico a servicios específicos según el tipo de dispositivo o sistema operativo.

Uno de los enfoques comunes es utilizar tokens JWT para autenticar y autorizar solicitudes a las API. Esto significa que podemos crear reglas de enrutamiento complejas con la puerta de enlace de API que tengan en cuenta las reclamaciones presentes en el token JWT y utilicen esta información para decidir a dónde reenviar la solicitud o qué datos mostrar. Este enfoque es particularmente útil cuando tienes múltiples usuarios en el sistema que requieren diferentes niveles de control de acceso.

![Enrutamiento dinámico de tráfico basado en tokens JWT con Apache APISIX](https://static.api7.ai/uploads/2024/12/25/NyANg5wY_consuming-apps-2.png?imageMogr2/format/webp)

## Demo: Enrutamiento dinámico basado en reclamaciones de tokens JWT

En esta demo, utilizamos la API backend pública llamada [Conference API](https://conferenceapi.azurewebsites.net/?format=json) con información sobre sesiones, ponentes y temas de conferencias. En la realidad, este podría ser tu servicio backend. Supongamos que queremos filtrar y recuperar solo las sesiones pertenecientes a un ponente específico que ha iniciado sesión en el sistema utilizando sus credenciales, como un token JWT. Por ejemplo, `https://conferenceapi.azurewebsites.net/speaker/1/sessions`

La solicitud muestra solo las sesiones de un ponente con un ID único, y este ID único proviene de la reclamación del token JWT como parte de su carga útil. Observa la siguiente estructura de carga útil del token decodificado, donde se incluye un campo `speakerId`:

![Token JWT con una reclamación personalizada](https://static.api7.ai/uploads/2024/12/25/4UCiYziS_consuming-apps-3.png?imageMogr2/format/webp)

En este escenario, enviamos solicitudes a la misma [Ruta](https://apisix.apache.org/docs/apisix/terminology/route/) en la puerta de enlace de API, y esta calcula la URI dinámica a partir del encabezado de autorización y reenvía la solicitud a la URI (ver el diagrama a continuación para entender el flujo). Para hacerlo, vamos a implementar un enrutamiento dinámico en el nivel de la puerta de enlace de API Apache APISIX basado en la reclamación del token JWT mediante el uso de los siguientes complementos:

1. El complemento [openid-connect](https://apisix.apache.org/docs/apisix/plugins/openid-connect/) que interactúa con el proveedor de identidad (IdP) y puede interceptar solicitudes no autenticadas a tiempo para aplicaciones backend. Como proveedor de identidad, utilizamos [Okta](https://www.okta.com/), que emite un token JWT con nuestra reclamación personalizada y valida el token JWT. O puedes usar otros IdP como [Keycloak](https://www.keycloak.org/), [Ory Hydra](https://www.ory.sh/hydra/), o incluso puedes usar el [complemento jwt](https://apisix.apache.org/docs/apisix/plugins/jwt-auth/) para crear un token JWT, autenticar y autorizar solicitudes.
2. El complemento [serverless-pre-function](https://apisix.apache.org/docs/apisix/plugins/serverless/) para escribir un código de función Lua personalizado que intercepta la solicitud, decodifica, analiza una reclamación del token JWT y almacena el valor de la reclamación en un nuevo encabezado personalizado para tomar decisiones de autorización adicionales.
3. El complemento [proxy-rewrite](https://apisix.apache.org/docs/apisix/plugins/proxy-rewrite/), una vez que tenemos la reclamación en el encabezado, utilizamos este complemento como mecanismo de reenvío de solicitudes para determinar qué ruta URI debe usarse para recuperar sesiones específicas del ponente basándose en la [variable de encabezado Nginx](https://nginx.org/en/docs/http/ngx_http_core_module.html), en nuestro caso es `speakerId` que cambia dinámicamente para crear diferentes rutas `/speaker/$http_speakerId/sessions`. El complemento reenviará la solicitud al recurso relacionado en la Conference API.

Una vez que entendemos lo que vamos a cubrir en la demo, revisemos los requisitos previos para comenzar a configurar el escenario anterior y completar el tutorial.

### Requisitos previos

- [Docker](https://docs.docker.com/get-docker/) se utiliza para instalar etcd y APISIX en contenedores.
- [curl](https://curl.se/) se utiliza para enviar solicitudes a APISIX para configurar rutas, upstreams y configuraciones de complementos. También puedes usar herramientas fáciles como [Postman](https://www.postman.com/) para interactuar con la API.
- Apache APISIX está instalado en tu entorno objetivo. APISIX se puede instalar y comenzar fácilmente con la siguiente [guía de inicio rápido](https://docs.api7.ai/apisix/getting-started/#get-apisix).
- Asegúrate de que tu cuenta de [OKTA](https://www.okta.com/) esté creada, hayas registrado una nueva aplicación (puedes seguir esta guía [Configuración de Okta](https://api7.ai/blog/how-to-use-apisix-auth-with-okta#:~:text=ready%20for%20use.-,Step%201%3A%20Configuring%20Okta,-Log%20in%20to)), [agregar una reclamación personalizada a un token](https://developer.okta.com/docs/guides/customize-tokens-returned-from-okta/main/#add-a-custom-claim-to-a-token) usando el panel de Okta, y [solicitar un token que contenga la reclamación personalizada](https://developer.okta.com/docs/guides/customize-tokens-returned-from-okta/main/#request-a-token-that-contains-the-custom-claim) llamada `speakerId`.

### Configurar el servicio backend (upstream)

Necesitarás configurar el servicio backend para la Conference API al que deseas enrutar las solicitudes. Esto se puede hacer agregando un servidor upstream en Apache APISIX a través de la [API de administración](https://apisix.apache.org/docs/apisix/admin-api/).

```
curl "http://127.0.0.1:9180/apisix/admin/upstreams/1" -X PUT -d '
{
  "name": "Conferences API upstream",
  "desc": "Register Conferences API as the upstream",
  "type": "roundrobin",
  "scheme": "https",
  "nodes": {
    "conferenceapi.azurewebsites.net:443": 1
  }
}'
```

### **Crear una configuración de complemento**

A continuación, configuramos un nuevo objeto de [configuración de complemento](https://apisix.apache.org/docs/apisix/terminology/plugin-config/). Utilizaremos 3 complementos: [openid-connect](https://apisix.apache.org/docs/apisix/plugins/openid-connect/), [serverless-pre-function](https://apisix.apache.org/docs/apisix/plugins/serverless/) y [proxy-rewrite](https://apisix.apache.org/docs/apisix/plugins/proxy-rewrite/) respectivamente, como discutimos los casos de uso de cada complemento anteriormente. Solo necesitas reemplazar los atributos del complemento `openid-connect` (*ClienID, Secret, Discovery y Introspection endpoints*) con tus propios detalles de Okta antes de ejecutar el comando curl.

```
curl "http://127.0.0.1:9180/apisix/admin/plugin_configs/1" -X PUT -d '
{
    "plugins": {
        "openid-connect":{
            "client_id":"{YOUR_OKTA_CLIENT_ID}",
            "client_secret":"{YOUR_OKTA_CLIENT_SECRET}",
            "discovery":"https://{YOUR_OKTA_ISSUER}/oauth2/default/.well-known/openid-configuration",
            "scope":"openid",
            "bearer_only":true,
            "realm":"master",
            "introspection_endpoint_auth_method":"https://{YOUR_OKTA_ISSUER}/oauth2/v1/introspect",
            "redirect_uri":"https://conferenceapi.azurewebsites.net/"
        },
        "proxy-rewrite": {
            "uri": "/speaker/$http_speakerId/sessions",
            "host":"conferenceapi.azurewebsites.net"
        },
        "serverless-pre-function": {
            "phase": "rewrite",
            "functions" : ["return function(conf, ctx)

    -- Importar bibliotecas necesarias
    local core = require(\"apisix.core\")
    local jwt = require(\"resty.jwt\")

    -- Recuperar el token JWT del encabezado Authorization
    local jwt_token = core.request.header(ctx, \"Authorization\")
    if jwt_token ~= nil then
        -- Eliminar el prefijo Bearer del token JWT
        local _, _, jwt_token_only = string.find(jwt_token, \"Bearer%s+(.+)\")
        if jwt_token_only ~= nil then
           -- Decodificar el token JWT
           local jwt_obj = jwt:load_jwt(jwt_token_only)

           if jwt_obj.valid then
             -- Recuperar el valor de la reclamación speakerId del token JWT
             local speakerId_claim_value = jwt_obj.payload.speakerId

             -- Almacenar el valor de la reclamación speakerId en la variable de encabezado
             core.request.set_header(ctx, \"speakerId\", speakerId_claim_value)
           end
         end
     end
   end
    "]}
    }
}'
```

En la configuración anterior, la parte más difícil de entender puede ser el código de función personalizado que escribimos en Lua dentro del complemento `serverless-pre-function`:

```
return function(conf, ctx)
    -- Importar bibliotecas necesarias
    local core = require(\"apisix.core\")
    local jwt = require(\"resty.jwt\")

    -- Recuperar el token JWT del encabezado Authorization
    local jwt_token = core.request.header(ctx, \"Authorization\")
    if jwt_token ~= nil then
        -- Eliminar el prefijo Bearer del token JWT
        local _, _, jwt_token_only = string.find(jwt_token, \"Bearer%s+(.+)\")
        if jwt_token_only ~= nil then
           -- Decodificar el token JWT
           local jwt_obj = jwt:load_jwt(jwt_token_only)

           if jwt_obj.valid then
             -- Recuperar el valor de la reclamación speakerId del token JWT
             local speakerId_claim_value = jwt_obj.payload.speakerId

             -- Almacenar el valor de la reclamación speakerId en la variable de encabezado
             core.request.set_header(ctx, \"speakerId\", speakerId_claim_value)
           end
         end
   end
end
```

Básicamente, este complemento se ejecutará antes que los otros dos complementos y hace lo siguiente:

1. Recupera el token JWT del encabezado Authorization.
2. Elimina el prefijo "Bearer " del token JWT.
3. Decodifica el token JWT utilizando la biblioteca resty.jwt.
4. Recupera el valor de la reclamación "speakerId" del token JWT decodificado.
5. Finalmente, almacena el valor de la reclamación "speakerId" en la variable de encabezado speakerId.

### Configurar una nueva Ruta

Este paso implica configurar una nueva ruta que utilice la configuración del complemento y configurar la ruta para que funcione con el upstream (haciendo referencia a sus ID) que creamos en los pasos anteriores:

```
curl "http://127.0.0.1:9180/apisix/admin/routes/1"  -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "name":"Conferences API speaker sessions route",
    "desc":"Create a new route in APISIX for the Conferences API speaker sessions",
    "methods": ["GET"],
    "uri": "/sessions",
    "upstream_id":"1",
    "plugin_config_id":1
}'
```

En la configuración anterior, definimos las reglas de coincidencia de ruta, como que solo las solicitudes HTTP GET a la URI `/sessions` serán enrutadas al servicio backend correcto.

### Obtener un token de Okta

Después de configurar el upstream, los complementos y la ruta en el lado de APISIX, ahora solicitamos un token de Okta que contenga nuestra reclamación personalizada `speakerId`. Puedes seguir la guía que incluye información sobre [cómo construir una URL para solicitar un token](https://developer.okta.com/docs/guides/customize-tokens-returned-from-okta/main/#request-a-token-that-contains-the-custom-claim) con Okta o simplemente usar la URL resultante a continuación con tu emisor de Okta y ID de cliente:

```
https://{YOUR_OKTA_ISSUER}/oauth2/default/v1/authorize?client_id={YOUR_OKTA_CLIENT_ID}
&response_type=id_token
&scope=openid
&redirect_uri=https%3A%2F%2Fconferenceapi.azurewebsites.net
&state=myState
&nonce=myNonceValue
```

Después de pegar la solicitud en tu navegador, el navegador se redirige a la página de inicio de sesión de Okta y genera un *Token de ID*.

```
https://conferenceapi.azurewebsites.net/#id_token={TOKEN_WILL_BE_HERE}
```

> Ten en cuenta que el proceso para recuperar un token puede ser diferente con otros proveedores de identidad.

Para verificar el token de ID devuelto, puedes copiar el valor y pegarlo en cualquier decodificador JWT (por ejemplo, [https://token.dev](https://token.dev/)).

### Probar el enrutamiento dinámico

Finalmente, ahora podemos verificar que la solicitud se está enrutando a la ruta URI correcta (con sesiones específicas del ponente) basándose en los criterios de coincidencia y la reclamación del token JWT ejecutando otro simple comando curl:

```
curl -i -X "GET [http://127.0.0.1:9080/sessions](http://127.0.0.1:9080/sessions)" -H "Authorization: Bearer {YOUR_OKTA_JWT_TOKEN}"
```

Aquí vamos, el resultado es el esperado. Si configuramos speakerId a 1 en la reclamación del token JWT de Okta, Apisix enrutó la solicitud a la ruta URI relevante y devolvió todas las sesiones de este ponente en la respuesta.

```
{
  "collection": {
    "version": "1.0",
    "links": [],
    "items": [
      {
        "href": "https://conferenceapi.azurewebsites.net/session/114",
        "data": [
          {
            "name": "Title",
            "value": "\r\n\t\t\tIntroduction to Windows Azure Part I\r\n\t\t"
          },
          {
            "name": "Timeslot",
            "value": "04 December 2013 13:40 - 14:40"
          },
          {
            "name": "Speaker",
            "value": "Scott Guthrie"
          }
        ],
        "links": [
          {
            "rel": "http://tavis.net/rels/speaker",
            "href": "https://conferenceapi.azurewebsites.net/speaker/1"
          },
          {
            "rel": "http://tavis.net/rels/topics",
            "href": "https://conferenceapi.azurewebsites.net/session/114/topics"
          }
        ]
      },
      {
        "href": "https://conferenceapi.azurewebsites.net/session/121",
        "data": [
          {
            "name": "Title",
            "value": "\r\n\t\t\tIntroduction to Windows Azure Part II\r\n\t\t"
          },
          {
            "name": "Timeslot",
            "value": "04 December 2013 15:00 - 16:00"
          },
          {
            "name": "Speaker",
            "value": "Scott Guthrie"
          }
        ],
      }
    ]
   }
}
```

## Conclusiones

- Con una puerta de enlace de API, puedes enrutar el tráfico a diferentes servicios backend basados en varios criterios.
- El enrutamiento dinámico se puede lograr dependiendo de los atributos del usuario especificados en el encabezado, consulta o cuerpo de la solicitud.
- Puedes crear reglas de enrutamiento complejas que tengan en cuenta las reclamaciones presentes en el token JWT y asegurar que solo las solicitudes autorizadas puedan acceder a tu API.

Tags:

[API Gateway Concept](https://api7.ai/tags/api-gateway-concept)

[API Routing](https://api7.ai/tags/api-routing)

[API Management](https://api7.ai/tags/api-management)

Share article link

Share

Related Posts

[![Haz que la gestión del ciclo de vida de los productos API sea fácil](https://static.api7.ai/uploads/2024/12/24/3NxzkQIQ_api-product-lifecycle-management.png)](https://api7.ai/blog/api-lifecycle-management)

## [Haz que la gestión del ciclo de vida de los productos API sea fácil](https://api7.ai/blog/api-lifecycle-management)

[![Una decisión de API Gateway en el mundo real: Dentro del proceso de evaluación técnica](https://static.api7.ai/uploads/2025/06/03/E7OqOddo_api-gateway-decision.webp)](https://api7.ai/blog/api-gateway-decision-inside-technical-evaluation)

## [Una decisión de API Gateway en el mundo real: Dentro del proceso de evaluación técnica](https://api7.ai/blog/api-gateway-decision-inside-technical-evaluation)

Table of Contents

- [Enrutamiento dinámico basado en reclamaciones JWT con Apache APISIX y Okta](#enrutamiento-din%C3%A1mico-basado-en-reclamaciones-jwt-con-apache-apisix-y-okta)

- [Objetivos de aprendizaje](#objetivos-de-aprendizaje)

- [Puerta de enlace de API: Enrutamiento dinámico de tráfico](#puerta-de-enlace-de-api-enrutamiento-din%C3%A1mico-de-tr%C3%A1fico)

- [Puerta de enlace de API: Enrutamiento dinámico basado en la identidad del usuario](#puerta-de-enlace-de-api-enrutamiento-din%C3%A1mico-basado-en-la-identidad-del-usuario)

- [Demo: Enrutamiento dinámico basado en reclamaciones de tokens JWT](#demo-enrutamiento-din%C3%A1mico-basado-en-reclamaciones-de-tokens-jwt)

  - [Requisitos previos](#requisitos-previos)
  - [Configurar el servicio backend (upstream)](#configurar-el-servicio-backend-upstream)
  - [**Crear una configuración de complemento**](#crear-una-configuraci%C3%B3n-de-complemento)
  - [Configurar una nueva Ruta](#configurar-una-nueva-ruta)
  - [Obtener un token de Okta](#obtener-un-token-de-okta)
  - [Probar el enrutamiento dinámico](#probar-el-enrutamiento-din%C3%A1mico)

- [Conclusiones](#conclusiones)

## Related Posts

[![API Gateway vs. Gestión de API](https://static.api7.ai/uploads/2024/12/25/zQTHfZGV_api-gateway-vs-api-management.jpg)](https://api7.ai/es/blog/api-gateway-and-api-management-comparison)

Technology

September 1, 2023

#### [API Gateway vs. Gestión de API](https://api7.ai/es/blog/api-gateway-and-api-management-comparison)

Descubre qué son el API gateway y la gestión de API, y explora sus relaciones y diferencias.

[API Gateway Concept](https://api7.ai/tags/api-gateway-concept)

[API Management](https://api7.ai/tags/api-management)

[APISIX Basics](https://api7.ai/tags/apisix-basics)

[![API Gateway para Plugins de ChatGPT](https://static.api7.ai/uploads/2024/12/25/BmKvMoHf_api-gateway-for-chatgpt.png)](https://api7.ai/es/blog/api-gateway-for-chatgpt-plugins)

Technology

April 19, 2023

#### [API Gateway para Plugins de ChatGPT](https://api7.ai/es/blog/api-gateway-for-chatgpt-plugins)

Esta publicación explora cómo API Gateway puede ser beneficioso para los desarrolladores de plugins de ChatGPT al exponer, asegurar, gestionar y monitorear sus endpoints de API.

[API Gateway Concept](https://api7.ai/tags/api-gateway-concept)

[API Management](https://api7.ai/tags/api-management)

[Plugin](https://api7.ai/tags/plugin)

[![Las 10 principales tendencias de API Management para 2023](https://static.api7.ai/uploads/2023/04/12/PtHsoEJS_top-10-trends.png)](https://api7.ai/es/blog/10-api-management-trends-2023)

Technology

April 14, 2023

#### [Las 10 principales tendencias de API Management para 2023](https://api7.ai/es/blog/10-api-management-trends-2023)

10 tendencias principales en la gestión de API: seguridad de API, estandarización, soluciones de gestión de API basadas en la nube, plataformas de API de bajo código, marketplaces de API, protocolos de API emergentes, IA y APIs, experiencia del desarrollador, análisis de API y arquitectura serverless.

[API Management](https://api7.ai/tags/api-management)

[APISIX Basics](https://api7.ai/tags/apisix-basics)

[API Gateway Concept](https://api7.ai/tags/api-gateway-concept)