En la economía actual impulsada por TI, las API web son cada vez más utilizadas por todo el mundo. Probablemente haya consumido o creado una API usted mismo. Las API manejan enormes cantidades de datos: una de las principales preocupaciones de la organización de servicios de software está buscando específicamente para proteger estos datos. La idea es que los datos deben ser estables y protegidos y pueden ser accedidos por sólo los usuarios previstos. El tiempo, la velocidad y el rendimiento también son importantes para las API. Aquí en este artículo, vamos a discutir diferentes métodos de autenticación y autorización de API que son ampliamente utilizados por las organizaciones de TI de todo el mundo.
Autenticación frente a autorización
Si alguna vez ha trabajado en una API, siempre verá solo los encabezados de autorización, no los encabezados de autenticación. ¿Alguna vez te preguntaste por qué? Simplemente use cualquier herramienta de rastreo de red como Fiddler / Wireshark, o use una herramienta de prueba de API y verifique la API de su aplicación. Tanto si ve los encabezados como el cuerpo de una API, la solicitud de API siempre encontrará autorización. Por lo tanto, antes de explicar por qué las API solo tienen autorización no autenticación, primero expliquemos la diferencia entre autenticación y autorización.
Autenticación
La autenticación no es más que validar a un usuario si es la persona adecuada para usar ese servicio. Vamos a explicarlo más adelante con un ejemplo simple. Supongamos que está visitando un restaurante en su ciudad con su familia. Abres la puerta del restaurante y el gerente te da la bienvenida. Pero no quieres sentarte en un comedor público en el restaurante, quieres sentarte en una habitación privada con familia y tienes que tener una reserva para eso. Usted informa al gerente y ellos confirman que tiene una reserva, lo que le permite sentarse en la sección privada del restaurante reservada para familias. Por lo tanto, esto es lo que llamamos como autenticación. El gerente del restaurante le ha permitido sentarse con su familia en un lugar privado con una reserva válida. Podemos decir que la reserva se denomina clave de autenticación.
Autorización
Ahora, se le permite en la habitación privada y se puede utilizar los servicios reservados para los comensales privados, etc. Usted está autorizado a hacer todo esto, pero si usted va a la cocina del restaurante y abrir su refrigerador pueden decir que no están permitidos en esta área. Así que esto se llama autorización. Así que se le permite entrar, pero después de entrar en el restaurante no está autorizado a entrar en algunas áreas y no está autorizado a acceder a alguna otra área. Así que esto es lo que es la autorización.
Ahora, cuando se trata de un sitio web, cualquiera puede ingresar a una página de inicio de sesión de sitio web público. Igual que cualquiera puede entrar en un restaurante. Nadie va a detenerte. Cuando inicia sesión con el nombre de usuario y la contraseña de su sitio web, se autentica y puede ingresar al sitio web. De la misma manera que accedió a una mesa privada reservada en un restaurante utilizando una reserva. Pero después de entrar, y después de la autenticación, puede acceder a algunas secciones, pero es posible que no pueda acceder a algunas otras secciones que son como secciones de administración del sitio web. Así que esta es una diferencia muy básica entre la autenticación y la autorización.
Ahora, volvamos a nuestra pregunta. Siempre vemos autorización en una API, ¿por qué es así? Si observa la API, apunta a un punto final donde esa dirección se dirige a una función o recurso determinado en la aplicación. Podemos decir, por ejemplo, un módulo en el back-end de la aplicación. Cuando realmente está intentando acceder a un recurso determinado solo en la aplicación, es más adecuado llamarlo como autorización para usted, aunque habrá autenticación para verificar su identidad. El primer paso es siempre la autenticación.
Tipos de autenticaciones HTTP
Puesto que hemos cubierto la diferencia entre la autenticación y la autorización, ahora discutiremos diferentes tipos de autenticaciones de API. Los métodos de autenticación de API varían en función de la técnica que utilizan. Las autenticaciones son muy importantes porque están directamente relacionadas con la seguridad del sistema. Es por eso que la prioridad siempre va a la autenticación HTTP en cualquier sistema.
Destacaremos cinco mecanismos principales para agregar seguridad a una API: Basic, API Key, Bearer, OAuth1.0/OAuth 2.0 y OpenID connect. Identificaremos lo que hacen, cómo funcionan y las ventajas y desventajas de cada enfoque. Por último, demostraremos las pruebas de carga de una API que requiere autenticación mediante LoadView.
Autenticación básica
La autenticación básica HTTP rara vez es utilizada por la industria de TI hoy en día, porque es muy fácil ser pirateado, pero este es el método más fácil de implementar. Las API enviarán un nombre de usuario y una contraseña a lo largo del cuerpo. Las credenciales se codificarán con el método de cifrado como Base64; esto convertirá el nombre de usuario y la contraseña en formato cifrado para la transmisión.
Puesto que utiliza el encabezado para la transmisión de credenciales, no hay otras medidas de seguridad complejas en su lugar. Ni siquiera los ID de sesión o las cookies.
Ejemplo de autenticación básica en un encabezado de solicitud:
Autorización: Básico Cg4sOnOlY8KyPQ
Autenticación implícita
La autenticación de acceso de resumen es más compleja y avanzada que la autenticación básica. Digest utiliza una combinación de la contraseña del usuario y otros atributos para crear un hash MD5. Esto se enviará al servidor para la autenticación. Es más avanzado que otro mecanismo de seguridad, ya que envía las credenciales como hash. Fue creado originalmente como parte de RFC 2069, las mejoras de seguridad se agregaron más tarde en RFC 2617.
En la autenticación implícita, es el servidor el que detecta al cliente que intenta acceder al recurso. El servidor generará un valor único, denominado “nonce”. Más adelante, este valor único será utilizado por el solicitante de recursos para generar un hash MD5, que será verificado por el servidor.
Claves de API
Las claves de API se utilizan ampliamente en comparación con la autenticación básica hoy en día. Se puede ver en aplicaciones móviles, así como aplicaciones web. Las claves API se crearon de alguna manera para resolver las vulnerabilidades de seguridad asociadas con el mecanismo básico de API. En una clave de API, se genera un valor único en el lado del servidor una vez que se autentica con su nombre de usuario y contraseña. Se asignará al usuario. Por lo general, este valor único se genera en función de la dirección IP y los diferentes atributos de usuario. La mayoría de las veces, los desarrolladores enviarán la clave de API en el encabezado de autorización.
Ejemplo de una clave de API
api_key: d670d200234faf5480aa11529b01d732
Definitivamente hay muchas ventajas de usar una clave de API, en comparación con todos los demás mecanismos de seguridad. En primer lugar, las claves de API son sencillas con una mejor seguridad. La desventaja es que cualquier persona puede recoger esta clave de seguridad utilizando cualquiera de las herramientas de sniffing de red. Esto puede ser llevado a problemas de seguridad de toda la aplicación.
Portador
Portador significa “una persona o cosa que lleva o sostiene algo”. Como su nombre indica, es un esquema de autenticación HTTP que implica tokens de seguridad. El portador del token de seguridad tendrá acceso a ciertas funciones o direcciones URL. El token de portador normalmente lo generará el servidor en respuesta a una solicitud de inicio de sesión de cliente. Una vez que el usuario tiene el token de portador del servidor, debe enviar el token junto con el encabezado de autorización al realizar más solicitudes.
Ejemplo de autenticación de portador
Autorización:
Portador eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy93cy8yMDA1LzA1L2lkZW50aXR5L2NsYWltcy9uYW1lIjoiNmUyZTU0NjUtNTRjZi00ZTU2LTk2NDEtNDU4Njg0YjVjNWQyIiwiZXhwIjoxNTkzOTY3ODQ0LCJpc3MiOiJodHRwOlxcd3D3LnNvdWxib29rLm1lIiwiYXVkIjoiaHR0cDpcXHd3dy5zb3VsYm9vay5tZSJ9.adcAYn8U5tn68EVGUGPLYBKcGC8Ohgxm7p45tDnpXVc
Fue creado originalmente como parte de OAuth2.0 en RFC-6750. Definitivamente hay muchas ventajas de usar tokens portadores en comparación con todos los demás mecanismos de seguridad. Los tokens de portador son mejores en términos de seguridad.
OAuth 1.0 y OAuth 2.0
OAuth es un protocolo más seguro para la autorización. OAuth proporciona simplicidad a la vez que proporciona flujo de autorización para las aplicaciones. OAuth es generalmente utilizado por los usuarios para iniciar sesión en sitios web de terceros utilizando sus cuentas de Google, Microsoft, Facebook, Slack, por ejemplo, sin exponer sus credenciales.
OAuth 1.0 es sospechoso de vulnerabilidades de seguridad y ya no es compatible. OAuth 2.0 tiene características de seguridad avanzadas y es el mejor para la identificación y autenticación de cuentas de usuario personales. OAuth 2.0 permite a los usuarios compartir sus atributos específicos con una aplicación, manteniendo sus credenciales y otra información en secreto. OAuth 1.0 era mucho más complicado y menos seguro que OAuth 2.0. El mayor cambio en OAuth2.0 es que no hay necesidad de firmar cada llamada con un hash con clave.
Básicamente, OAuth consta de dos tokens para realizar la verificación; un token de autenticación y un token de sesión. Los tokens de autenticación funcionan como protocolos de seguridad de claves de API, la aplicación se autentica para acceder a los datos de usuario. Los tokens de sesión se utilizan para mantener la sesión de usuario y recuperar un nuevo token de autenticación si el token de sesión ha caducado. OAuth 2.0 combina la autenticación y la autorización para permitir más seguridad a la aplicación.
En OAuth, el usuario tendrá acceso a la aplicación con credenciales. A continuación, la aplicación solicitará un token de autenticación. El solicitante enviará esta solicitud a un servidor de autenticación, lo que permitirá esta autenticación si las credenciales son correctas. Este token de autenticación se puede verificar en cualquier momento, independientemente del usuario. Esto hará que OAuth sea un mecanismo mucho más seguro que las otras autenticaciones HTTP. Una de las principales desventajas de OAuth es la complejidad a implementar. Debe tener un conocimiento sólido en el flujo de OAuth para integrarlo con la aplicación.
OpenID Connect
OpenID Connect es una extensión del protocolo OAuth 2.0. Comprueba la identidad del cliente en función de la autenticación realizada por un servidor de autorización. Además, puede obtener información de perfil de usuario sobre el cliente. OpenID connect realmente resuelve muchas desventajas de OAuth 2.0 y proporciona una mejor solución para los usuarios finales y desarrolladores.
¿Cuál es el mejor protocolo de autenticación para usar?
La autenticación básica HTTP es la más fácil de implementar en la aplicación, pero tampoco es segura en absoluto. Las credenciales están codificadas, pero se envían como texto sin formato. La autenticación implícita mejora la autenticación básica mediante el envío de datos en formato hash. Pero el hash del algoritmo MD5 no es complejo en absoluto y puede ser hackeado muy fácilmente. Las claves de API y el portador son casi similares y proporcionan una mejor seguridad que arriba.
El protocolo OAuth garantiza que ningún pirata informático pueda obtener información del cliente. Incluso la aplicación no puede obtener las credenciales de perfil de cliente y la información privada. OpenID Connect establece protocolos para que las aplicaciones accedan a los atributos del cliente mediante la API RESTful. OpenID Connect amplía el flujo de tokens de autorización de OAuth 2.0 introduciendo nuevos tokens. Básicamente, OpenID Connect se realiza como una extensión de OAuth 2.0.
Uso de LoadView para probar una API que requiere autenticación
En esta sección, vamos a implementar la autenticación de API HTTP mediante LoadView. LoadView le permite realizar estas tareas de forma muy fácil y eficiente. Load View proporciona dos opciones para las pruebas de carga de autenticación de API:
Autenticación API: Opción Uno
Si tiene acceso a la aplicación podemos obtener la solicitud de API utilizando cualquier herramienta de red. Este es el método más simple. Mostraremos una demostración rápida para configurar cada uno de los mecanismos de autenticación HTTP anteriores utilizando LoadView
Nota: Puede obtener los detalles de la solicitud del servidor de API y los detalles de los datos del cuerpo de su equipo de desarrollo o capturarlo con cualquier herramienta de rastreo de red.
Paso 1: Seleccione un tipo de prueba de carga
Inicie sesión en LoadView y, en Seleccionar un tipo de prueba de carga, seleccione HTTP/S.
Paso 2: Configure su API
La siguiente pantalla le pedirá que configure su API. Aquí le mostraremos cómo puede configurar diferentes mecanismos de autenticación HTTP en LoadView.
Autenticación básica
Claves de API
Ficha de portador
OAuth 2.0
OAuth 2.0 y Open ID Connect son más complejos de configurar. Te mostraré una demo para OAuth 2.0. Hay una manera fácil de hacer la autenticación de OAuth 2.0 que explicaré después de esta sección.
Paso 1: Servidor de autenticación OAuth
Configure los detalles del servidor de autenticación de OAuth.
Paso 2: Credenciales
Escriba las credenciales y haga clic en Login (Inicio de sesión). El servidor de autenticación redirige al usuario a su sitio web con un código como parámetro URL.
Paso 3: Información del servidor
El servidor de API solicita información del usuario al servidor de autenticación.
Paso 4: Token de acceso
Los servidores de API identifican al usuario y responden con un token de acceso. A continuación, el usuario envía el token de acceso al servidor de API en cada solicitud. El servidor DE API valida y da acceso a la aplicación.
Autenticación API: Opción Dos
Si la primera opción no es factible, puede grabarla con la herramienta de grabación EveryStep Web Recorder. Se puede acceder a ella a través de la web y el uso de la grabadora es más fácil y eficaz. Además, no es necesario aprender diferentes mecanismos de autenticación. Aquí vamos a demostrar cómo hacer pruebas de carga mediante LoadView y el uso de EveryStep Web Recorder. La aplicación utiliza OAuth 2.0 para la autenticación.
Paso 1: Grabar un nuevo guión
Inicie sesión en LoadView y, en Seleccionar un tipo de prueba de carga, seleccione Aplicaciones web. O simplemente abra EveryStep Web Recorder, introduzca su URL y comience a grabar.
Paso 2: Navegue a la funcionalidad de inicio de sesión
Eso es todo. Ha grabado la autenticación de la aplicación, teniendo OAuth 2.0. Reproduzca el script grabado y asegúrese de que todo funciona según lo esperado. ¿No es sencillo? Una vez realizada la grabación, puede pasar a los siguientes pasos para ejecutar la prueba de carga.
Pensamientos finales: Cargar las API web de pruebas que requieren autenticación
Correlacionar mecanismos de autenticación HTTP no es una tarea fácil con cualquier herramienta de prueba de rendimiento. Usted necesita tener experiencia práctica y conocimiento profundo sobre cómo funciona el flujo de autenticación. Además, es muy importante realizar pruebas de carga para la funcionalidad de inicio de sesión. Si su módulo de inicio de sesión no puede servir la carga de usuario simultánea esperada, será una gran pérdida para su negocio. El inicio de sesión de la aplicación es una pieza crítica de la funcionalidad de su aplicación. Si está buscando una buena solución de pruebas de rendimiento de extremo a extremo para sus API web, definitivamente le gustará LoadView. Adelante y darle una oportunidad hoy!