Tokens de acceso personal, autenticación máquina a máquina y definición de claves API y sus escenarios en el mundo real

Si estás construyendo un producto de software o SaaS, a menudo te encontrarás con un caso de uso amplio o solicitud de característica: Solicitudes API. Especialmente los clientes empresariales más grandes pueden querer acceso programático a los recursos, ya sea a nivel personal u organizacional.

En estos casos, las claves API, los Tokens de Acceso Personal (PATs) y la autenticación Máquina a Máquina (M2M) son a menudo necesarios. En este artículo, exploraremos las diferencias entre estos métodos y cómo pueden ser utilizados en el desarrollo de productos B2B para desarrolladores.

Las similitudes#

Primero, echemos un vistazo a las similitudes entre esos tres.

1. Propósito de seguridad: Los tres métodos se utilizan para asegurar y controlar el acceso a APIs, servicios o recursos. Todos sirven como un medio de autenticación y/o autorización.
2. Enfoque basado en tokens: Cada método generalmente implica el uso de una cadena o token único para la identificación. Estos tokens usualmente se envían con solicitudes API, a menudo en encabezados o como parámetros de consulta.
3. Revocables: Los tokens o claves en los tres métodos pueden ser revocados o invalidados si son comprometidos o ya no son necesarios. Esto permite una respuesta rápida de seguridad sin cambiar el sistema subyacente.
4. Acceso programable: Los tres métodos facilitan el acceso programático a APIs o servicios. Permiten automatización e integración entre diferentes sistemas o aplicaciones.
5. Auditables: El uso de estos métodos de autenticación puede ser registrado y auditado. Esto permite rastrear el acceso a la API, monitorizar actividades sospechosas y entregar informes de cumplimiento.
6. Adaptable al control de acceso: Todos los métodos pueden implementarse con diferentes niveles de control de acceso y permisos. Pueden adaptarse a diferentes modelos de seguridad y requisitos arquitectónicos.
7. Independencia de protocolo: Aunque a menudo se utilizan con APIs REST, estos métodos pueden aplicarse a varios tipos de APIs y protocolos.

Entender estas similitudes ayuda a reconocer las bases comunes de estos métodos de autenticación. Sus diferencias te permiten elegir la solución más adecuada para casos de uso específicos y requisitos de seguridad.

Ahora, hablemos de sus diferencias, enfocándonos en los casos de uso y cuándo usar cada método.

Las diferencias#

Claves API#

Las claves API se utilizan para identificar y autorizar la aplicación o servicio que realiza la llamada. Generalmente tienen una larga duración y son estáticas hasta que se rotan y a menudo tienen un conjunto fijo de permisos. Se utilizan principalmente para comunicaciones servidor a servidor o para acceder a datos públicos, estos tokens generalmente no representan a un usuario específico.

¿Cómo funcionan las claves API?#

Una clave API es emitida por un proveedor de API y dada a un consumidor de API registrado [1], quien la incluye con cada solicitud. El servidor de API verifica la clave API para validar la identidad del consumidor antes de devolver los datos solicitados.

Las claves API no son tan efectivas como otras formas de autenticación de API, como OAuth y JWT, pero aún juegan un papel importante al ayudar a los productores de API a monitorizar el uso mientras mantienen los datos sensibles seguros.

[1]: Un consumidor de API es cualquier aplicación, servicio o usuario que interactúa con una API para acceder a su funcionalidad o datos. Envían solicitudes a la API para realizar operaciones como recuperar, crear, actualizar o eliminar recursos. Los consumidores de API pueden ser aplicaciones web, aplicaciones móviles, otros servidores o incluso desarrolladores individuales que utilizan la API para integrarse con otros servicios o para construir nuevas funcionalidades sobre plataformas existentes.

Postman: ¿Qué es una clave API?

Casos de uso#

Cuando las personas discuten usos de claves API, a menudo mencionan automatización, intercambio de datos, pruebas, desarrollo y control de seguridad. Sin embargo, estos son bastante técnicos. En escenarios del mundo real, el propósito más común al construir productos es la integración.

Ejemplo 1: Integración con Zapier#

Zapier: Agregar autenticación con clave API

