Header Ads Widget

Ticker

6/recent/ticker-posts

Explicación de 3 métodos comunes de autenticación de API


 Las API manejan enormes cantidades de datos de un tipo muy variable; en consecuencia, una de las principales preocupaciones de cualquier proveedor de datos es cómo proteger específicamente estos datos. La idea de que los datos deben ser secretos, que no deben modificarse y que deben estar disponibles para su manipulación es clave para cualquier conversación sobre la gestión y el manejo de datos de API.

Hoy vamos a hablar de  Autenticación . Aunque es un tema que se discute a menudo, vale la pena repetirlo para aclarar exactamente qué es, qué no es y cómo funciona.

Destacaremos tres métodos principales para agregar seguridad a una API : autenticación básica HTTP , claves de API y OAuth . Identificaremos los pros y los contras de cada enfoque de autenticación y, finalmente, recomendaremos la mejor manera para que la mayoría de los proveedores aprovechen este poder.

Autenticación vs Autorización

Antes de profundizar demasiado en este tema, primero debemos definir qué es realmente la autenticación y, lo que es más importante, qué no es. Por mucho que la autenticación impulse la Internet moderna, el tema a menudo se combina con un término estrechamente relacionado: autorización .

Las dos funciones a menudo están unidas en soluciones únicas; de hecho, una de las soluciones que analizaremos en un momento es un sistema híbrido de autenticación y autorización. Como tal, y debido a sus similitudes en la aplicación funcional, es bastante fácil confundir estos dos elementos.

La forma más fácil de dividir la autorización y la autenticación es preguntar: ¿qué prueban realmente? En términos simples, la autenticación es cuando una entidad prueba una identidad . En otras palabras, la autenticación demuestra que eres quien dices ser. Esto es similar a tener una tarjeta de identificación , un artículo entregado por una autoridad confiable que el solicitante, como un oficial de policía, puede usar como evidencia que sugiere que usted es de hecho quien dice ser.

La autorización es un concepto completamente diferente, aunque ciertamente está estrechamente relacionado. En términos simples, la autorización es cuando una entidad acredita un derecho de acceso . En otras palabras, la Autorización demuestra que tiene derecho a realizar una solicitud. Cuando intentas ir detrás del escenario en un concierto o evento, no necesariamente tienes que demostrar que eres quien dices ser; proporcionas la entrada , que es una prueba de facto de que tienes derecho a estar donde estás ''. Estás tratando de entrar.

Considere por un momento una licencia de conducir. En muchos países, una licencia de conducir demuestra que usted es quien dice ser a través de una imagen u otro elemento certificado, y luego va más allá para demostrar que tiene derecho a conducir la clase de vehículo que está conduciendo. En tal caso, tenemos autenticación y autorización, y en muchas soluciones de API, tenemos sistemas que proporcionan un fragmento de código que autentica al usuario y prueba su autorización. En tal caso, tenemos soluciones híbridas .

Por lo tanto, en el futuro, es importante recordar que de lo que realmente estamos hablando aquí es de un sistema que prueba su identidad , nada más y nada menos.

Relacionado: Cómo controlar la identidad del usuario dentro de microservicios

 

Métodos comunes de autenticación de API

Si bien existen tantos métodos de autenticación patentados como sistemas que los utilizan, son en gran parte variaciones de algunos enfoques principales. Estos enfoques casi siempre se desarrollaron para resolver las limitaciones en las primeras comunicaciones y los sistemas de Internet y, como tales, generalmente utilizan enfoques arquitectónicos amplios existentes con implementaciones novedosas para permitir que se produzca la autenticación.

Autenticación básica HTTP

La autenticación básica HTTP rara vez se recomienda debido a sus vulnerabilidades de seguridad inherentes.

Una solución es la autenticación básica HTTP . En este enfoque, un agente de usuario HTTP simplemente proporciona un nombre de usuario y una contraseña para probar su autenticación. Este enfoque no requiere cookies, ID de sesión, páginas de inicio de sesión y otras soluciones especializadas, y debido a que utiliza el encabezado HTTP en sí, no hay necesidad de apretones de manos u otros sistemas de respuesta complejos.

El problema es que, a menos que el proceso se aplique estrictamente durante todo el ciclo de datos a SSL por motivos de seguridad, la autenticación se transmite en abierto en líneas inseguras. Esto se presta a ataques man in the middle , donde un usuario puede simplemente capturar los datos de inicio de sesión y autenticarse a través de un encabezado HTTP copy-cat adjunto a un paquete malicioso.

Además, incluso si se aplica SSL, esto da como resultado una  ralentización del tiempo de respuesta. E incluso ignorando que, en su forma básica, HTTP no está encriptado de ninguna manera. Está encapsulado en base64 y, debido a esto, a menudo se proclama erróneamente como cifrado.

La autenticación básica HTTP tiene su lugar. En una red interna , especialmente en situaciones de IoT donde la velocidad no es esencial, tener un sistema de autenticación básica HTTP es aceptable como equilibrio entre el costo de implementación y la función real. Sin embargo, como solución de autenticación general, la autenticación básica HTTP rara vez debe usarse en su forma básica .

