De todas las investigaciones que he realizado, he encontrado que las claves de API son menos seguras que las tokens de acceso (bajo el uso de oAuth), y solo se deben usar para fines de monitoreo.
Pero a partir de lo que entendí, el servidor genera ambos. Entonces, si utilizara el mismo algoritmo difícil para crear mi token de acceso, o para crear la clave API, ¿eso no los haría similares? Los ejemplos ayudarían a comprender mejor la causa, ya que no encontré ninguno.
Las claves API son públicas, por intención. Son un mecanismo de autorización, no un mecanismo de autenticación (esto se menciona en sus enlaces). No importa cómo se generen , pero sí importa cómo se manejan . En otras palabras: "cualquier persona con esta clave puede ingresar".
Por lo tanto, utiliza las claves de API cuando quiere autorizar y no necesita autenticarse. Utiliza tokens de autenticación, que están protegidos en el manejo , para autenticar la conexión. En otras palabras, "aquí está su clave única para permitirle ingresar esta hora".
Una clave API típica para una aplicación REST-ful suele ser significativamente menos segura que el control de acceso proporcionado por un JWT OAuth (token web JSON) por motivos relacionados con la mensajería de protocolo de capa de aplicación (orden, sintaxis, protección de la unidad de datos (o la falta de la misma), a diferencia de la protección que resulta solo del uso de un algoritmo criptográfico particular, modo y / o tamaño de clave. Sin embargo, no me sorprendería si los generadores de cadena de clave API fueran más predecibles que los generadores de cadena de token de acceso OAuth. Las claves de API a menudo se envían como parámetros de consulta HTTP GET dentro de la primera línea de una solicitud HTTP como se muestra aquí con la API de JavaScript de Google Maps:
<script async defer src="https://maps.googleapis.com/maps/api/jskey=YOUR_API_KEY&callback=initMap" type="text/javascript"></script>
Debido al hecho de que la cadena de clave API se pasa como un parámetro de consulta GET de HTTP, es mucho más fácil para los servidores web intermedios (incluidos los proxies) y los navegadores con lenguajes de script del lado del cliente como JavaScript o ActionScript para obtener acceso de lectura y / o escritura a la clave API. Compare esto con otros tipos de acciones HTTP como PUT o POST donde los parámetros de consulta están más ocultos de las tecnologías mencionadas anteriormente. Casi todo el software del servidor web escribirá el valor del atributo src en la etiqueta script anterior a access_log y / o error_log archivos que incluyen la clave API, ya que los valores de las variables de parámetros de consulta son parte de las variables de entorno CGI (Common Gateway Interface): SCRIPT_PATH y QUERY_STRING . Consulte CWE-598 para obtener más información.
Los tokens de acceso OAuth, por otro lado, se generan por sesión. No se producirá un token de acceso otorgado por un proveedor de autenticación seguro, hasta que el proveedor haya recibido la prueba de que el usuario solicitante tiene derecho a los privilegios solicitados; dicha prueba podría establecerse a través del conocimiento de las credenciales (es decir, un par de nombre de usuario y contraseña correspondientes). Otras veces, el control de acceso puede ser más restrictivo y los tokens de acceso solo se proporcionan para un pequeño subconjunto de privilegios dentro de una aplicación / sitio / API en particular subcomponente, área de operación, esfera de control, etc. Los permisos que se otorgan en última instancia al usuario final pueden ser tan específicos como lo desee el administrador del sistema. Tenga en cuenta que los tokens de acceso están programados para caducar después de un período de tiempo establecido y son capaces de proporcionar control de acceso discrecional entre varios usuarios / grupos, privilegios / capacidades, etc.
Los tokens de acceso a menudo se transfieren fuera de la URL en el campo de Autorización del encabezado de solicitud HTTP, por ejemplo. A veces, las implementaciones del marco de autenticación personalizado harán que el token se transmita dentro de una cookie que tiene habilitadas las marcas HttpOnly , Secure y SameSite - o como un encabezado de solicitud HTTP personalizado como X-Auth-Token como se documenta públicamente para el almacenamiento en la nube de Oracle SaaS: API de Oracle Cloud Storage Service :
Es extremadamente raro que los encabezados de solicitud HTTP y los valores de las cookies sean registrados por el software del servidor / navegador web; también son más difíciles de acceder programáticamente debido a CORS (Intercambio de recursos de origen cruzado). En comparación, las claves API pasadas como parámetros HTTP GET pueden extraerse con JavaScript del lado del cliente desde el DOM (Modelo de objetos de documento).
Por estas razones, la complejidad requerida para obtener tokens de acceso de un marco de autenticación como OAuth es mucho mayor que la necesaria para registrar el uso de una clave API. Además, la robustez de los marcos de autenticación y autorización permite encapsular el token de acceso dentro del protocolo HTTP de manera que es bastante difícil verlo o manipularlo.
Lea otras preguntas en las etiquetas authentication oauth oauth2 access-control api