Zapier es una herramienta de automatización popular que conecta diferentes aplicaciones web. Al integrar una aplicación con Zapier, se utilizan claves API para autenticar y autorizar el acceso a la API de la aplicación. Por ejemplo, si deseas automatizar tareas entre un sistema CRM y una herramienta de marketing por correo electrónico, generarías una clave API desde el sistema CRM y la proporcionarías a Zapier. Esta clave se utiliza luego para autenticar las solicitudes de Zapier a la API del CRM, permitiendo que los datos fluyan de manera segura entre los dos sistemas.

Ejemplo 2: Integración con Stripe#

Stripe aprovecha las claves API para una integración segura con varias plataformas y aplicaciones. Usa el Panel de Desarrolladores para crear, revelar, eliminar y rotar claves API.

Tokens de Acceso Personal (PATs)#

Un token de acceso personal es otro concepto similar pero representa la identidad y permisos de un usuario específico, se genera dinámicamente tras una autenticación o inicio de sesión exitoso, y típicamente tiene una vida útil limitada pero puede ser renovado. Ofrecen control de acceso detallado a datos y capacidades específicas del usuario y se utilizan comúnmente para herramientas de línea de comandos, scripts o acceso API personal.

¿Cómo funcionan los PATs?#

1. Creación y gestión: Los usuarios generan PATs a través de la configuración de su cuenta en la plataforma respectiva.
   • Por ejemplo, en GitHub, los usuarios pueden crear PATs detallados o clásicos con permisos específicos y fechas de caducidad.
   • En productos de Atlassian como Jira y Confluence, los usuarios pueden crear PATs desde la configuración de su perfil, especificando el nombre del token y la caducidad opcional.
2. Uso: Los PATs se utilizan como tokens portadores en el encabezado de Autorización de las solicitudes API. Esto significa que se incluyen en los encabezados HTTP para autenticar la solicitud.
   • Permiten acceso seguro a los recursos API, permitiendo a los usuarios realizar acciones como crear, leer, actualizar y eliminar recursos según los permisos otorgados al token.
   • Los PATs pueden ser utilizados en varias aplicaciones dentro de una plataforma, proporcionando una forma unificada de gestionar el acceso y los permisos.
3. Revocación y configuración de caducidad:
   • Los PATs ofrecen mayor seguridad al permitir que los usuarios revoquen tokens si son comprometidos, sin tener que cambiar la contraseña de la cuenta.
   • Las plataformas a menudo recomiendan establecer fechas de caducidad para los PATs para reducir el riesgo de que se exploten tokens de larga duración.

Casos de uso#

Hay dos escenarios típicos,

Automatización y scripting

Esto significa cuando un desarrollador usa un PAT para automatizar el despliegue de código desde un repositorio a un entorno de producción, reduciendo la intervención manual y asegurando la consistencia.

Por ejemplo, los usuarios de GitHub pueden crear PATs para autenticar operaciones Git sobre HTTPS e interactuar con la API REST de GitHub. Esto es útil para desarrolladores que necesitan automatizar tareas como clonar repositorios, enviar commits o gestionar issues y pull requests.

Integración con aplicaciones externas

Esto significa habilitar la comunicación segura entre diferentes sistemas y aplicaciones. Esto se parece al escenario donde la integración con clave API, pero el PAT representa al usuario, no al cliente o la aplicación.

Por ejemplo, un gerente de proyecto utiliza un PAT para integrar una herramienta de gestión de proyectos con un sistema externo de seguimiento de issues, permitiendo un intercambio y sincronización de datos sin problemas, como Atlassian (Jira y Confluence).

Los escenarios anteriores son más como herramientas para desarrolladores. ¿Los PATs son útiles solo para este tipo de productos? No. Aquí hay dos ejemplos adicionales: uno es un sistema CMS, y otro es una herramienta de productividad.

Ejemplo 1: Contentful#

Contentful: Tokens de Acceso Personal

Contentful, una plataforma CMS sin cabeza, ofrece PATs como alternativa a los tokens OAuth para acceder a su API de Gestión de Contenidos (CMA).

Características clave incluyen:

• Los usuarios pueden crear múltiples tokens con diferentes alcances y permisos.
• Los tokens están vinculados a la cuenta del usuario, heredando sus permisos.
• Los PATs son particularmente útiles para propósitos de desarrollo y automatización.

Ejemplo 2: Airtable#

Creación de Tokens de Acceso Personal | Soporte de Airtable

