Cómo se comparan las claves API con la autorización JWT: una descripción detallada

A medida que crea sus propias API, querrá examinar sus casos de uso para determinar qué método de seguridad implementar para cada API.

Para algunos casos de uso, las claves API son suficientes; en otros, querrá la protección y flexibilidad adicionales que vienen con la autorización de JSON Web Tokens (JWT). Entonces, en la comparación de claves API versus autorizaciones JWT , el ganador es... depende.

Todas las llamadas API requieren alguna medida de seguridad y control de acceso.

Las claves de API con una ACL sensata pueden proporcionar suficiente seguridad sin agregar demasiados gastos generales. Pero con el aumento del uso de microservicios para casi todas las tareas pequeñas y grandes, su ecosistema API puede necesitar un método más unificado, granular y seguro como la autorización JWT.

Cuando las claves API están bien

Las empresas en línea que usan una API de búsqueda basada en la nube normalmente pueden exponer claves de API de solo lectura sin grandes riesgos, siempre que el índice de datos subyacente no contenga secretos.

De hecho, las aplicaciones del lado del cliente deben conectarse directamente al motor de búsqueda en la nube por razones de rendimiento, exponiendo así su clave API, para evitar el viaje más largo al servidor back-end antes de ir a la nube. Por otro lado, las actualizaciones de índices requieren un acceso restringido a las claves API, que nunca deben estar expuestas.

Pero en ambos casos de uso (búsqueda e indexación), las claves API generalmente están bien; no hay una necesidad urgente de los gastos generales de la autorización JWT.

Cuándo es el momento de considerar la autorización JWT

Sin embargo, las API exigen cada vez más flexibilidad y protección.

La autorización JWT no solo agrega un nivel adicional de seguridad (más sobre esto a continuación), sino que también proporciona un método más manejable y más fácil para orquestar la multitud y la red de API que se usan a diario. Como se describe en las siguientes secciones:

JWT centraliza la autenticación y la autorización mediante la generación de un único token compartido que contiene información del usuario y del nivel de la aplicación (encriptada o cifrada) para ayudar a cualquier API en el mismo ecosistema a determinar qué puede hacer el titular del token.

Las claves API, a primera vista, parecen tan simples: solo necesita enviar la clave API adecuada y estará listo para comenzar. Pero eso es un poco engañoso.

Cuando su ecosistema depende de muchos microservicios integrados, la gestión de numerosas claves de API se vuelve complicada, poco fiable y casi imposible de gestionar.

Crecen en número, cambian, caducan, se eliminan, sus ACL cambian, todo eso y más, sin notificar a las aplicaciones y usuarios que dependen de estas mismas claves API.

Con JWT, sienta las bases para una arquitectura de inicio de sesión único. Discutimos esto a continuación en la sección Cambiar a JWT.

Uso de claves API vs. Autorización JWT

Uso de claves API

Las claves API son directas, simples y totalmente transparentes. No representan ninguna información subyacente, no cifran un mensaje secreto. Son simplemente una identificación única ilegible.

Aquí hay un ejemplo de una clave API disponible públicamente en javascript del lado del cliente. El código incluye una ID de aplicación ( app-id-BBRSSHR ) que usa la clave API ( temp-search-key-ere452sdaz56qsjh565d ) para permitirle realizar búsquedas.

La ID de la aplicación se refiere a una de sus aplicaciones orientadas al usuario (como un sitio web en línea o un servicio de transmisión). La clave API es temporal y de corta duración (caduca después de un período de tiempo) para brindar cierta protección contra el uso o abuso no deseado.

 import { hitTemplate } from "./helpers"; const search = instantsearch({ appId: "app-id-BBRSSHR", apiKey: "temp-search-key-ere452sdaz56qsjh565d", indexName: "demo_ecommerce" });

Otro ejemplo: la indexación, que requiere una clave API más segura. Tiene el mismo formato ( appId + apiKey ), pero es privado porque está oculto al público, ya sea en código compilado o en una base de datos segura en su back-end.

La ID de la aplicación ( YourApplicationID ) se refiere al sistema administrativo. La clave API ( YourAdminAPIKey ) puede ser una clave de administrador permanente que cambia solo una vez al año para un mantenimiento más simple.

 use Algolia\AlgoliaSearch\SearchClient; $client = SearchClient::create( 'YourApplicationID', 'YourAdminAPIKey' ); $index = $client->initIndex('demo_ecommerce'); $index->saveObject( [ 'firstname' => 'Jimmie', 'lastname' => 'Barninger', 'city' => 'New York', 'objectID' => 'myID' ] );

Usando el token JWT

