Header Ads Widget

Ticker

6/recent/ticker-posts

La diferencia entre autenticación HTTP, claves API y OAuth

 


Al diseñar sistemas que permitan la autenticación segura y la autorización para el acceso a la API, debe considerar cómo sus aplicaciones y usuarios deben autenticarse. En este artículo, compararemos tres formas diferentes de lograr esto: claves de API , autenticación básica HTTP y OAuth . También destacaremos cuáles son los beneficios y los inconvenientes de cada método.

Claves API

El uso de claves de API es una forma de autenticar una aplicación que accede a la API, sin hacer referencia a un usuario real. La aplicación agrega la clave a cada solicitud de API y la API puede usar la clave para identificar la aplicación y autorizar la solicitud. Luego, la clave se puede usar para realizar cosas como limitación de velocidad, estadísticas y acciones similares.

La forma en que se envía la clave difiere entre las API. Algunas API usan parámetros de consulta, algunas usan el encabezado Authorize, algunas usan los parámetros del cuerpo, etc. Por ejemplo, Google Cloud acepta la clave de API con un parámetro de consulta como este:

curl -X POST https://language.googleapis.com/v1/documents:analyzeEntities?key=API_KEY

Cloudflare requires the API key to be sent in a custom header:

curl https://api.cloudflare.com/client/v4/zones/cd7d0123e301230df9514d \
     -H "Content-Type:application/json" \
     -H "X-Auth-Key:1234567893feefc5f0q5000bfo0c38d90bbeb" \
     -H "X-Auth-Email:example@example.com"

Beneficios

Es relativamente fácil para los clientes usar claves API. Aunque la mayoría de los proveedores usan métodos diferentes, agregar una clave a la solicitud de API es bastante simple.

Inconvenientes

La clave API solo identifica la aplicación, no el usuario de la aplicación. A menudo es difícil mantener la clave en secreto. Para la comunicación de servidor a servidor, es posible ocultar la clave usando TLS y restringir el acceso para que solo se use en escenarios de backend. Sin embargo, dado que muchos otros tipos de clientes consumirán las API, es probable que las claves se filtren.

Las URL de solicitud pueden terminar en registros. Las aplicaciones JavaScript tienen más o menos todo a la vista. Las aplicaciones móviles son fáciles de descompilar, etc. Por lo tanto, los desarrolladores no deben confiar en las claves API para más que identificar al cliente con fines estadísticos. Además, las claves de API tampoco están estandarizadas, lo que significa que cada API tiene una implementación única.

Autenticación básica HTTP

HTTP Basic Auth es un método simple que crea una autenticación de estilo de nombre de usuario y contraseña para solicitudes HTTP. Esta técnica utiliza un encabezado llamado Autorización, con una representación codificada en base64 del nombre de usuario y la contraseña. Dependiendo del caso de uso, HTTP Basic Auth puede autenticar al usuario de la aplicación o la propia aplicación.

Una solicitud que utiliza autenticación básica para el usuario danielcon la contraseña se passwordve así:

GET / HTTP/1.1
Host: example.com
Authorization: Basic ZGFuaWVsOnBhc3N3b3Jk

Cuando se usa la autenticación básica para una API, este encabezado generalmente se envía en cada solicitud. Las credenciales se convierten más o menos en una clave API cuando se utilizan como autenticación para la aplicación. Incluso si representa un nombre de usuario y una contraseña, sigue siendo solo una cadena estática.

En teoría, la contraseña podría cambiarse de vez en cuando, pero normalmente no es el caso. Al igual que con las claves de API, estas credenciales podrían filtrarse a terceros. Por supuesto, dado que las credenciales se envían en un encabezado, es menos probable que terminen en un registro en algún lugar que usando una consulta o un parámetro de ruta, como podría hacer la clave API.

Por lo general, no se recomienda el uso de la autenticación básica para autenticar usuarios, ya que enviar las credenciales de usuario para cada solicitud se consideraría una mala práctica. Si HTTP Basic Auth solo se usa para una sola solicitud, aún requiere que la aplicación recopile las credenciales de usuario. El usuario no tiene forma de saber para qué los usará la aplicación, y la única forma de revocar el acceso es cambiando la contraseña.

