¿Por qué está diseñado OAuth para tener token de solicitud y token de acceso?
En el protocolo OAuth, un consumidor de servicios le pedirá a un usuario que autorice un token de solicitud en el dominio del proveedor de servicios, luego intercambia el token de solicitud por un token de acceso del proveedor de servicios.
Me pregunto por qué OAuth está diseñado para tener dos tokens en el protocolo.
¿Por qué no usar un solo token en este proceso? Es decir, el usuario autorizaría el token , y el consumidor del servicio recuperaría información del proveedor con el token.
2 answers
Por razones de usabilidad y seguridad.
De la Guía para principiantes de OAuth:
Https://hueniverse.com/beginners-guide-to-oauth-part-iii-security-architecture-e9394f5263b5
... Aunque en su mayoría 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: a front-channel que se utiliza para involucrar al Usuario y solicitar autorización, y un back-channel utilizado por el Consumidor para interactuar directamente con el Proveedor de Servicios. Al limitar el Token de Acceso al canal posterior, el Token en sí permanece oculto al Usuario. Esto permite que el Token de Acceso tenga significados especiales y tenga un tamaño más grande 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 una copia de
¿Por qué debemos "cambiar credenciales temporales por credenciales de token" en OAuth?
Si la explicación de la Guía para Principiantes no está clara, entonces ve a leer la versión de@npdoty .
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
2017-10-12 11:44:02
De La Guía Oficial de OAuth 1.0
El protocolo OAuth habilita sitios web o solicitudes (Consumidores) de acceso Recursos protegidos de un servicio web (Proveedor de servicios) a través de una API, sin exigir a los Usuarios que revelen sus Credenciales del Proveedor de servicios a la Consumidor. Más generalmente, OAuth crea un sistema de metodología genérica para API autenticación.
Un caso de uso de ejemplo está permitiendo servicio de impresión printer.example.com (el Consumidor), al acceso privado las fotos almacenadas en photos.example.net (el Proveedor de Servicios) sin requerir a los Usuarios que proporcionen sus photos.example.net credenciales para printer.example.com.
OAuth no requiere un usuario específico interfaz o patrón de interacción, ni ¿especifica cómo los Proveedores de Servicios authenticate Users, making the protocolo ideal para casos dónde están las credenciales de autenticación no disponible para el Consumidor, tales como con OpenID.
OAuth tiene como objetivo unificar la experiencia y implementación de web delegada autenticación de servicio en un solo, protocolo impulsado por la comunidad. OAuth se basa en los protocolos existentes y mejor prácticas que han sido independientes implementado por varios sitios web. Un estándar abierto, apoyado por grandes y pequeños proveedores por igual, promueve un experiencia consistente y confiable para tanto los desarrolladores de aplicaciones como el usuarios de esos aplicación.
Para resumir lo que dicho básicamente el usuario da un nombre de usuario y contraseña para un token de solicitud OAuth. Le das al 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.
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
2010-09-01 01:53:25