de autenticación de API REST

he encontrado bastantes preguntas sobre este tema en SO, pero no pudieron encontrar ninguna respuesta a esta pregunta: ¿de autenticación de API REST

¿Debo validar a los usuarios con su nombre de usuario y contraseña, o con una clave de API? Y cuáles son los pros y los contras de cada método.

Pregunto esto porque en mi API, hay un par de métodos que me gustaría bloquear y verificar que el usuario tenga acceso a algún documento o acción. Soy un poco reacio a autenticar al hacer que el usuario envíe un encabezado HTTP AUTH con su nombre de usuario y contraseña porque no se siente seguro y es un poco más molesto para el usuario. Por otro lado, sin embargo, si uso una clave API, ¿cuál es el punto de que el usuario cree una contraseña? Como ya no lo usarán para acceder a las características de la API.

ACTUALIZACIÓN

Si otros lectores de esto son curiosidad por lo que terminé usando, decidí copiar la forma en Amazon hace su validación (buena explicación here: https://www.ida.liu.se/~TDP024/labs/hmacarticle.pdf)

Fuente

2011-09-30 Obto

Apreciar la ACTUALIZACIÓN. Gracias. –

El enlace está roto, por favor considere actualizarlo. Enlace actualizado: https://www.ida.liu.se/~TDP024/labs/hmacarticle.pdf –

enlace: http://acaasia.blogspot.co.il/2013/04/designing-secure-rest-web- api-without.html – OhadR

puede utilizar la autenticación HTTP sobre SSL y eso es lo suficientemente seguro. Sin embargo, dificulta el consumo de API ya que requiere que la biblioteca del cliente admita SSL. SSL también puede afectar el rendimiento si espera demasiadas llamadas simultáneamente.

La opción de clave API es tan insegura como la Autenticación HTTP sin SSL. Si no le preocupa la seguridad, API Key es la más fácil para los consumidores de la API.

Fuente

2011-09-30 06:15:45

Así que si vas a la ruta de la clave API, ¿vale la pena incluso que el usuario haga una contraseña? Parece que la clave API se desharía de la mayoría si no es que todo el propósito de tener una contraseña – Obto

El nombre de usuario @Obto se puede generar secuencialmente y la contraseña se puede generar aleatoriamente. Cuantas más partes de la credencial de autenticación; más largo y más difícil es descifrar la contraseña. Es realmente una cuestión de gusto. Una clave API más larga con partes secuenciales y aleatorias o un nombre de usuario y contraseña separados. La clave API generalmente no es legible por el ser humano y se genera automáticamente (en cuyo caso la contraseña es redundante). –

Así que, al final, parece que realmente se trata de su propia preferencia – Obto

Un buen método es tener un método de inicio de sesión, tomando el nombre de usuario y la contraseña (con suerte sobre TLS). Les das un token que expira si se autentican con éxito; el resto de sus llamadas API debe contener este token para tener éxito.

Fuente

2011-09-30 06:16:11 Ivo

@HasanKhan bien claramente oAuth está haciendo algo mal. – Ivo

@Hasan Khan Tenga en cuenta que el token no * necesita * ser almacenado en estado compartido; simplemente se puede crear de manera determinista utilizando un secreto del lado del servidor (por ejemplo, fecha hash con secreto, hora hash con secreto o timestamp cifrado reversiblemente). Por lo tanto, puede usar una tienda con estado que probablemente se escale a por lo menos miles de solicitudes por segundo sin problemas y elija una opción más eficaz si es necesario. –

Respuesta

Cuestiones relacionadas