Beneficios

HTTP Basic Auth es una forma estandarizada de enviar credenciales. El encabezado siempre tiene el mismo aspecto y los componentes son fáciles de implementar. Es fácil de usar y podría ser una autenticación decente para aplicaciones en entornos de servidor a servidor.

Inconvenientes

Cuando un usuario está autenticado, la aplicación debe recopilar la contraseña. Desde la perspectiva del usuario, no es posible saber qué hace la aplicación con la contraseña. La aplicación obtendrá acceso completo a la cuenta, y el usuario no tiene otra forma de revocar el acceso que cambiar la contraseña. Las contraseñas son tokens de larga duración, y si un atacante obtiene una contraseña, probablemente pasará desapercibida. Cuando se usa para autenticar al usuario, la autenticación multifactor no es posible.

Autenticación basada en token mediante OAuth 2.0

Una arquitectura basada en token se basa en el hecho de que todos los servicios reciben un token como prueba de que la aplicación puede llamar al servicio. El token lo emite un tercero en el que pueden confiar tanto la aplicación como el servicio. Actualmente, el protocolo más popular para obtener estos tokens es OAuth 2.0 , especificado en RFC 6749 .

OAuth especifica los mecanismos en los que una aplicación puede solicitar a un usuario acceso a los servicios en nombre del usuario y recibir un token como prueba de que el usuario está de acuerdo. Para demostrar cómo funciona OAuth, consideremos el siguiente caso de uso.

Alice, una usuaria, tiene una cuenta con un servicio donde puede informar la temperatura interior actual de su casa. Alice también quiere dar acceso a una aplicación de terceros para leer los datos de temperatura, poder trazar las temperaturas en un gráfico y hacer referencias cruzadas con datos de otros servicios.

El servicio de temperatura expone una API con los datos de temperatura, por lo que la aplicación de terceros debería poder acceder a los datos con bastante facilidad. Pero, ¿cómo hacemos que solo los datos de Alice estén disponibles para la aplicación?

Recopilación de credenciales

Mediante la autenticación básica, la aplicación puede recopilar el nombre de usuario y la contraseña de Alice para el servicio de temperatura y utilizarlos para solicitar los datos del servicio. El servicio de temperatura puede verificar el nombre de usuario y la contraseña y devolver los datos solicitados.

Sin embargo, como mencionamos anteriormente, existen algunos problemas con este enfoque:

  • El usuario debe confiar las credenciales a la aplicación. El usuario no tiene forma de saber para qué se utilizan las credenciales.
  • La única forma de que el usuario revoque el acceso es cambiando la contraseña.
  • La aplicación no está autenticada
  • El alcance del acceso no se puede controlar. El usuario ha regalado acceso completo a la cuenta.
  • No se puede utilizar la autenticación de dos factores

Históricamente, esto ha creado la necesidad de que los servicios desarrollen "contraseñas específicas de la aplicación", es decir, contraseñas adicionales para que las aplicaciones utilicen su cuenta. Esto elimina la necesidad de revelar la contraseña real, pero generalmente significa regalar acceso completo a la cuenta. En el lado del proveedor de servicios, podría crear lógica en torno a la combinación de contraseñas específicas de la aplicación con claves de API, lo que también podría limitar el acceso, pero serían implementaciones totalmente personalizadas.

El camino de OAuth

Veamos cómo podríamos resolver este problema usando una estrategia OAuth 2.0. Para permitir una mejor autenticación, el servicio de temperatura debe publicar un servidor de autorización (AS) a cargo de emitir los tokens. Este AS permite que las aplicaciones de terceros se registren y reciban credenciales para que su aplicación pueda solicitar acceso en nombre de los usuarios.

Para solicitar acceso, la aplicación puede apuntar el navegador del usuario al AS con parámetros como:

https://as.temperatures.com/authorize?client_id=third_party_graphs&scope=read_temperatures&…

