¿Por qué está diseñado OAuth para tener un token de solicitud y de acceso?

Question

En el protocolo OAuth, un consumidor de servicios le pedirá un usuario para autorizar una solicitud de token en el dominio de proveedor de servicios, entonces intercambia el petición de señal de para 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 utilizar un solo 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.

Answer 1

Por razones de uso y seguridad.

Desde el Beginner’s Guide to OAuth:

https://hueniverse.com/beginners-guide-to-oauth-part-iii-security-architecture-e9394f5263b5

... Mientras que la mayoría de un artefacto de cómo se desarrolló la especificación OAuth, el diseño de dos Token ofrece algunas características de uso y de seguridad lo que hizo 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 en sí 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) .

===

cuenta que esta pregunta es una víctima de

Why must we "change temporary credentials for token credentials" in OAuth?

Si la explicación de la Guía para principiantes no está claro, a continuación, ir a leer @npdoty's take on it.

Answer 2

De The Official OAuth 1.0 Guide

El protocolo OAuth permite a los sitios web o aplicaciones (consumidores) para acceder a Recursos Protegidos de un servicio Web (proveedor de servicios) a través de una API, sin los usuarios tengan que revelar su servicio Credenciales del proveedor al Consumidores. De forma más general, OAuth crea una metodología genérica de implementación libre y para la autenticación API .

un caso de ejemplo el uso está permitiendo la impresión printer.example.com servicio (el Comprador), para acceder a fotos privadas almacenadas en photos.example.net (el proveedor de servicios) sin los usuarios tengan que proporcionar su credenciales de photos.example.net a printer.example.com.

OAuth no requiere un usuario interfaz o interacción patrón específico, ni tampoco especifica cómo los proveedores de servicios autenticar a los usuarios, por lo que el protocolo ideal para casos donde las credenciales de autenticación son disponible para el consumidor, tales como con OpenID.

OAuth pretende unificar la experiencia y implementación de la autenticación del servicio web delegado en un único protocolo de , impulsado por la comunidad. OAuth se basa en los protocolos existentes y las mejores prácticas que han sido implementadas de forma independiente por varios sitios web . Un estándar abierto , admitido por grandes y pequeños proveedores, promueve una experiencia coherente y confiable para ambos desarrolladores de aplicaciones y los usuarios de esas aplicaciones.

En resumen, 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.