Diseño de API: Autenticación básica HTTP vs Token API

Actualmente estoy creando un sistema de autenticación en frente de una API web pública para una aplicación web. Dado que cada cuenta de usuario tiene una clave API y cada solicitud debe ser autenticada, tengo dos alternativas:

  1. Usando una autenticación básica HTTP, como lo hace GitHub.

    Las solicitudes deben enviarse a la URL

    http://api.example.com/resource/id
with basic authentication
username: token
password: the api key

  2. Pasando el token API como parámetro querystring.

    Las solicitudes deben enviarse al URL 

    http://api.example.com/resource/id?token=api_key

También hay una tercera opción que es pasar el token dentro del URI, pero honestamente no me gusta esa solución.

¿Qué solución adoptarías y por qué?

Author: Simone Carletti, 2011-02-11
Source

4 answers

Creo que HTTP Basic Auth debería estar bien, pero solo para necesidades realmente simples.

La solución completa (y final) en MI humilde opinión es implementar un proveedor OAuth. No es complejo, es un protocolo simple y le da mucha flexibilidad. Además, parece ser la tendencia actual, ya que muchos grandes jugadores lo implementan y es compatible con muchas bibliotecas.

 12
Author: Diego Giorgini,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-10-19 12:32:05

La mejor opción podría ser usar una clave API en el encabezado (por ejemplo, 'Authorization: Token MY_API_KEY') en lugar de como un parámetro de url:

Ventajas sobre HTTP Basic Auth:

  • Más conveniente, ya que puede caducar o regenerar tokens fácilmente sin afectar la contraseña de la cuenta del usuario.
  • Si está comprometida, la vulnerabilidad se limita a la API, no a la cuenta maestra del usuario
  • Puede tener varias claves por cuenta (por ejemplo, los usuarios pueden tener claves" prueba "y" producción " al lado lado.)

Ventajas sobre la clave API en URL:

  • Proporciona una medida adicional de seguridad al evitar que los usuarios compartan URL inadvertidamente con sus credenciales incrustadas en ellas. (Además, la URL puede terminar en cosas como los registros del servidor)
 29
Author: Yarin,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-12-24 02:33:47

Muchas veces tuve que pensar en cómo autenticar usuarios/solicitudes en API y después de comparar más soluciones terminé usando la solución de Amazon donde no necesito o no puedo usar OAuth. Esta solución se basa en firmas que evita problemas de "man in the middle" ya que la autenticación básica y el paso de un token simple están enviando datos de texto sin formato. Sí, puede agregar ssl, pero esto agregará complejidad al sistema...

 17
Author: dlondero,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-11-23 15:12:13

Preferiría usar la solución token. Si no tiene usuarios reales con su propio nombre de usuario y contraseña, entonces se siente como si estuviera utilizando la construcción Básica de autenticación no como se pretendía. No es que eso esté necesariamente mal, pero no tan limpio, IMO. También elimina la necesidad de usar encabezados personalizados y creo que hace que la implementación en ambos lados sea más fácil y más limpia. La siguiente pregunta que me haría es si debería usar la autenticación de dos factores o si necesita administrar sesiones en todo.

 1
Author: Christopher Martin,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-10-10 19:34:23