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 se manifiesta con frecuencia en forma de autenticación (auth) y se puede realizar tanto en el lado del cliente como en el del servidor, según el servicio utilizado y la tarea que se esté realizando.
Dado el amplio espectro de protocolos disponibles, las API difieren en sus implementaciones de autenticación individuales. Estos protocolos de autenticación y las complejidades de la implementación añaden un desafío adicional al integrar las API en un sitio Jamstack. Afortunadamente, hay 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, profundicemos en los diversos protocolos y los escenarios para los que son más adecuados.
Convoca 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 de API. En un flujo de OAuth, una aplicación cliente solicita un token de acceso desde un punto final de autorización y lo usa para firmar una solicitud a un punto final API.
Hay cuatro tipos principales de concesión: código de autorización, flujo implícito, credencial del propietario del recurso y credenciales del cliente. Veremos cada uno individualmente.
Concesión de 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. Utilizado principalmente para obtener un token de acceso para autorizar solicitudes de API después de que un usuario otorga permiso explícitamente, este flujo de concesión 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 otorgado el permiso, el siguiente paso es recuperar un token de acceso del servidor de autenticación que luego se puede usar 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 pedirle a un usuario una autorización explícita. Este intercambio de código de varios pasos significa que el token de acceso nunca está expuesto y siempre se envía a través de un canal secundario seguro entre una aplicación y el 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.
Subvenció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 conceda 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 el 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, en virtud de estar incrustado directamente en la URL (y registrado en el historial del navegador), es fácilmente accesible si se intercepta la redirección.
A pesar de sus vulnerabilidades, la concesión implícita puede ser útil para clientes basados en agentes de usuario como las aplicaciones de página única. Dado que se puede acceder fácilmente al código de la aplicación y 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 al proporcionar a las aplicaciones una forma rápida y fácil de autenticar a un usuario en el lado del cliente. También es un medio válido para navegar por los problemas de CORS, especialmente cuando se usa 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 el flujo implícito tienden a ser de corta duración y los tokens de actualización nunca se emiten. Como resultado, este flujo puede requerir el inicio de sesión para cada solicitud a un recurso privilegiado.
Credencial de propietario de recurso
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 seguro que otros tipos de subvenciones, la subvención de la Credencial de propietario de recursos brinda una excelente experiencia de usuario para los clientes de primera mano. 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 usar para autenticar una solicitud de API.
Normalmente, en la concesión de credenciales de cliente, se establece una cuenta de servicio a través de la cual la aplicación opera y realiza llamadas a la API. De esta manera, los usuarios no se involucran 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, análisis, en lugar de a datos específicos del usuario.
Conclusión
Con su dependencia de servicios de terceros para una funcionalidad compleja, una solución de autenticación bien diseñada es crucial para mantener la seguridad de los sitios Jamstack. Las API, que son 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 se describen muy bien en oauth.net. El sitio web en su conjunto es una excelente inmersión profunda no solo en los tipos de autenticación disponibles, sino también en el marco de OAuth en su conjunto.
¿Prefieres un método sobre otro? ¿Tiene un ejemplo en uso que pueda señalar? ¡Comparte en los comentarios!