Los tokens de API estáticos se han utilizado durante mucho tiempo para llamar a APIs externas y acceder a los recursos de terceros, como proveedores de software. A medida que los estándares de las API han evolucionado, OAuth 2.0 surgió como la opción que ofrece una seguridad más robusta, mayor flexibilidad y una mejor experiencia para los desarrolladores. Exploremos las ventajas de dejar atrás los tokens estáticos en favor de OAuth 2.0.
Panorama de tokens estáticos de la API
En un sistema de software seguro, todas las llamadas que permiten leer o modificar recursos deben estar autorizadas. Cuando llamas a una API protegida, ésta necesita alguna forma de validar la autorización. Los tokens de API estáticos son una forma de proporcionar información de autorización a la API utilizando un valor memorizado sin contexto de usuario. Como resultado, proporcionaron un enfoque sencillo (pero limitado) para que los desarrolladores otorguen acceso a la API de otra aplicación: generar un token, almacenarlo una vez y continuar con la tarea.
Si observamos un ejemplo de llamada HTTP a Okta, una solicitud con un token de API estático podría verse algo así:
El cliente de la API (también conocido como cliente) agrega el valor del token a la llamada. Dependiendo del sistema del proveedor al que se llame, la API puede añadir el valor del token estático a un encabezado HTTP, como Authorization (usando un esquema de autorización estándar o uno propietario, como el esquema SSWS de Okta), o en un parámetro de consulta.
Pasar de tokens de API estáticos a OAuth 2.0 para mejorar la seguridad.
Como ocurre con muchas tecnologías, esta facilidad de uso conlleva un aumento correspondiente en la exposición al riesgo. A diferencia de los tokens de OAuth 2.0 de corta duración, los tokens estáticos suelen tener una vida útil prolongada. Los tokens de la API establecidos en los parámetros de consulta son particularmente peligrosos. Los navegadores guardan las URL en el historial, y los sistemas de registro pueden registrar la URL completa, exponiendo el token más fácilmente que al usar encabezados HTTP.
Para comprender mejor las preocupaciones de seguridad asociadas con los tokens de API estáticos, profundicemos en algunas de sus características en detalle y comparémoslas con OAuth 2.0 como alternativa.
Riesgos de acceso al usar tokens de API estáticos
Los tokens estáticos pueden caer en malas manos, lo que conduce a un acceso no autorizado. Por ejemplo, los tokens estáticos pueden terminar inadvertidamente en los sistemas de control de versiones, exponiendo inadvertidamente el token a quienes consultan el repositorio y al historial de versiones. Dado que los tokens estáticos tienen una larga vigencia, el riesgo de exponerlos es particularmente preocupante, pues las consecuencias de un token robado son significativas: un token estático robado permanece activo hasta que se desactiva manualmente o expira, lo que permite el acceso no autorizado.
Problemas con la rotación de tokens
Rotar tokens estáticos puede ser una tarea desafiante. Debido a que los valores de los tokens persisten en el entorno del solicitante o en los sistemas de software, programar la rotación para liberar rápidamente un token, generar uno nuevo y guardarlo, mientras se mantienen en funcionamiento los entornos de producción, puede plantear desafíos.
Limitar el alcance es difícil.
Asignar ámbitos limitados a tokens estáticos no es sencillo. Los tokens estáticos suelen otorgar acceso completo a la API invocada: un nivel de acceso todo o nada. Definir un acceso con alcance limitado —p. ej., solo lectura en lugar de escritura— y otras medidas de control de acceso de granularidad fina puede no estar disponible o resultar difícil de gestionar mediante tokens de API estáticos.
Permisos heredados en tokens generados por el usuario.
Los tokens de acceso generados por el usuario suelen heredar los permisos de la cuenta de usuario que los generó. Si un administrador genera el token, este tiene acceso total a todos los recursos y acciones que el administrador puede realizar. Para mitigar esta preocupación, a veces las organizaciones crean cuentas de servicio con alcances limitados para generar el token. Sin embargo, al hacerlo se genera una sobrecarga en la gestión de usuarios y potencialmente ocupa un asiento de la licencia.
Desafíos de auditoría
Es complicado rastrear la utilización estática de tokens. Una necesidad esencial de la auditoría es rastrear la interacción de un usuario con una API. Sin embargo, los tokens estáticos de la API normalmente no tienen contexto de usuario, y todas las llamadas a la API utilizan el mismo token, por lo que puede resultar imposible identificar la acción de un usuario específico.
Los tokens estáticos son frágiles.
Los tokens vinculados a las cuentas de usuario se invalidan cuando el usuario abandona la organización. Algunas organizaciones utilizan cuentas de servicio para contrarrestar esta medida, lo que abre riesgos de acceso y conlleva una sobrecarga de gestión.
Hay una forma mejor y más segura de acceder a las API que mitiga los riesgos asociados con los tokens de API estáticos: usar los flujos estándar de OAuth 2.0 de la industria.
Adopta OAuth 2.0 para mejorar la seguridad.
OAuth 2.0 se adapta a prácticamente cualquier escenario en lugar de los tokens estáticos SSWS de Okta. Pero a diferencia de los tokens estáticos, las especificaciones de OAuth incluyen definiciones y prácticas seguras para necesidades tales como la rotación de tokens, las decisiones básicas de autorización y más para casos de uso cotidianos como
- Interacción automatizada de servicio a servicio para gestionar llamadas a la API entre bastidores sin contexto de usuario.
- Automatización basada en tareas mediante las operaciones de línea de comandos
- Limitar los datos y las acciones de la aplicación a los niveles de acceso del usuario para mantener la seguridad de la autorización.
OAuth 2.0 admite cada uno de los casos de uso cotidianos mencionados anteriormente mediante propiedades de configuración enviadas en una solicitud a un servidor de autorización centralizado. La interacción general es un proceso de varios pasos como este:
1. El llamante solicita un token de acceso al servidor de autorización, pasando las propiedades de configuración requeridas para el caso de uso. El servidor de autorización devuelve un token de acceso de corta duración. La duración del token depende del caso de uso. Algunos casos de uso son intrínsecamente más seguros, por lo que su vida útil puede variar. La petición HTTP que aparece a continuación muestra un ejemplo de solicitud para obtener un token, pero no incluye las propiedades de configuración requeridas. Verá las propiedades de configuración necesarias en los próximos ejemplos.
2. El llamante utiliza el valor del token en la solicitud de la API como valor del encabezado Authorization de la petición HTTP empleando el esquema Bearer. La solicitud HTTP podría tener un aspecto similar a este:
Hay mucho que saber sobre OAuth 2.0, así que consulta los recursos al final de esta publicación para profundizar en el tema. No profundizaremos en todos los detalles en esta publicación, sino que adaptaremos la información a los casos de uso mencionados y ofreceremos un resumen de alto nivel para cada uno.
Veamos cada caso de uso para ver cómo OAuth 2.0 lo respalda.
Interacción de servicio a servicio
Es posible que tenga procesos de back-end que llamen a otras API para obtener datos o realizar acciones. OAuth 2.0 es compatible con solicitudes de servicio a servicio o de máquina a máquina sin un contexto de usuario asociado a la llamada, mediante un flujo de autorización denominado credenciales de cliente.
Ventajas de usar credenciales de cliente en lugar de tokens de API
El uso de OAuth 2.0 para la interacción entre servicios ofrece enormes ventajas sobre las claves de API estáticas, especialmente en lo que respecta a los niveles de acceso denominados ámbitos. En OAuth 2.0, identificas los ámbitos que obtendrá tu token de acceso como parte de las propiedades de configuración en la llamada para recuperar tu token. Deberías asegurarte de que la API que estás llamando admita acceso basado en ámbitos y de que hayas concedido los ámbitos que necesitas. Por ejemplo, las API de Okta han definido múltiples ámbitos para las API de recursos, como okta.users.read y okta.users.write. Puede conceder acceso a uno o a ambos de esos ámbitos.
El flujo de credenciales de cliente no es lo mismo que utilizar cuentas de servicio para la autorización de la API. OAuth 2.0 permite la interacción máquina a máquina en un formato estándar sin consumir un asiento de usuario para emular un usuario de automatización. Ten en cuenta que cuando definas ámbitos, lo harás en la configuración de la aplicación de servicio y en el servidor de autorización, no a nivel de usuario. La ventaja es que controla el acceso a los recursos de toda la aplicación de servicio, en lugar de hacerlo a través de un usuario dentro de la aplicación. Ya no tiene que preocuparse por gestionar cuentas de servicio y puede estar seguro de que la aplicación no podrá acceder a más alcances de los que ha permitido.
Obtener un token de acceso mediante credenciales de cliente.
Para obtener un token de acceso para este flujo, enviarás propiedades que especifiquen el tipo de flujo de autorización, las credenciales y los ámbitos del token de acceso. El término de OAuth 2.0 para definir el flujo de autorización es grant_type; para el flujo de credenciales de cliente, deberás pasar el valor client_credentials.
Las credenciales pueden ser un JSON Web Token (JWT) criptográficamente seguro firmado con la clave privada del cliente o un valor secreto generado por su servidor de autorización. Un JWT con clave privada es más seguro, ya que no corres el riesgo de exponer el valor secreto, lo que de forma accidental genera preocupaciones de acceso similares a las de un token de API estático. Generarás un par de claves pública y privada y registrarás la clave pública en un JSON Web Key Set (JWKS) o la cargarás en el servidor de autorización, de modo que dicho servidor disponga de la clave pública para validar la firma del JWT. Obtenga más información sobre este proceso en la documentación de Implementar OAuth para Okta con una aplicación de servicio.
Un ejemplo de llamada HTTP para obtener el token de acceso podría verse así:
Una vez que obtengas el token de acceso, lo agregarás a las llamadas a la API como un encabezado: Authorization: Bearer access_token.
Obtenga más información sobre las llamadas API de servicio a servicio con .NET y la creación de JWT privados en Python en Asegure su API web de .NET 6 y Configure el flujo de JWT de clave privada en tres comandos de Python.
Automatización basada en tareas
Las terminales de línea de comandos, como Bash y PowerShell, son procesos sin navegador para ejecutar comandos individuales o scripts dentro de la ventana de tu terminal. A diferencia de la interacción anterior entre servicios, este flujo implica contexto de usuario. Quieres ejecutar las operaciones de línea de comandos con tu contexto de autorización, lo que significa que solo tendrás acceso a los recursos de la API que te corresponden. OAuth 2.0 admite este caso de uso con un flujo llamado Device Flow.
La obtención de tokens de acceso es un proceso de varios pasos con este flujo. Antes de solicitar directamente el token de acceso, como en el caso de uso de servicio a servicio, primero obtienes códigos de verificación únicos enviando el ID de cliente a un endpoint especial de tu servidor de autorización:
La respuesta de la llamada a /device/authorize devuelve dos códigos únicos: un código de dispositivo y un código de usuario, además de un URI de verificación. Confirme la solicitud de autorización navegando a la URI de verificación en su navegador e ingresando el código de usuario.
Para obtener el token de acceso, agregas la propiedad grant_type para especificar el flujo de OAuth 2.0 según el caso de uso y el código de dispositivo como propiedades de configuración en la llamada:
Utilice el token de acceso de la respuesta en el encabezado Authorization: Bearer access_token.
Puedes leer más sobre el flujo de código de dispositivo para líneas de comando en Autenticarse desde la línea de comandos con Java.
Acceso de usuario a través de una aplicación web.
El último caso de uso garantiza que la autorización del usuario se aplique al acceso a la API al usar una aplicación web. OAuth 2.0 permite limitar las acciones de una aplicación a un subconjunto de las que el usuario puede realizar y de los datos que ve. En este flujo, cuentas con el contexto del usuario para aplicar la autorización de recursos; además, disponer de ese contexto facilita la auditoría y el rastreo de las llamadas de usuarios individuales. El flujo OAuth 2.0 para este caso de uso combina un flujo estándar, el flujo de código de autorización y una extensión que proporciona una capa adicional de seguridad denominada Proof Key for Code Exchange (PKCE).
El flujo de código de autorización con PKCE requiere múltiples pasos para obtener un token de acceso e implica la interacción del usuario a través del consentimiento y la verificación, lo que permite la autenticación multifactor. En este flujo, redirigirás al usuario a un servidor de autorización para obtener el código de autorización antes de solicitar un token de acceso.
La URL de redireccionamiento incluye propiedades específicas de la solicitud necesarias para completar el inicio de sesión, como la especificación del tipo de solicitud mediante la propiedad response_type, el ID de cliente y otras propiedades.
Cuando el usuario completa con éxito el inicio de sesión, el proveedor de identidad redirige de nuevo a la aplicación con un código de autorización en la respuesta de autorización. Para obtener el token de acceso, proporcionas el tipo de concesión de este flujo, el código de autorización y otros metadatos específicos de la solicitud.
Con el token de acceso en mano, la aplicación web añade el token de acceso a las llamadas salientes de la API en el encabezado Authorization: Bearer access_token.
Lee más sobre el flujo de código de autorización en Cómo funcionan la autenticación y la autorización en aplicaciones SPA y Uso de PKCE con OAuth 2.0 y Spring Boot para una mejor seguridad.
Retire gradualmente los tokens de API estáticos y use OAuth 2.0.
Las migraciones de software requieren tiempo y planificación, y contar con un buen plan de acción ayuda. Considere la transición a OAuth 2.0 en pequeños pasos incrementales.
El primer paso para migrar de tokens de API estáticos es asegurarse de que las API que utilices admitan OAuth 2.0. Consulta con tu proveedor si estás llamando a APIs de terceros. Si su API es interna, querrá añadir soporte para OAuth. Una vez que verifique que las API que está llamando admiten OAuth, necesitará el ID de cliente de la aplicación OAuth y habilitar medidas de acceso, como los ámbitos.
Al iniciar sesión en la consola de administración de Okta como administrador, puedes determinar si utilizas tokens de API estáticos en un entorno de Okta. En la barra lateral, navegue a Seguridad > API y seleccione la pestaña Tokens para ver todos los tokens creados para la organización de Okta. Esta vista ofrece información sobre el uso de tokens de API, los casos de uso y el nivel de acceso (p. ej., un token creado por un superadministrador cuenta con acceso completo). Deberías evaluar cada uno y convertirlos para que usen OAuth.
Centrémonos en el caso de uso de una llamada automatizada de servicio a servicio. Incorporar OAuth 2.0 en tus APIs de una sola vez es abrumador, así que veamos cómo lograrlo de forma incremental. Antes de hacer cualquier cambio en el código, puedes probar los pasos localmente a mano y usar tu cliente HTTP favorito para solicitar un token y llamar a una API con OAuth 2.0. Este caso utiliza el flujo de credenciales de cliente con un JWT de clave privada. Los pasos son:
- Generar el par de claves pública/privada.
- Utilice el par de claves pública/privada para generar el JWT de clave privada.
- Solicitar el token de acceso
- Añade el token de acceso a tu solicitud de API.
- Incorpora OAuth en el sistema de tu aplicación.
1. Genere el par de claves pública y privada.
Puede generar un par de claves pública/privada siguiendo estas instrucciones. La consola de administración de Okta puede generar un par de claves pública/privada con fines de prueba si no desea generarlo usted mismo.
2. Generar el JWT de clave privada
Utilice el par de claves pública/privada para crear el JWT de clave privada siguiendo las instrucciones de la documentación de Implementar OAuth para Okta con una aplicación de servicio. En este paso es más importante entender cómo funciona todo esto en lugar de automatizar los pasos, para que puedas almacenar el par de claves pública/privada localmente, usar herramientas instaladas en tu máquina y, por ahora, pegar el JWKS que contiene tu clave pública en un sitio web de generación de JWT de prueba.
3. Solicite el token de acceso
Solicita el token de acceso utilizando tu JWT de clave privada sin añadir ningún ámbito mediante hacer la solicitud HTTP en tu cliente HTTP favorito. Deberías obtener un error al usar el token de acceso sin el alcance adecuado, pero es bueno probar tanto los escenarios de error como los de éxito. El token de acceso expira en algún momento, y verás la expiración en la respuesta del token de acceso. El token de acceso forma parte de la respuesta. Usarás la cadena completa como token de acceso.
4. Agrega el token de acceso a tu solicitud de API.
Utiliza tu cliente HTTP para llamar a tu API usando el token de acceso. Agregarás un encabezado Authorization y usarás el esquema Bearer, de modo que tu llamada a la API incluya el siguiente encabezado con el formato que se muestra a continuación:
Cuando hagas la llamada a la API, deberías recibir un error HTTP 403. ¡Hurra! ¿Éxito? Bueno, sí, una prueba de caso de error exitosa. Ahora sabe qué error esperar si se produce un error al configurar los ámbitos. Añadamos los ámbitos a la solicitud del token de acceso e intentémoslo de nuevo.
Esta vez, solicita tu token de acceso utilizando un JWT de clave privada y añade los ámbitos para la llamada a la API. Usa el token de acceso en la llamada a la API. ¡El momento de la verdad! Deberías ver una respuesta exitosa. Sabrás que hay un error de configuración si vuelves a recibir un error 403. Si esto sucede, vuelve a comprobar los ámbitos de la solicitud y asegúrate de que la aplicación OAuth 2.0 tenga habilitados los ámbitos que estás solicitando.
5. Añada autorización OAuth 2.0 en su sistema
Ahora que ha recorrido manualmente con éxito el proceso de autorización OAuth 2.0 para una llamada de servidor a servicio, puede incorporar aspectos de estos pasos en su sistema. En un entorno de desarrollo o de pruebas, intente usar el token de acceso. Deberías modificar tus APIs para usar la cabecera Authorization con el esquema Bearer y sustituir tu token de API estático existente por el token de acceso generado manualmente, de modo que tus llamadas a la API funcionen sin necesidad de automatizar los pasos para solicitar el token de acceso.
Cuando tengas la seguridad de que tu sistema de API maneja correctamente el token de acceso, es hora de añadir los pasos para solicitarlo desde tu código. Tu pila tecnológica puede incluir SDKs que faciliten al menos parte (o la totalidad) de los pasos de la solicitud. SDKs de administración de Okta pueden encargarse del proceso de autenticación OAuth 2.0 en su nombre. Los usuarios de Java Spring pueden consultar la documentación de Spring Security, y los usuarios de .NET Core pueden consultar Microsoft.AspNetCore.Authentication como ejemplos. Recuerda probar tu trabajo a medida que avanzas, tanto en el flujo principal como en los casos de error y en situaciones como el manejo correcto de la expiración del token de acceso.
Antes de desplegar cambios en tu entorno de producción, asegúrate de utilizar herramientas de calidad de producción para generar internamente el JWKS y de gestionar tu clave privada de forma segura.
Mejores prácticas durante las migraciones de autorización de API
No siempre es factible abandonar de inmediato los tokens estáticos, especialmente en organizaciones grandes o si tienes muchas APIs que actualizar. Si aún utilizas tokens SSWS con Okta, querrás mitigar los riesgos hasta que puedas migrar a OAuth 2.0. Las mejores prácticas incluyen:
- Implemente nuevas llamadas a la API o código utilizando OAuth 2.0.
- Siga el principio de menor privilegio. Por ejemplo:
- No utilice cuentas personales para establecer cuentas de servicio.
- Utilice un rol de administrador personalizado para las cuentas de servicio, otorgando solo los permisos esenciales.
- Utilice grupos y políticas globales de sesión para impedir los inicios de sesión interactivos en las cuentas de servicio.
Asegura las llamadas a la API con OAuth 2.0
El paso de tokens estáticos a OAuth 2.0 no solo significa adoptar una nueva tecnología, sino dar un giro hacia un ecosistema más seguro, flexible y amigable para los desarrolladores. Aunque los tokens estáticos tuvieron su momento y su lugar, está claro que el futuro radica en soluciones OAuth 2.0 dinámicas, centradas en el usuario y seguras.
Recuerda que, a medida que la tecnología avanza, mantenerse al día y adaptarse a mejores prácticas no solo es beneficioso, sino esencial. Migra a OAuth 2.0 y da un paso hacia una experiencia de desarrollo más segura, ágil y eficiente.
Próximos pasos con OAuth 2.0
Si encuentras esta publicación interesante, puede que disfrutes de estas otras.
- Seleccionando la mejor autorización para las integraciones de API
- Añade autenticación a cualquier aplicación con OAuth2 Proxy
- OAuth para desarrolladores de Java
Consulta las guías para desarrolladores de seguridad de API de Okta para comenzar tu migración a OAuth 2.0:
Configurar demostración de la prueba de posesión
- Esta guía explica cómo crear tokens de acceso restringidos al remitente, un mecanismo a nivel de aplicación para evitar la reproducción de tokens en diferentes puntos finales.
- Esta guía explica cómo interactuar con las API de Okta utilizando tokens de acceso OAuth 2.0 con ámbitos. Configurar OAuth para Okta: aplicación de servicio
- Esta guía describe cómo interactuar con las API de Okta utilizando tokens de acceso OAuth 2.0 con ámbitos para una aplicación de servicio.
- Agregue autorización usando Okta para proteger sus APIs. Al terminar, tendrás una aplicación segura de API REST que valida las solicitudes entrantes.
Integrar el riesgo de terceros
- Esta guía explica cómo configurar una organización de Okta para recibir eventos de riesgo de un proveedor externo. Conexión de API segura entre organizaciones con OAuth 2.0
- Esta guía describe cómo configurar de forma segura organizaciones hub and spoke de Okta para sincronizar usuarios y grupos mediante OAuth 2.0 en una solución multiarrendatario. Conecte el acceso a la API de la organización de Okta a datos con alcance utilizando el flujo de credenciales de cliente de OAuth 2.0 para la aplicación integración Org2Org.
Configura la autenticación escalonada con valores ACR.
- Esta guía explica cómo incluir el parámetro acr_values en sus solicitudes de autorización para aumentar la confianza del usuario final.
Para más contenido emocionante, sigue a @oktadev en X, encuéntranos en LinkedIn y suscríbete a nuestro canal de YouTube.
