¿Razón para usar solo secretos como claves API?

Esas claves de la API a menudo se llaman tokens. A menudo se asume que tienen una vida útil bastante corta y se utilizan más o menos como un ID de sesión de alto nivel. No es una sesión verdadera porque se usan para solicitudes sin estado y solo llevan la identificación del usuario. Pero su vida en general se extiende desde unas pocas horas hasta varios días. Además, nunca son una clave de acceso principal, por lo que si la base de datos del token se ve comprometida, se vacía de inmediato y los usuarios solicitan nuevas claves API.

Como ya se señaló, no hay nada que haga esto menos seguro. No es tan difícil buscar en la base de datos hash(secret) en lugar de account_id .

Desde la perspectiva de los atacantes, adivinar una clave de API es bastante difícil (la mayoría de ellos son de tamaño considerable). El uso del esquema account_id:secret (suponiendo que el secreto sea la clave de la API, no la contraseña del usuario) ciertamente agrega aún más seguridad, pero sin efecto práctico (los nombres de las cuentas rara vez son un secreto, por lo que obtenerlos no es demasiado difícil. Ningún atacante lo haría al azar adivina uno, además de adivinar una clave).

Además, piense en dónde se usan esas claves API. Muy probablemente en procesos automatizados (es decir, una secuencia de comandos de Python haciendo algún trabajo). Al requerir que los desarrolladores agreguen un nombre de cuenta, los obliga a escribirlo en el código o en algún archivo de configuración. En caso de un ataque, prefiero perder mi clave de API, que puedo revocar e intercambiar fácilmente por una nueva, en lugar de perder mi account_id y el API key . Al usar account_id , un atacante solo necesita la contraseña para secuestrar su cuenta, lo que probablemente sea menos seguro en comparación con una clave API larga (por lo que académicamente, agregar account_id debilita su seguridad, mientras que omitirla realmente no bájalo).

  

Muchas API protegidas con claves API solo usan la clave secreta (es decir, una   contraseña) sin algo como un ID de cuenta o nombre de usuario.

o comúnmente conocidas como tokens, se proporcionan después de la autenticación exitosa a través de account_id y contraseña adecuados. Esto se puede hacer durante las llamadas a la API, por lo que el cliente proporciona una vez sus credenciales para obtener una clave que, a su vez, se utiliza para las siguientes llamadas a la API. Las mismas credenciales se utilizan para revocar o renovar un token.

  

¿Por qué es esto mejor que usar un combo account_id: secret_key en el   autenticación?

Las API están diseñadas para permitir la comunicación entre sistemas y no están diseñadas para tener una interacción directa con el usuario, en mi opinión, una identificación de cuenta tiene un significado diferente que identificar un sistema (cliente).

Sin embargo, la razón principal por la que es mejor usar un token en lugar de account_id / password es evitar la circulación frecuente de la contraseña a través del cable. Recuerde que la naturaleza sin estado de la API hace que el cliente proporcione credenciales en cada solicitud.