implement - oauth2 api
¿Por qué está diseñado OAuth para tener token de solicitud y acceso? (2)
En el protocolo OAuth, un consumidor del servicio le pedirá a un usuario que autorice un token de solicitud en el dominio del proveedor del servicio, luego intercambiará el token de solicitud de un token de acceso del proveedor del servicio.
Me pregunto por qué OAuth está diseñado para tener dos tokens en el protocolo.
¿Por qué no usar solo un token en este proceso? Es decir, el usuario autorizaría el token y el consumidor del servicio obtendría información del proveedor con el token .
De la guía oficial de OAuth 1.0
El protocolo OAuth permite a los sitios web o aplicaciones (consumidores) acceder a los recursos protegidos desde un servicio web (proveedor de servicios) a través de una API, sin requerir que los usuarios divulguen sus credenciales de proveedor de servicios a los consumidores. En términos más generales, OAuth crea una metodología genérica y de implementación libre para la autenticación API.
Un ejemplo de caso de uso es permitir el servicio de impresión printer.example.com (el consumidor), para acceder a fotos privadas almacenadas en photos.example.net (el proveedor de servicios) sin requerir que los usuarios proporcionen sus credenciales de photos.example.net a la impresora. Ejemplo .com.
OAuth no requiere una interfaz de usuario específica o patrón de interacción, ni especifica cómo los proveedores de servicios autentican a los usuarios, lo que hace que el protocolo sea ideal para casos en los que las credenciales de autenticación no están disponibles para el consumidor, como con OpenID.
OAuth tiene como objetivo unificar la experiencia y la implementación de la autenticación del servicio web delegado en un único protocolo impulsado por la comunidad. OAuth se basa en los protocolos existentes y las mejores prácticas que han sido implementados de forma independiente por varios sitios web. Un estándar abierto, respaldado por proveedores grandes y pequeños por igual, promueve una experiencia consistente y confiable tanto para los desarrolladores de aplicaciones como para los usuarios de esas aplicaciones.
En resumen, básicamente, el usuario da un nombre de usuario y una contraseña para un token de solicitud de OAuth. Le das el servicio que quiere conectarse a algo usando OAuth el token de solicitud y reciben el token de acceso. Esto hace que el servicio nunca vea / use el nombre de usuario y la contraseña.
Por razones de usabilidad y seguridad.
De la guía para principiantes a OAuth :
https://hueniverse.com/beginners-guide-to-oauth-part-iii-security-architecture-e9394f5263b5
... Aunque principalmente es un artefacto de cómo evolucionó la especificación OAuth, el diseño de dos tokens ofrece algunas características de usabilidad y seguridad que hicieron que valiera la pena permanecer en la especificación. OAuth opera en dos canales: un canal frontal que se utiliza para atraer al usuario y solicitar autorización, y un canal secundario utilizado por el consumidor para interactuar directamente con el proveedor de servicios. Al limitar el token de acceso al canal secundario, el token permanece oculto para el usuario. Esto permite que el token de acceso tenga un significado especial y tenga un tamaño mayor que el token de solicitud del canal frontal que se expone al usuario al solicitar autorización, y en algunos casos debe ingresarse manualmente (dispositivo móvil o decodificador) .
===
Tenga en cuenta que esta pregunta es un engaño de
¿Por qué debemos "cambiar las credenciales temporales para credenciales de tokens" en OAuth?
Si la explicación de la Guía para principiantes no está clara, entonces lea read @ npdoty .