Lo que realmente es 2-legged Oauth

Question

He estado explorando OAuth versión 1.0 para la API REST en la que estoy trabajando actualmente.

tengo 3 escenarios de autenticación

1. se trata de 3 partes, el proveedor de servicios, el consumidor y el usuario. El Oauth de 3 patas coincide con este escenario.
2. participan 2 partes, el consumidor y el proveedor del servicio. ¿Es este un escenario donde Oauth de 2 patas es más aplicable y, en caso afirmativo, cuál es el proceso, ya que apenas existe una diferencia entre esto y la autenticación básica de HTTP en función de mi comprensión.
3. También estoy creando un tipo especial de usuario que siempre puede acceder a los datos del usuario actualmente conectado sin la autorización del usuario. ¿Cómo puede esto encajar en la imagen mientras se sigue implementando OAuth?

¿Estás utilizando esta situación? ¿Cómo puedo implementar Oauth perfectamente y cómo puede ayudarme a comprender los procesos Oauth de 3 patas y 2 patas?

Answer 1

Número 1: Correcto, solo use el típico flujo de Oauth de 3 patas.

Número 2. Oauth de 2 patas es prácticamente lo mismo que http-basic, excepto que la firma Oauth le ofrece protección contra los ataques MITM (pero si usa http-basic sobre TLS, obtiene la misma protección). El proceso para Oauth de 2 patas es solo la firma de la solicitud con la clave/secreto del consumidor, que es sinónimo de un nombre de usuario/contraseña en lugar de http básico.

Número 3. No estoy 100% claro sobre lo que quiere decir aquí, pero suena similar a cómo usa google oauth de 2 patas para los dominios de aplicaciones de Google. Eche un vistazo a su documentación aquí: https://developers.google.com/accounts/docs/OAuth#GoogleAppsOAuth

¿Ha investigado OAuth 2.0? Todavía está en borrador, pero tiene mucha más flexibilidad para diferentes escenarios. Puede ser algo para considerar. http://oauth.net/2/