Un token JWT es un gran conjunto de caracteres ilegibles que contienen información oculta y codificada, enmascarada por una firma o un algoritmo de cifrado. Se compone de tres partes: un encabezado, cuerpo y firma. Están separados por un punto: Header.Body.Signature .

 EZPZAAdsqfqfzeezarEUARLEA.sqfdqsTIYfddhtreujhgGSFJ.fkdlsqEgfdsgkerGAFSLEvdslmgIegeVDEzefsqd

El encabezado JWT es EZPZAAdsqfqfzeezarEUARLEA , que contiene la siguiente información:

 { "alg": "HS256", "typ": "JWT" } { "sub": "1234567890", "name": "John Doe", "iat": 1516239022 }

Hay diferentes algoritmos disponibles, por ejemplo, RS256 y HS256 . Aquí usamos HS256 , que requiere el uso de una clave privada al generar la firma. RS256 utiliza una combinación de clave pública y privada.

El cuerpo de JWT (llamado payload ) es sqfdqsTIYfddhtreujhgGSFJ , que contiene la identidad del usuario para ayudar a establecer los derechos del usuario del token. También da otra información, como una fecha de caducidad (cuanto más corta, más segura):

 { "sub": "1234567890", "name": "John Doe", "iat": 1516239022 }

La firma es fkdlsqEgfdsgkerGAFSLEvdslmgIegeVDEzefsqd , que se genera al combinar el encabezado, el cuerpo y una clave privada compartida, utilizando el método hash HS256, como se indica en el encabezado.

 HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

Y así es como obtienes el siguiente token: Header.Body.Signature :

 EZPZAAdsqfqfzeezarEUARLEA.sqfdqsTIYfddhtreujhgGSFJ.fkdlsqEgfdsgkerGAFSLEvdslmgIegeVDEzefsqd

Una palabra sobre autenticación y autorización

Tanto la clave API como JWT se utilizan para la autenticación y autorización, pero lo hacen de manera diferente.

• La autenticación permite que el usuario o la aplicación utilice uno o más métodos de la API.

  
  

• La autorización define cómo pueden usar esos métodos. Algunas aplicaciones o usuarios solo pueden leer los datos; otros pueden actualizar; otros son administradores (roles y permisos). Lo mismo ocurre con las claves API, administradas por su ACLS: pueden ser de solo lectura, acceso de escritura o administración.

Las claves de API autentican y autorizan utilizando la misma clave de API. La autorización JWT requiere un proceso de autenticación inicial antes de generar el token de autorización.

Una vez que se genera el token, se usa en todo el ecosistema para determinar qué puede y qué no puede hacer el titular del token.

Además, las claves API autentican la aplicación *,* no el usuario ; mientras que JWT autentica tanto al usuario como a la aplicación. Por supuesto, podría usar claves de API para la autorización a nivel de usuario, pero no está bien diseñado para eso: un ecosistema necesitaría generar y administrar claves de API para cada usuario o ID de sesión, lo que es una carga innecesaria para un sistema.

Una palabra sobre una mejor protección y seguridad

En términos de seguridad, tanto las claves API como JWT están abiertas a ataques. La mejor medida de seguridad es implementar una arquitectura segura para todas las comunicaciones de extremo a extremo.

Dicho esto, las claves API son históricamente menos seguras porque dependen de estar ocultas.

Puede ocultar claves con SSL/TLS/HTTPS, o restringiendo su uso a procesos de back-end. Sin embargo, no puede controlar todo el uso de la API; Es probable que las claves API se filtren; HTTPS no siempre es posible; y así.

Con JWT, debido a que el token tiene hash/cifrado, viene con una metodología más segura que es menos probable que esté expuesta.

¿Qué información hay en un token JWT?

La diferencia más notable entre una clave API y un token JWT es que los tokens JWT son autónomos: contienen información que una API necesita para proteger la transacción y determinar la granularidad de los derechos del titular del token.

Por el contrario, las claves API utilizan su singularidad para obtener acceso inicial; pero luego la API necesita encontrar la ACL asociada de una clave en una tabla central para determinar exactamente a qué da acceso la clave.

Por lo general, la clave API proporciona solo seguridad a nivel de aplicación, lo que brinda a todos los usuarios el mismo acceso; mientras que el token JWT proporciona acceso a nivel de usuario.

Un token JWT puede contener información como su fecha de vencimiento y un identificador de usuario para determinar los derechos del usuario en todo el ecosistema.

Echemos un vistazo a parte de la información que puede incluir en un token JWT:

 iss (issuer): identifies the principal that issued the JWT. sub (subject): identifies the principal that is the subject of the JWT. Must be unique aud (audience): identifies the recipients that the JWT is intended for (array of strings/uri) exp (expiration time): identifies the expiration time (UTC Unix) after which you must no longer accept this token. It should be after the issued-at time. nbf(not before): identifies the UTC Unix time before which the JWT must not be accepted iat (issued at): identifies the UTC Unix time at which the JWT was issued jti (JWT ID): provides a unique identifier for the JWT.

