oauth-2.0 2-legged

¿Cómo funciona Oaut 2-legged en OAuth 2.0?



oauth-2.0 (2)

Después de mucha investigación, descubrí que client_credentials tipo de concesión client_credentials es para este escenario. Una vez que ingresas este término en google, puedes encontrar montones de recursos muy útiles.

Este es el flujo normal para OAuth 2.0 de 3 patas (queremos que el usuario inicie sesión):

Supongamos que tenemos los siguientes puntos finales en nuestra aplicación para autenticación:

/oauth/auth /oauth/token

Normalmente (para concesión de código de autorización), dirigimos al usuario a /oauth/auth?state=blah&client_id=myid&redirecturl=mysite.com/blah

Luego, luego de la autenticación, el usuario es redirigido a mysite.com/blah?code=somecode

Luego obtenemos somecode y lo somecode por un token usando /oauth/token?code=somecode&client_id=myid&client_secret=mysecret

Entonces podemos usar el token para hacer llamadas.

Este es el flujo de aplicaciones para client_credentials para implementar OAuth 2.0 de 2 patas, que es notablemente más simple:

  • En este enfoque, no necesitamos realizar ninguna autenticación.

  • Simplemente POST /oauth/token to /oauth/token con los siguientes datos de formulario:

    grant_type=client_credentials&scope=view_friends

Tenga en cuenta que el alcance es opcional. El punto final devuelve directamente un token de acceso para que lo usemos (no se proporciona token de actualización). Como no se proporciona un token de actualización, cuando el token caduque, tendrá que volver a autenticarse y solicitar uno nuevo.

Esto lleva a las siguientes advertencias:

  • Úselo solo para aplicaciones (muy, muy) confiables, como aplicaciones internas.
  • Necesita dispositivo a su manera para autenticarse. Por ejemplo, el ejemplo de RFC usa autenticación básica.

Otra solución es usar JWT (tokens web JSON) como la API de Google OAuth . Es un proceso muy complicado, pero existen numerosas bibliotecas para generar su JWT. A continuación, publica los siguientes datos del formulario (url codificado por supuesto):

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=generated_jwt

Esto se publica en /oauth/token para obtener tu token.

En cuanto a la pregunta de si puede crear una API que admita OAuth 2.0 de 2 patas y 3 patas , sí, es posible .

Entonces /auth endpoint solo se usa cuando los usuarios necesitan autenticarse contra el servicio.

En el punto final /token , simplemente verifique el valor de grant_type en los parámetros GET para urn:ietf:params:oauth:grant-type:jwt-bearer si usa JWT o client_credentials para client_credentials.

Tenga en cuenta que al generar client_id y client_secret para otorgar al usuario, si admite varios grant_types , asegúrese de tener una columna de base de datos para almacenar el tipo de tipo de concesión para el que se generó el id. Y el secreto. Si se requiere tener múltiples tipos de subvención por usuario, genere un conjunto diferente de credenciales para cada tipo de subvención.

En OAuth 1.0, 2-legged es bastante fácil: simplemente envíe la solicitud como de costumbre y omita el encabezado access_token .

Las cosas parecen haber cambiado en OAuth 2.0 (drásticamente, como descubrí hoy :)). En OAuth 2.0, la solicitud ya no tiene encabezados, como el nonce, la clave del consumidor, la marca de tiempo, etc. Esto simplemente se reemplazó por:

Authorization: OAuth ya29.4fgasdfafasdfdsaf3waffghfhfgh

Entiendo cómo funcionan las autorizaciones de 3 patas en OAuth 2.0 y la aplicación fluye. ¿Pero cómo funciona 2 patas en 2.0? ¿Es posible diseñar una API que pueda admitir OAuth 2.0 de 2 patas y 3 patas?

He estado buscando información con respecto a esto, pero he encontrado muchas cosas en 2 patas para 1.0 y casi nada para 2.0.

También puede consultar la implementación de Google de OAuth2 de 2 patas (creo que esta documentación se ha publicado recientemente).

Los developers.google.com/drive/delegation también deberían ayudar a comprender la implementación OAuth2 de dos patas de Google.