Esta solicitud llevará al usuario al AS del servicio de temperatura, donde el AS puede autenticar a Alice con cualquier método disponible. Dado que esto sucede en el navegador, son posibles múltiples factores, y el único que ve los datos es el servicio de temperatura y el propietario de la cuenta.

Una vez que Alice se ha autenticado, el AS puede preguntar si está bien permitir el acceso de un tercero. En este caso, se solicitó el alcance read_temperature, por lo que el AS puede generar una pregunta específica.

Cuando Alice acepta, el cliente puede autenticarse. Se emite un token como prueba de que Alice aceptó el acceso delegado y se envía de vuelta a la aplicación de terceros.

Ahora, la aplicación de terceros puede llamar a la API utilizando el token recibido. El token se envía junto con la solicitud al agregarlo al encabezado de autorización con la palabra clave Bearer de la siguiente manera:

GET /temperature HTTP/1.1
Host api.temperatures.com
Authorization: Bearer 

Al recibir la solicitud, el servicio puede validar el token y ver que Alice permitió a la aplicación leer los listados de temperatura de su cuenta y devolver los datos a la aplicación.

Validación de tokens

El token emitido se puede devolver de dos formas, ya sea devolviendo una referencia a los datos del token o devolviendo el valor del token directamente. Para el token de referencia, el servicio deberá enviar una solicitud al AS para validar el token y devolver los datos asociados con él. Este proceso se llama introspección y una respuesta de muestra se ve así:

{
"active": true,
"sub": “alice”,
"client_id": "third_party_graphs",
"scope": "read_temperatures"
}

En esta respuesta, podemos ver que el usuario alicele ha otorgado a la aplicación third_party_graphsacceso a su cuenta, con el alcance de read_temperatures.
Con base en esta información, el servicio puede decidir si debe permitir o rechazar la solicitud. El client_idtambién se puede utilizar para las estadísticas y limitante de la velocidad de la aplicación. Tenga en cuenta que solo obtuvimos el nombre de usuario de la cuenta en el ejemplo, pero dado que el AS hace la autenticación, también puede devolver reclamos adicionales en esta respuesta (cosas como tipo de cuenta, dirección, talla de zapatos, etc.) Los reclamos pueden ser cualquier cosa que puede permitir que el servicio tome una decisión de autorización bien informada.

Para devolver el valor, generalmente se usa un formato de token como JSON Web Token (JWT). Este token se puede firmar o cifrar para que el servicio pueda verificar el token simplemente utilizando la clave pública del AS de confianza.

Consejo: lea este recurso para obtener recomendaciones sobre los tipos de tokens.

Podemos ver una clara diferencia aquí:

  • Alice solo dio sus credenciales para el sitio de confianza.
  • Se puede utilizar la autenticación multifactor.
  • Alice puede revocar el acceso a la aplicación, solicitando al sitio de temperatura que retire su consentimiento, sin cambiar su contraseña.
  • Alice puede permitir que la aplicación de terceros acceda solo a cierta información de su cuenta.
  • Las reclamaciones sobre el usuario se pueden entregar al servicio directamente a través de la solicitud. No se requieren búsquedas adicionales.
  • El flujo está completamente estandarizado.

Resumen

Dado que OAuth 2.0 se desarrolló en el momento de un mercado de API en crecimiento, la mayoría de los casos de uso de claves de API y autenticación básica ya se han considerado dentro del protocolo. Es seguro decir que supera a la competencia en todas las cuentas. Para casos de uso pequeños y específicos, podría estar bien usar claves de API o autenticación básica, pero cualquier persona que cree sistemas que planeen crecer debería buscar una arquitectura basada en tokens como la arquitectura de seguridad Neo .

En el caso de uso anterior, solo describí el flujo de usuarios, pero OAuth, por supuesto, especifica flujos alternativos para obtener tokens en entornos de servidor a servidor. Puede leer más sobre los de mi publicación anterior que explora ocho tipos de flujos y poderes de OAuth .

Publicar un comentario

0 Comentarios