Leer más: Mantener la seguridad en un entorno de entrega continua

Claves API

Las claves de API son un estándar de la industria, pero no deben considerarse una medida de seguridad integral.

Las claves de API se crearon como una solución a los problemas de autenticación iniciales de la autenticación básica HTTP y otros sistemas similares. En este enfoque, se asigna un valor generado único a cada usuario por primera vez, lo que significa que el usuario es conocido. Cuando el usuario intenta volver a ingresar al sistema, su clave única (a veces generada a partir de su combinación de hardware y datos de IP, y otras veces generada aleatoriamente por el servidor que los conoce) se usa para demostrar que es el mismo usuario que antes. .

Por un lado, esto es muy rápido . La capacidad de probar la identidad una vez y seguir adelante es muy ágil, y es por eso que se ha utilizado durante muchos años como un enfoque predeterminado para muchos proveedores de API. Además, configurar el sistema en sí es bastante fácil y controlar estas claves una vez generadas es aún más fácil. Esto también permite que los sistemas purguen las claves, eliminando así la autenticación después del hecho y denegando la entrada a cualquier sistema que intente utilizar una clave eliminada.

El problema, sin embargo, es que las claves de API se utilizan a menudo para lo que no son: una clave de API no es un método de autorización , es un método de autenticación. Debido a que cualquiera que hace una solicitud de un servicio transmite su clave, en teoría, esta clave se puede recoger con la misma facilidad que cualquier transmisión de red, y si algún punto de toda la red es inseguro, toda la red está expuesta. Esto hace que las claves de API sean algo difícil de recomendar, a menudo mal utilizadas y fundamentalmente inseguras , sin embargo, tienen su lugar cuando están debidamente aseguradas y rodeadas por sistemas de autorización.

Leer más: Por qué claves API ≠ Seguridad API

OAuth

OAuth combina la autenticación y la autorización para permitir un control de validez y alcance más sofisticado.

OAuth es una bestia un poco extraña. OAuth no es técnicamente un método de autenticación, sino un método tanto de autenticación como de autorización . Cuando OAuth se usa únicamente para autenticación, es lo que se conoce como "pseudoautenticación".

En este enfoque, el usuario inicia sesión en un sistema. Luego, ese sistema solicitará autenticación, generalmente en forma de token . Luego, el usuario enviará esta solicitud a un servidor de autenticación, que rechazará o permitirá esta autenticación. Desde aquí, el token se proporciona al usuario y luego al solicitante. Luego, el solicitante puede verificar dicho token en cualquier momento independientemente del usuario para su validación, y puede usarse a lo largo del tiempo con un alcance y una antigüedad de validez estrictamente limitados.

Este es fundamentalmente un sistema mucho más seguro y poderoso que los otros enfoques, en gran parte porque permite el establecimiento suave del alcance (es decir, en qué sistemas la clave permite al usuario autenticarse) y la validez (lo que significa que la clave no tiene para ser revocado intencionalmente por el sistema, automáticamente quedará obsoleto a tiempo).

Como con cualquier otra cosa, este enfoque tiene algunos pros y contras importantes. Por un lado, es claramente superior en cuanto al nivel de seguridad que puede ofrecer y, por esta razón, OAuth se está convirtiendo rápidamente en la opción de facto para cualquiera que elija evitar las claves API . Por otro lado, usar OAuth solo para la autenticación es ignorar todo lo demás que OAuth tiene para ofrecer: sería como conducir un Ferrari como un conductor de todos los días y nunca exceder los límites de velocidad residenciales.

Con estas advertencias en mente, OAuth es fácil de configurar y es increíblemente rápido.

Leer más: Profundización en OAuth y OpenID Connect

La mejor opción

Entonces, de estos tres enfoques, dos más generales y uno más específico, ¿cuál es el mejor? Es una pregunta difícil de responder y la respuesta en sí misma depende en gran medida de sus situaciones. Si bien el claro ganador de los tres enfoques es OAuth , hay algunos casos de uso en los que las claves de API o la autenticación básica HTTP pueden ser apropiadas.

Dicho esto, estos casos de uso son pocos y distantes entre sí y, en consecuencia, es muy difícil argumentar en contra de OAuth al final del día. OAuth ofrece una gran cantidad de beneficios , desde la facilidad de uso hasta un módulo de sistema federado , y lo más importante ofrece escalabilidad de seguridad: los proveedores pueden estar buscando autenticación en este momento, pero tienen un sistema que admite de forma nativa una autorización sólida además de en los métodos de autenticación es muy valioso y reduce el costo de implementación a largo plazo.

¿Qué piensas? ¿Cuál es la mejor forma de autenticar a un usuario? Más concretamente, ¿cuáles crees que son los casos de uso más claros para usar algo como una clave de API sobre OAuth? Háganos saber en los comentarios a continuación.

 

Publicar un comentario

0 Comentarios