Ejemplo:

 { "iss": "stackoverflow", "sub": "joe", "aud": ["all"], "iat": 1300819370, "exp": 1300819380, "jti": "3F2504E0-4F89-11D3-9A0C-0305E82C3301", "context": { "user": { "key": "joe", "displayName": "Joe Smith" }, "roles":["admin","finaluser"] } }

La autorización JWT ofrece flexibilidad, confiabilidad y más seguridad

Así que aquí está el escenario. Tienes muchas aplicaciones:

• Aplicaciones que nos permiten rastrear el uso de la API de todos nuestros usuarios.
• Apps que dan acceso a facturación y datos de clientes.
• Aplicaciones que permiten a los usuarios de API cambiar la configuración en diferentes sistemas.
• Aplicaciones que recuperan datos de productos o contenido empresarial.
• Y así.

Hacerlo con claves API

El problema surge cuando hay más API ejecutando el programa. ¿Dónde almacena las más de 100 claves API necesarias para todo este acceso? Administrar demasiadas claves API requiere que una tabla de claves API esté disponible para todas las aplicaciones que se ejecutan dentro del ecosistema.

Por lo tanto, todas las aplicaciones del ecosistema deberían conocer la base de datos. Cada aplicación necesitaría conectarse y leer desde esa tabla. Y algunas aplicaciones podrían generar nuevas claves o modificar claves existentes.

Todo lo cual está bien, pero se vuelve difícil de mantener. Una forma de gestionar esto es crear una API que valide una clave contra esta base de datos. Pero para eso, necesitará un segundo sistema de autenticación para conectarse a esta API.

No solo es engorroso recuperar las claves API, sino que mantener su duración y nivel de autorización se vuelve tedioso. Y no todas las aplicaciones funcionan a nivel de aplicación, necesitan derechos a nivel de usuario.

Además, las API se pueden usar de maneras que difieren de un sistema a otro. Peor aún, diferentes aplicaciones comparten claves API y, por lo tanto, dependen de las diferentes aplicaciones para mantener los niveles de acceso correctos de las claves API compartidas.

Cambiando a JWT

Cualquier API que requiera autenticación puede cambiar fácilmente a la autorización de JWT. Con la autorización JWT, obtiene la autenticación basada en el usuario. Una vez que el usuario se autentica, obtiene un token seguro que puede usar en todos los sistemas.

La gestión del usuario (y por tanto del token) está centralizada. Usted configura los derechos de acceso y otorga a cada usuario derechos diferentes para cada sistema. El extremo de autorización de JWT autentica al usuario y crea el token.

Con esa arquitectura, el siguiente paso es crear un inicio de sesión único en el ecosistema completo y confiar solo en el token para los derechos.

Al final, el enfoque más simple, sólido y manejable es crear este punto final único dedicado a realizar tanto la autenticación como la autorización, de modo que todos los demás servidores en todo el ecosistema puedan confiar en ese punto central para autorizar las interacciones API entre el cliente y el servidor. .

En resumen, a veces JWT es absolutamente necesario y a veces es excesivo

Como desarrollador de aplicaciones, mi principal preocupación al crear API es que se utilicen correctamente y proporcionen los datos y la funcionalidad correctos.

Por lo tanto, confío en gran medida en los consejos de DevOps para sugerir la mejor y más manejable seguridad. Pero no se trata sólo de seguridad.

En un ecosistema grande, necesitamos una forma simple y robusta de acceder a los microservicios a través de múltiples sistemas y servidores, lo que se logra mejor al centralizar los procesos de autenticación y autorización.

JWT es Overkill en las siguientes dos situaciones:

• Un ecosistema simple con solo unas pocas API.
• Proveedores de API de terceros.

Las API de terceros deben ser fáciles de usar y rápidas de implementar, con poco trabajo inicial durante la integración.

Además, debe compartir la clave utilizada para firmar el token. Así que es mejor cuando controlas ambos extremos, lo que es poco probable en escenarios de terceros. También necesita confiar en la implementación. por ejemplo, una API podría optar por ignorar la fecha de vencimiento o el NBF ("no antes").

JWT no se exagera cuando...

Querrá usar JWT cuando varios servicios necesiten comunicarse entre sí a través de una red extensa.

Centralizar y asegurar esos intercambios es crucial. Es especialmente importante cuando cada red o aplicación requiere diferentes niveles de acceso según el usuario, no solo la aplicación.

También es importante tener control sobre el tráfico y poder priorizar las llamadas de la red. Finalmente, desea la experiencia simple de conectar y usar al agregar nuevos microservicios o mejorar los existentes.

Publicado por primera vez aquí

Autor: Julien Bourdeau, ingeniero de software sénior en Algolia, GitHub , Gorjeo , LinkedIn