API y autenticación en Jamstack

La primera “A” en Jamstack significa “API” y es un factor clave que hace que trabajar con sitios estáticos sea tan poderoso. Las API brindan a los desarrolladores la libertad de descargar la complejidad y brindan vías para incluir funcionalidad dinámica en un sitio que de otro modo sería estático. A menudo, acceder a una API requiere validar la autenticidad de una solicitud. Esto frecuentemente se manifiesta en forma de autenticación (auth) y se puede realizar en el lado del cliente o en el lado del servidor, según el servicio utilizado y la tarea que se esté realizando.

Dado el amplio espectro de protocolos disponibles, las API se diferencian en sus implementaciones de autenticación individuales. Estos protocolos de autenticación y complejidades de implementación añaden un desafío adicional al integrar API en un sitio Jamstack. Afortunadamente, existe un método para esta locura. Cada protocolo se puede asignar a un caso de uso específico y la implementación de la autenticación es una cuestión de comprender esto.

Para ilustrar esto mejor, profundizamos en los distintos protocolos y los escenarios para los que son más adecuados.

Convocar a los protocolos

OAuth 2.0 es el estándar general que sigue la autenticación en la actualidad. OAuth es un marco de autorización bastante flexible que constituye una serie de concesiones que definen la relación entre un cliente y un punto final API. En un flujo de OAuth, una aplicación cliente solicita un token de acceso desde un punto final de autorización y lo utiliza para firmar una solicitud a un punto final API.

Hay cuatro tipos de concesiones principales: código de autorización, flujo implícito, credencial de propietario de recurso y credenciales de cliente. Examinaremos cada uno individualmente.

Concesión del código de autorización

De todos los tipos de concesión de OAuth, la concesión del código de autorización es probablemente la más común. Este flujo de concesión, que se utiliza principalmente para obtener un token de acceso para autorizar solicitudes de API después de que un usuario otorga permiso explícitamente, sigue un proceso de dos pasos.

• Primero, se dirige al usuario a una pantalla de consentimiento, también conocida como servidor de autorización, donde otorga al servicio acceso restringido a su cuenta y datos personales.
• Una vez que se ha concedido el permiso, el siguiente paso es recuperar un token de acceso del servidor de autenticación que luego se puede utilizar para autenticar la solicitud en el punto final de la API.

En comparación con otros tipos de concesión, la concesión del código de autorización tiene una capa adicional de seguridad con el paso adicional de solicitar al usuario una autorización explícita. Este intercambio de código de varios pasos significa que el token de acceso nunca queda expuesto y siempre se envía a través de un canal secundario seguro entre una aplicación y un servidor de autenticación. De esta manera, los atacantes no pueden robar fácilmente un token de acceso interceptando una solicitud. Los servicios propiedad de Google, como Gmail y Google Calendar, utilizan este flujo de código de autorización para acceder al contenido personal desde la cuenta de un usuario. Si desea profundizar más en este flujo de trabajo, consulte esta publicación de blog para obtener más información.

Concesión implícita

La concesión implícita es similar a la concesión del código de autorización con una diferencia notable: en lugar de que un usuario otorgue permiso para recuperar un código de autorización que luego se intercambia por un token de acceso, se devuelve un token de acceso inmediatamente a través de la parte del fragmento (hash). de la URL de redireccionamiento (también conocido como canal frontal).

Con el paso reducido de un código de autorización, el flujo de concesión implícita conlleva el riesgo de exponer tokens. El token, al estar incrustado directamente en la URL (y registrado en el historial del navegador), es fácilmente accesible si alguna vez se intercepta la redirección.

A pesar de sus vulnerabilidades, la concesión implícita puede resultar útil para clientes basados ​​en agentes de usuario, como aplicaciones de una sola página. Dado que se puede acceder fácilmente tanto al código de la aplicación como al almacenamiento en las aplicaciones renderizadas del lado del cliente, no existe una forma segura de mantener seguros los secretos del cliente. El flujo implícito es la solución lógica a esto, ya que proporciona a las aplicaciones una forma rápida y sencilla de autenticar a un usuario en el lado del cliente. También es un medio válido para solucionar problemas de CORS, especialmente cuando se utiliza un servidor de autenticación de terceros que no admite solicitudes de origen cruzado. Debido a los riesgos inherentes de los tokens expuestos con este enfoque, es importante tener en cuenta que los tokens de acceso en Implicit Flow tienden a ser de corta duración y los tokens de actualización nunca se emiten. Como resultado, este flujo puede requerir iniciar sesión para cada solicitud a un recurso privilegiado.

Credencial de propietario de recursos

En el caso de la concesión de credenciales de propietario de recursos, los propietarios de recursos envían sus credenciales de nombre de usuario y contraseña al servidor de autenticación, que luego devuelve un token de acceso con un token de actualización opcional. Dado que las credenciales del propietario del recurso son visibles en el intercambio de autenticación entre la aplicación cliente y el servidor de autorización, debe existir una relación de confianza entre el propietario del recurso y la aplicación cliente. Aunque evidentemente es menos segura que otros tipos de concesión, la concesión de Credencial de propietario de recursos ofrece una excelente experiencia de usuario para los clientes propios. Este flujo de concesión es más adecuado en los casos en que la aplicación tiene muchos privilegios o cuando se trabaja dentro del sistema operativo de un dispositivo. Este flujo de autorización se utiliza a menudo cuando otros flujos no son viables.

Credencial de cliente

El tipo de concesión de credenciales de cliente se utiliza principalmente cuando los clientes necesitan obtener un token de acceso fuera del contexto de un usuario. Esto es adecuado para la autenticación de máquina a máquina cuando no se puede garantizar el permiso explícito de un usuario para cada acceso a un recurso protegido. Las CLI y los servicios que se ejecutan en el back-end son casos en los que este tipo de concesión resulta útil. En lugar de depender del inicio de sesión del usuario, se transmiten un ID de cliente y un secreto para obtener un token que luego se puede utilizar para autenticar una solicitud de API.

Normalmente, en la concesión de Credencial de Cliente, se establece una cuenta de servicio a través de la cual la aplicación opera y realiza llamadas API. De esta manera, los usuarios no participan directamente y las aplicaciones aún pueden continuar autenticando solicitudes. Este flujo de trabajo es bastante común en situaciones en las que las aplicaciones desean acceder a sus propios datos, por ejemplo, Analytics, en lugar de datos de usuarios específicos.

Conclusión

Al depender de servicios de terceros para funciones complejas, una solución de autenticación bien diseñada es crucial para mantener la seguridad de los sitios Jamstack. Las API, al ser la forma predominante de intercambiar datos en Jamstack, son una gran parte de eso. Analizamos cuatro métodos diferentes para autenticar solicitudes de API, cada uno con sus beneficios e impactos en la experiencia del usuario.

Mencionamos al principio que estas cuatro son las principales formas de autenticación que se utilizan para solicitar datos de una API. También hay muchos otros tipos, que están muy bien descritos en oauth.net. El sitio web en su conjunto es un excelente análisis profundo no solo de los tipos de autenticación disponibles, sino también del marco OAuth en su conjunto.

¿Prefieres un método u otro? ¿Tiene algún ejemplo en uso que pueda señalar? ¡Comparte en los comentarios!