Continuando con la explicación de ayer sobre OAuth hoy vemos la diferencia entre los 2 modelos de comunicación OAuth: 3-legged y 2-legged OAuth.

La comunicación típica OAuth es la

3-legged OAuth:

El flujo importante (no está la parte en la que el Consumer obtiene su consumer key y consumer secret):

6.1 El Consumer (aplicación que quiere accede a los datos del User) crea una session OAuth session obteniendo un request token unauthorized del Service Provider (el host del dato)

6.2 El Consumer redirecciona al usuario al Service Provider con el request token unauthorized para que el Service Provider pueda preguntar al usuario que de acceso a los datos protegidos al Consumer. El User se logea en el Service Provider y da el permiso. El Serice Provider redirecciona al User de vuelta al Consumer.

6.3 El mismo token que el Consumer mantenía ahora está authorized. El Consumer lo envía al Service Provider en una petición directa para intercambiarlo por un Access token.

2-legged OAuth

Este tipo de autorización se usa normalmente para casos en los que el Consumer está instalado en la máquina del User o para Widgets embebidos en una página o para comunicar entre Servicios.

La diferencia fundamental es que el Consumer no requiere acceso a ningún dato del User y simplemente quiere establecer una conexión con el ServiceProvider sin datos previos. En este escenario el Consumer tiene su propio espacio en el Service Provider, por lo que el Consumer puede obtener datos directamente del User y enviarlos al Service Provider. Por tanto no es necesario que el Service Provider tenga autorización del usuario, y la segunda de las 2 patas puede saltarse quedando el flujo así:

La interacción 6.2 de antes no existe.

La interacción 6.1 es algo diferente, en lugar de que el Service Provider devuelva al Consumer un unauthorized request token el token es pre-authorized. El Consumer puede inmediatamente intercambiarlo por un Access token.

Una vez entendido seguro que os preguntáis lo mismo que yo…para que se pide un Request Token preauthorizado y luego un Access Token, ¿por qué no diretamente un Access Token?…la respuesta es evidente, si no fuese de esta forma no sería OAuth.

Uso de OAuth por Twitter

Twitter “adapta” el uso de OAuth saltándose por completo el flujo, en Twitter el User navega a Twitter, obtiene directamente su Access Token (sin paso previo de Request Token), copia el Access Token en la aplicación Consumer y voilá, el Consumer ya tiene acceso a los datos del usuario sin ningún –legged flow.

Fuente original