<\/p>\n
Autenticaci\u00f3n<\/h3>\n
La autenticaci\u00f3n no es m\u00e1s que validar a un usuario si es la persona adecuada para usar ese servicio. Vamos a explicarlo m\u00e1s adelante con un ejemplo simple. Supongamos que est\u00e1 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\u00fablico en el restaurante, quieres sentarte en una habitaci\u00f3n 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\u00f3n privada del restaurante reservada para familias. Por lo tanto, esto es lo que llamamos como autenticaci\u00f3n. El gerente del restaurante le ha permitido sentarse con su familia en un lugar privado con una reserva v\u00e1lida. Podemos decir que la reserva se denomina clave de autenticaci\u00f3n.<\/p>\n
<\/p>\n
Autorizaci\u00f3n<\/h3>\n
Ahora, se le permite en la habitaci\u00f3n privada y se puede utilizar los servicios reservados para los comensales privados, etc. Usted est\u00e1 autorizado a hacer todo esto, pero si usted va a la cocina del restaurante y abrir su refrigerador pueden decir que no est\u00e1n permitidos en esta \u00e1rea. As\u00ed que esto se llama autorizaci\u00f3n. As\u00ed que se le permite entrar, pero despu\u00e9s de entrar en el restaurante no est\u00e1 autorizado a entrar en algunas \u00e1reas y no est\u00e1 autorizado a acceder a alguna otra \u00e1rea. As\u00ed que esto es lo que es la autorizaci\u00f3n.<\/p>\n
Ahora, cuando se trata de un sitio web, cualquiera puede ingresar a una p\u00e1gina<\/a> de inicio de sesi\u00f3n de sitio web p\u00fablico. Igual que cualquiera puede entrar en un restaurante. Nadie va a detenerte. Cuando inicia sesi\u00f3n con el nombre de usuario<\/a> y la contrase\u00f1a de su sitio web, se autentica y puede ingresar al sitio web. De la misma manera que accedi\u00f3 a una mesa privada reservada en un restaurante utilizando una reserva. Pero despu\u00e9s de entrar, y despu\u00e9s de la autenticaci\u00f3n, puede acceder a algunas secciones, pero es posible que no pueda acceder a algunas otras secciones que son como secciones de administraci\u00f3n del sitio web. As\u00ed que esta es una diferencia muy b\u00e1sica entre la autenticaci\u00f3n y la autorizaci\u00f3n.<\/p>\n Ahora, volvamos a nuestra pregunta. Siempre vemos autorizaci\u00f3n en una API, \u00bfpor qu\u00e9 es as\u00ed? Si observa la API, apunta a un punto final donde esa direcci\u00f3n se dirige a una funci\u00f3n o recurso determinado en la aplicaci\u00f3n. Podemos decir, por ejemplo, un m\u00f3dulo en el back-end de la aplicaci\u00f3n. Cuando realmente est\u00e1 intentando acceder a un recurso determinado solo en la aplicaci\u00f3n, es m\u00e1s adecuado llamarlo como autorizaci\u00f3n para usted, aunque habr\u00e1 autenticaci\u00f3n para verificar su identidad. El primer paso es siempre la autenticaci\u00f3n.<\/p>\n <\/p>\n Puesto que hemos cubierto la diferencia entre la autenticaci\u00f3n y la autorizaci\u00f3n, ahora discutiremos diferentes tipos de autenticaciones de API. Los m\u00e9todos de autenticaci\u00f3n de API var\u00edan en funci\u00f3n de la t\u00e9cnica que utilizan. Las autenticaciones son muy importantes porque est\u00e1n directamente relacionadas con la seguridad del sistema. Es por eso que la prioridad siempre va a la autenticaci\u00f3n HTTP en cualquier sistema.<\/p>\n 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\u00f3mo funcionan y las ventajas y desventajas de cada enfoque. Por \u00faltimo, demostraremos las pruebas de carga de una API que requiere autenticaci\u00f3n mediante LoadView<\/a>.<\/p>\n <\/p>\n La autenticaci\u00f3n b\u00e1sica HTTP rara vez es utilizada por la industria de TI hoy en d\u00eda<\/a>, porque es muy f\u00e1cil ser pirateado, pero este es el m\u00e9todo m\u00e1s f\u00e1cil de implementar. Las API enviar\u00e1n un nombre de usuario y una contrase\u00f1a a lo largo del cuerpo. Las credenciales se codificar\u00e1n con el m\u00e9todo de cifrado como Base64<\/em>; esto convertir\u00e1 el nombre de usuario y la contrase\u00f1a en formato cifrado para la transmisi\u00f3n.<\/p>\n Puesto que utiliza el encabezado para la transmisi\u00f3n de credenciales, no hay otras medidas de seguridad complejas en su lugar. Ni siquiera los ID de sesi\u00f3n o las cookies.<\/p>\n <\/p>\n Autorizaci\u00f3n: B\u00e1sico Cg4sOnOlY8KyPQ<\/em><\/p>\n <\/p>\n La autenticaci\u00f3n de acceso de resumen es m\u00e1s compleja y avanzada que la autenticaci\u00f3n b\u00e1sica. Digest utiliza una combinaci\u00f3n de la contrase\u00f1a del usuario y otros atributos para crear un hash MD5. Esto se enviar\u00e1 al servidor para la autenticaci\u00f3n. Es m\u00e1s avanzado que otro mecanismo de seguridad, ya que env\u00eda las credenciales como hash. Fue creado originalmente como parte de RFC 2069, las mejoras de seguridad se agregaron m\u00e1s tarde en RFC 2617.<\/p>\n En la autenticaci\u00f3n impl\u00edcita, es el servidor el que detecta al cliente que intenta acceder al recurso. El servidor<\/a> generar\u00e1 un valor \u00fanico, denominado “nonce”. M\u00e1s adelante, este valor \u00fanico ser\u00e1 utilizado por el solicitante de recursos para generar un hash MD5, que ser\u00e1 verificado por el servidor.<\/p>\n <\/p>\n Las claves de API se utilizan ampliamente en comparaci\u00f3n con la autenticaci\u00f3n b\u00e1sica hoy en d\u00eda. Se puede ver en aplicaciones m\u00f3viles, as\u00ed como aplicaciones web. Las claves API se crearon de alguna manera para resolver<\/a> las vulnerabilidades de seguridad asociadas con el mecanismo b\u00e1sico de API. En una clave de API, se genera un valor \u00fanico en el lado del servidor una vez que se autentica con su nombre de usuario y contrase\u00f1a. Se asignar\u00e1 al usuario. Por lo general, este valor \u00fanico se genera en funci\u00f3n de la direcci\u00f3n IP y los diferentes atributos de usuario. La mayor\u00eda de las veces, los desarrolladores enviar\u00e1n la clave de API en el encabezado de autorizaci\u00f3n.<\/p>\n <\/p>\n api_key: d670d200234faf5480aa11529b01d732<\/em><\/p>\n Definitivamente hay muchas ventajas de usar una clave de API, en comparaci\u00f3n con todos los dem\u00e1s 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\u00f3n.<\/p>\n <\/p>\n Portador significa “una persona o cosa que lleva o sostiene algo”. Como su nombre indica, es un esquema de autenticaci\u00f3n HTTP que implica tokens de seguridad. El portador del token de seguridad tendr\u00e1 acceso a ciertas funciones o direcciones URL. El token de portador normalmente lo generar\u00e1 el servidor en respuesta a una solicitud de inicio de sesi\u00f3n de cliente. Una vez que el usuario tiene el token de portador del servidor, debe enviar el token junto con el encabezado de autorizaci\u00f3n al realizar m\u00e1s solicitudes.<\/p>\n <\/p>\n Autorizaci\u00f3n: <\/em><\/p>\n Portador eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy93cy8yMDA1LzA1L2lkZW50aXR5L2NsYWltcy9uYW1lIjoiNmUyZTU0NjUtNTRjZi00ZTU2LTk2NDEtNDU4Njg0YjVjNWQyIiwiZXhwIjoxNTkzOTY3ODQ0LCJpc3MiOiJodHRwOlxcd3D3LnNvdWxib29rLm1lIiwiYXVkIjoiaHR0cDpcXHd3dy5zb3VsYm9vay5tZSJ9.adcAYn8U5tn68EVGUGPLYBKcGC8Ohgxm7p45tDnpXVc<\/em><\/p>\n Fue creado originalmente como parte de OAuth2.0 en RFC-6750. Definitivamente hay muchas ventajas de usar tokens portadores en comparaci\u00f3n con todos los dem\u00e1s mecanismos de seguridad. Los tokens de portador son mejores en t\u00e9rminos de seguridad.<\/p>\n <\/p>\n OAuth es un protocolo<\/a> m\u00e1s seguro para la autorizaci\u00f3n. OAuth<\/a> proporciona simplicidad a la vez que proporciona flujo de autorizaci\u00f3n para las aplicaciones. OAuth es generalmente utilizado por los usuarios para iniciar sesi\u00f3n en sitios web de terceros utilizando sus cuentas de Google, Microsoft, Facebook, Slack, por ejemplo, sin exponer sus credenciales.<\/p>\n OAuth 1.0 es sospechoso de vulnerabilidades de seguridad y ya no es compatible. OAuth 2.0 tiene caracter\u00edsticas de seguridad avanzadas y es el mejor para la identificaci\u00f3n y autenticaci\u00f3n de cuentas de usuario personales. OAuth 2.0 permite a los usuarios compartir sus atributos espec\u00edficos con una aplicaci\u00f3n, manteniendo sus credenciales y otra informaci\u00f3n en secreto. OAuth 1.0 era mucho m\u00e1s 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.<\/p>\n B\u00e1sicamente, OAuth consta de dos tokens para realizar la verificaci\u00f3n; un token de autenticaci\u00f3n y un token de sesi\u00f3n. Los tokens de autenticaci\u00f3n funcionan como protocolos de seguridad de claves de API, la aplicaci\u00f3n se autentica para acceder a los datos de usuario. Los tokens de sesi\u00f3n se utilizan para mantener la sesi\u00f3n de usuario y recuperar un nuevo token de autenticaci\u00f3n si el token de sesi\u00f3n ha caducado. OAuth 2.0 combina la autenticaci\u00f3n y la autorizaci\u00f3n para permitir m\u00e1s seguridad a la aplicaci\u00f3n.<\/p>\n En OAuth, el usuario tendr\u00e1 acceso a la aplicaci\u00f3n con credenciales. A continuaci\u00f3n, la aplicaci\u00f3n solicitar\u00e1 un token de autenticaci\u00f3n. El solicitante enviar\u00e1 esta solicitud a un servidor de autenticaci\u00f3n, lo que permitir\u00e1 esta autenticaci\u00f3n si las credenciales son correctas. Este token de autenticaci\u00f3n se puede verificar en cualquier momento, independientemente del usuario. Esto har\u00e1 que OAuth sea un mecanismo mucho m\u00e1s seguro que las otras autenticaciones HTTP. Una de las principales desventajas de OAuth es la complejidad a implementar. Debe tener un conocimiento s\u00f3lido en el flujo de OAuth para integrarlo con la aplicaci\u00f3n.<\/p>\n <\/p>\n OpenID Connect es una extensi\u00f3n del protocolo OAuth 2.0. Comprueba la identidad del cliente en funci\u00f3n de la autenticaci\u00f3n realizada por un servidor de autorizaci\u00f3n. Adem\u00e1s, puede obtener informaci\u00f3n de perfil de usuario sobre el cliente. OpenID connect realmente resuelve muchas desventajas de OAuth 2.0 y proporciona una mejor soluci\u00f3n para los usuarios finales y desarrolladores.<\/p>\n <\/p>\n La autenticaci\u00f3n b\u00e1sica HTTP es la m\u00e1s f\u00e1cil de implementar en la aplicaci\u00f3n, pero tampoco es segura en absoluto. Las credenciales est\u00e1n codificadas, pero se env\u00edan como texto sin formato. La autenticaci\u00f3n impl\u00edcita mejora la autenticaci\u00f3n b\u00e1sica mediante el env\u00edo de datos en formato hash. Pero el hash del algoritmo MD5 no es complejo en absoluto y puede ser hackeado muy f\u00e1cilmente. Las claves de API y el portador son casi similares y proporcionan una mejor seguridad que arriba.<\/p>\n El protocolo OAuth garantiza que ning\u00fan pirata inform\u00e1tico pueda obtener informaci\u00f3n del cliente. Incluso la aplicaci\u00f3n no puede obtener las credenciales de perfil de cliente y la informaci\u00f3n privada. OpenID Connect establece protocolos para que las aplicaciones accedan a los atributos del cliente mediante la API RESTful<\/a>. OpenID Connect ampl\u00eda el flujo de tokens de autorizaci\u00f3n de OAuth 2.0 introduciendo nuevos tokens. B\u00e1sicamente, OpenID Connect se realiza como una extensi\u00f3n de OAuth 2.0.<\/p>\n <\/p>\n En esta secci\u00f3n, vamos a implementar la autenticaci\u00f3n de API HTTP mediante LoadView. LoadView le permite realizar estas tareas de forma muy f\u00e1cil y eficiente. Load View proporciona dos opciones para las pruebas de carga de autenticaci\u00f3n de API:<\/p>\n <\/p>\n Si tiene acceso a la aplicaci\u00f3n podemos obtener la solicitud de API utilizando cualquier herramienta de red. Este es el m\u00e9todo m\u00e1s simple. Mostraremos una demostraci\u00f3n r\u00e1pida para configurar cada uno de los mecanismos de autenticaci\u00f3n HTTP anteriores utilizando LoadView<\/p>\n 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.<\/em><\/p>\n <\/p>\n La siguiente pantalla le pedir\u00e1 que configure su API. Aqu\u00ed le mostraremos c\u00f3mo puede configurar diferentes mecanismos de autenticaci\u00f3n HTTP en LoadView.<\/p>\n Autenticaci\u00f3n b\u00e1sica<\/strong><\/p>\n <\/p>\n Claves de API<\/strong><\/p>\n <\/p>\n Ficha de portador<\/strong><\/p>\n <\/p>\n OAuth 2.0<\/strong><\/p>\n OAuth 2.0 y Open ID Connect son m\u00e1s complejos de configurar. Te mostrar\u00e9 una demo para OAuth 2.0. Hay una manera f\u00e1cil de hacer la autenticaci\u00f3n de OAuth 2.0 que explicar\u00e9 despu\u00e9s de esta secci\u00f3n.<\/p>\n <\/p>\n Configure los detalles del servidor de autenticaci\u00f3n de OAuth.<\/p>\n <\/p>\n Escriba las credenciales y haga clic en Login (Inicio de sesi\u00f3n). El servidor de autenticaci\u00f3n redirige al usuario a su sitio web con un c\u00f3digo como par\u00e1metro URL.<\/p>\n <\/p>\n <\/p>\n El servidor de API solicita informaci\u00f3n del usuario al servidor de autenticaci\u00f3n.<\/p>\n <\/p>\n Los servidores de API identifican al usuario y responden con un token de acceso. A continuaci\u00f3n, el usuario env\u00eda el token de acceso al servidor de API en cada solicitud. El servidor DE API valida y da acceso a la aplicaci\u00f3n.<\/p>\n <\/p>\n <\/p>\n Si la primera opci\u00f3n no es factible, puede grabarla con la herramienta de grabaci\u00f3n EveryStep Web Recorder.<\/a> Se puede acceder a ella a trav\u00e9s de la web y el uso de la grabadora es m\u00e1s f\u00e1cil y eficaz. Adem\u00e1s, no es necesario aprender diferentes mecanismos de autenticaci\u00f3n. Aqu\u00ed vamos a demostrar c\u00f3mo hacer pruebas de carga mediante LoadView y el uso de EveryStep Web Recorder. La aplicaci\u00f3n utiliza OAuth 2.0 para la autenticaci\u00f3n.<\/p>\n <\/p>\n Inicie sesi\u00f3n en LoadView y, en Seleccionar un tipo de prueba de carga<\/em>, seleccione Aplicaciones web<\/em>. O simplemente abra EveryStep Web Recorder<\/a>, introduzca su URL y comience a grabar.<\/p>\n <\/p>\n <\/p>\n <\/p>\n Eso es todo. Ha grabado la autenticaci\u00f3n de la aplicaci\u00f3n, teniendo OAuth 2.0. Reproduzca el script grabado y aseg\u00farese de que todo funciona seg\u00fan lo esperado. \u00bfNo es sencillo? Una vez realizada la grabaci\u00f3n, puede pasar a los siguientes pasos para ejecutar la prueba de carga.<\/p>\n <\/p>\n Correlacionar mecanismos de autenticaci\u00f3n HTTP no es una tarea f\u00e1cil con cualquier herramienta de prueba de rendimiento. Usted necesita tener experiencia pr\u00e1ctica y conocimiento profundo sobre c\u00f3mo funciona el flujo de autenticaci\u00f3n. Adem\u00e1s, es muy importante realizar pruebas de carga para la funcionalidad de inicio de sesi\u00f3n. Si su m\u00f3dulo de inicio de sesi\u00f3n no puede servir la carga de usuario simult\u00e1nea esperada, ser\u00e1 una gran p\u00e9rdida para su negocio. El inicio de sesi\u00f3n de la aplicaci\u00f3n es una pieza cr\u00edtica de la funcionalidad de su aplicaci\u00f3n. <\/strong> Si est\u00e1 buscando una buena soluci\u00f3n de pruebas de rendimiento de extremo a extremo para sus API web<\/a>, definitivamente le gustar\u00e1 LoadView. Adelante y darle una oportunidad hoy<\/a>!<\/p>\n[\/et_pb_text][\/et_pb_column][\/et_pb_row][\/et_pb_section]\n","protected":false},"excerpt":{"rendered":" En la econom\u00eda actual impulsada por TI, las API web son cada vez m\u00e1s 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\u00f3n de servicios de software est\u00e1 buscando espec\u00edficamente para proteger estos datos. La […]<\/p>\n","protected":false},"author":5,"featured_media":12090,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"on","_et_pb_old_content":"","_et_gb_content_width":"","footnotes":""},"categories":[168,174,149],"tags":[175,151],"class_list":["post-12018","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-user-experience-es","category-api-testing-es","category-performance-testing-es","tag-api-testing-es","tag-pruebas-de-carga"],"yoast_head":"\nTipos de autenticaciones HTTP<\/h2>\n
Autenticaci\u00f3n b\u00e1sica<\/h3>\n
Ejemplo de autenticaci\u00f3n b\u00e1sica en un encabezado de solicitud:<\/h4>\n
Autenticaci\u00f3n impl\u00edcita<\/h3>\n
Claves de API<\/h3>\n
Ejemplo de una clave de API<\/h4>\n
Portador<\/h3>\n
Ejemplo de autenticaci\u00f3n de portador<\/h4>\n
OAuth 1.0 y OAuth 2.0<\/h3>\n
OpenID Connect<\/h3>\n
\u00bfCu\u00e1l es el mejor protocolo de autenticaci\u00f3n para usar?<\/h3>\n
Uso de LoadView para probar una API que requiere autenticaci\u00f3n<\/h2>\n
Autenticaci\u00f3n API: Opci\u00f3n Uno<\/h3>\n
\u00a0<\/h5>\n
Paso 1: Seleccione un tipo de prueba de carga<\/strong><\/h4>\n
Inicie sesi\u00f3n en LoadView y, en Seleccionar un tipo de prueba de carga<\/em>, seleccione HTTP\/S<\/em>.<\/h5>\n
![\"Seleccione](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/Select-a-Load-Testing-Type-1024x459.png\")
<\/p>\nPaso 2: Configure su API<\/strong><\/h4>\n
![\"Autenticaci\u00f3n](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/Basic-Authentication-1024x466.png\")
<\/p>\n![\"Claves](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/API-Keys-1024x465.png\")
<\/p>\n![\"Ficha](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/Bearer-Token-1024x461.png\")
<\/p>\nPaso 1: Servidor de autenticaci\u00f3n OAuth<\/strong><\/h5>\n
![\"Autenticaci\u00f3n](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/OAuth-Authentication-1024x437.png\")
<\/p>\nPaso 2: Credenciales<\/strong><\/h5>\n
![\"Credenciales](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/OAuth-Authentication-Credentials-1024x462.png\")
<\/p>\nPaso 3: Informaci\u00f3n del servidor<\/strong><\/h5>\n
![\"Informaci\u00f3n](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/OAuth-Authentication-Server-Information-1024x457.png\")
<\/p>\nPaso 4: Token de acceso<\/strong><\/h5>\n
![\"Token](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/OAuth-Authentication-Access-Token-1024x449.png\")
<\/p>\nAutenticaci\u00f3n API: Opci\u00f3n Dos<\/h3>\n
Paso 1: Grabar un nuevo gui\u00f3n<\/strong><\/h4>\n
![\"Registro](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/OAuth-record-new-script-1024x445.jpg\")
<\/p>\nPaso 2: Navegue a la funcionalidad de inicio de sesi\u00f3n<\/strong><\/h4>\n
![\"Inicio](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/OAuth-Sign-In-1024x447.png\")
<\/p>\n![\"OAuth](\"https:\/\/www.loadview-testing.com\/wp-content\/uploads\/OAuth-Sign-In-Step-2-1024x449.png\")
<\/p>\nPensamientos finales: Cargar las API web de pruebas que requieren autenticaci\u00f3n<\/h2>\n