Airtable - una plataforma de colaboración en la nube, implementa PATs para acceso API.

Su sistema permite:

• Creación de múltiples tokens con diferentes alcances y niveles de acceso.
• Los tokens pueden estar limitados a bases o espacios de trabajo específicos.
• Los administradores de la empresa pueden crear tokens con mayor acceso en toda la organización.

Autenticación Máquina a Máquina (M2M)#

M2M está diseñada para la comunicación servicio a servicio sin intervención humana. Proviene de la idea de que nombres de usuario y contraseñas son insuficientes para proteger servicios y no son eficientes para una automatización efectiva.

Las aplicaciones máquina a máquina (M2M) ahora adoptan el Flujo de Credenciales del Cliente, que está definido en el protocolo de autorización OAuth 2.0 RFC 6749. También puede soportar protocolos estándar similares. Sí, la autenticación M2M es más estricta respecto a estándares abiertos en comparación con los PATs y las claves API.

Autentica la aplicación o servicio en sí mismo, no a un usuario, y a menudo implementa JWT (JSON Web Tokens) para autenticación sin estado. Esto proporciona una forma segura para que los servicios interactúen entre sí en sistemas distribuidos.

¿Cómo funciona la autenticación máquina a máquina?#

Sigue un proceso similar:

1. Credenciales del Cliente: Cada máquina (o servicio) tiene un ID de cliente único y un secreto.
2. Solicitud de Token: El servicio envía estas credenciales al servidor de autorización.
3. Token de Acceso: Tras la validación, el servidor de autorización emite un token de acceso, a menudo un JWT (Token Web JSON).
4. Solicitudes API: El servicio utiliza este token para autenticar y autorizar solicitudes API a otro servicio.
5. Validación: El servicio receptor valida el token antes de otorgar acceso a sus recursos.

Casos de uso#

Aquí hay un ejemplo conciso de uso de autenticación máquina a máquina (M2M) para comunicación backend a backend:

Escenario: El Servicio A necesita acceder a datos desde la API del Servicio B.

1. Configuración:

   • El Servicio A está registrado como cliente con un servidor de autorización.
   • Al Servicio A se le da un ID de cliente y un secreto de cliente.

2. Autenticación:

   • El Servicio A solicita un token de acceso del servidor de autorización:

3. Emisión de Token:

   • El servidor de autorización verifica las credenciales y emite un token de acceso JWT.

4. Solicitud API:

   • El Servicio A utiliza el token para solicitar datos al Servicio B:

5. Validación:

   • El Servicio B valida el token con el servidor de autorización.

6. Respuesta:

   • Si es válido, el Servicio B devuelve los datos solicitados al Servicio A.

Este proceso permite una comunicación segura y automatizada entre el Servicio A y el Servicio B sin intervención del usuario, utilizando el flujo de credenciales del cliente de OAuth 2.0.

Comunicación dispositivo a dispositivo

La comunicación dispositivo a dispositivo, particularmente en el contexto de IoT (Internet de las Cosas), depende en gran medida de la autenticación máquina a máquina (M2M) para asegurar un intercambio de datos seguro y eficiente.

Por ejemplo, como dispositivos inteligentes para el hogar, un termostato inteligente se comunica con un hub central de automatización del hogar para ajustar la configuración de temperatura según las preferencias del usuario. El termostato utiliza autenticación M2M para enviar datos de manera segura al hub y recibir comandos, asegurando que solo los dispositivos autorizados puedan interactuar con el sistema de calefacción del hogar.

Resumen clave#

Ok, has llegado al final de este artículo. ¿Puedo obtener un resumen rápido? ¡Claro! Aquí tienes los puntos clave:

1. Alcance: Las claves API son amplias, los PATs (Tokens de Acceso Personal) son específicos del usuario, y los tokens M2M (Máquina a Máquina) son específicos para servicio.
2. Duración: Las claves API tienen una larga duración, los PATs tienen una vida útil más corta, y los tokens M2M pueden variar.
3. Representación: Las claves API son cadenas opacas, los PATs pueden ser opacos o estructurados, y los tokens M2M a menudo usan JWTs.
4. Caso de uso: Las claves API son para acceso API simple, los PATs son para operaciones centradas en el usuario, y los tokens M2M son para comunicación servicio a servicio.