Pregunta En un alto nivel, ¿cómo funciona OAuth 2?


Según entiendo, la siguiente cadena de eventos ocurre en OAuth 2 para Site-A acceder Usuario información de Site-B.

  1. Site-A registra en Site-B, y obtiene un secreto y una identificación.
  2. Cuando Usuario dice Site-A acceder Site-B, Usuario es enviado a Site-B donde él dice Site-B que de hecho le gustaría dar Site-A permisos a información específica.
  3. Site-B redirige Usuario de regreso Site-A, junto con un Código de Autorización.
  4. Site-A luego pasa ese código de autorización junto con su secreto de vuelta a Site-B a cambio de un token de seguridad.
  5. Site-A luego hace solicitudes a Site-B a nombre de Usuario al agrupar el token de seguridad junto con las solicitudes.

¿Cómo funciona todo esto en términos de seguridad y encriptación, en un alto nivel? ¿Cómo protege OAuth 2 contra elementos como los ataques de reproducción con el token de seguridad?


506
2018-01-18 17:44


origen


Respuestas:


Cómo funciona OAuth 2.0 en la vida real:

Estaba conduciendo junto a la panadería de Olaf en mi camino al trabajo cuando vi la rosquilla más deliciosa en la ventana. Es decir, la cosa estaba goteando chocolate. Entonces entré y exigí "¡Debo tener ese donut!". Él dijo "seguro que será $ 30".

Sí, lo sé, ¡$ 30 por una dona! Debe ser delicioso! Busqué mi billetera cuando de repente escuché al chef gritar "NO! No donut para ti". ¿Pregunté por qué? Dijo que solo acepta transferencias bancarias.

¿Seriamente? Sí, hablaba en serio. Casi me alejé allí, pero luego el donut me llamó: "Cómeme, estoy delicioso ...". ¿Quién soy yo para desobedecer las órdenes de un donut? Dije ok.

Me entregó una nota con su nombre (el chef, no el donut): "Diles que Olaf te envió". Su nombre ya estaba en la nota, así que no sé de qué iba a decir que era, pero está bien.

Conduje una hora y media a mi banco. Le entregué la nota al cajero; Le dije que Olaf me envió. Ella me dio una de esas miradas, del tipo que dice: "Puedo leer".

Ella tomó mi nota, pidió mi identificación, me preguntó cuánto dinero estaba bien darle. Le dije $ 30 dólares. Hizo algunos garabatos y me dio otra nota. Este tenía un montón de números, supuse que así es como hacen un seguimiento de las notas.

En ese punto me muero de hambre. Me apresuré a salir de allí, una hora y media más tarde estaba de vuelta, parado frente a Olaf con mi nota extendida. Lo tomó, lo miró y dijo: "Volveré".

Pensé que estaba recibiendo mi donut, pero después de 30 minutos comencé a sospechar. Entonces le pregunté al tipo detrás del mostrador "¿Dónde está Olaf?". Él dijo: "Fue a buscar dinero". "¿Qué quieres decir?". "Toma nota al banco".

Eh ... entonces Olaf tomó la nota que el banco me dio y volvió al banco para sacar dinero de mi cuenta. Como él tenía la nota que el banco me dio, el banco sabía que él era el tipo del que estaba hablando, y como hablé con el banco, ellos sabían que solo le daría $ 30.

Me debe haber llevado mucho tiempo darme cuenta de eso porque cuando levanté la vista, Olaf estaba frente a mí finalmente entregándome mi dona. Antes de irme, tuve que preguntar: "Olaf, ¿siempre vendiste rosquillas de esta manera?". "No, solía hacerlo diferente".

Huh. Mientras caminaba de regreso a mi automóvil, mi teléfono sonó. No me molesté en responder, probablemente fue mi trabajo llamarme para despedirme, mi jefe es un maldito. Además, me quedé atrapada pensando en el proceso que acabo de pasar.

Quiero decir, piénselo: pude dejar que Olaf sacara $ 30 de mi cuenta bancaria sin tener que darle la información de mi cuenta. Y no tuve que preocuparme de que sacara demasiado dinero porque ya le dije al banco que solo podía recibir $ 30. Y el banco sabía que era el hombre correcto porque tenía la nota que me dieron para darle a Olaf.

Ok, seguro que preferiría entregarle $ 30 de mi bolsillo. Pero ahora que tenía esa nota, podía decirle al banco que le permitiera tomar $ 30 cada semana, y luego podía aparecer en la panadería y ya no tenía que ir al banco. Incluso podría pedir el donut por teléfono si quisiera.

Por supuesto que nunca haría eso, esa dona era desagradable.

Me pregunto si este enfoque tiene aplicaciones más amplias. Mencionó que este era su segundo enfoque, podría llamarlo Olaf 2.0. De todos modos, es mejor que llegue a casa, debo comenzar a buscar un nuevo trabajo. Pero no antes de obtener uno de esos batidos de fresa de ese nuevo lugar del otro lado de la ciudad, necesito algo para lavar el sabor de ese donut.


1269
2017-09-12 01:26



En base a lo que he leído, así es como funciona todo:

El flujo general delineado en la pregunta es correcto. En el paso 2, el usuario X está autenticado y también autoriza el acceso del sitio A a la información del usuario X en el sitio B. En el paso 4, el sitio pasa su secreto al sitio B, autenticándose, así como el código de autorización, indicando qué está pidiendo (token de acceso del Usuario X).

En general, OAuth 2 en realidad es un modelo de seguridad muy simple, y el cifrado nunca entra directamente en juego. En cambio, tanto el secreto como el token de seguridad son esencialmente contraseñas, y todo está asegurado solo por la seguridad de la conexión https.

OAuth 2 no tiene protección contra los ataques de repetición de la ficha de seguridad o el secreto. En su lugar, depende completamente de que el Sitio B sea responsable de estos elementos y no los deje salir, y de que se envíen a través de https mientras están en tránsito (https protegerá los parámetros de URL).

El propósito del paso del Código de autorización es simplemente la conveniencia, y el Código de autorización no es especialmente delicado por sí mismo. Proporciona un identificador común para el token de acceso del usuario X para el sitio A cuando se solicita al sitio B el token de acceso del usuario X. Solo el ID de usuario de User X en el Sitio B no habría funcionado, ya que podría haber muchos tokens de acceso pendientes esperando ser entregados en diferentes sitios al mismo tiempo.


121
2018-02-09 22:34



OAuth es un protocolo con el que una aplicación de 3 partes puede acceder a sus datos almacenados en otro sitio web sin su cuenta y contraseña. Para una definición más oficial, consulte la Wiki o especificación.

Aquí hay una demostración de caso de uso:

  1. Me conecto a LinkedIn y quiero conectarme con algunos amigos que están en mis contactos de Gmail. LinkedIn lo admite, así que hago clic en este botón:
    Add Connection

  2. Aparece una página web y muestra la página de inicio de sesión de Gmail, cuando ingreso mi cuenta y mi contraseña:
    Add Connection

  3. Gmail luego muestra una página de consentimiento donde hago clic en "Aceptar": Add Connection

  4. Ahora LinkedIn puede acceder a mis contactos en Gmail: Add Connection

A continuación se muestra un diagrama de flujo del ejemplo anterior:

Add Connection

Paso 1: LinkedIn solicita un token del Servidor de autorización de Gmail.

Paso 2: el servidor de autorizaciones de Gmail autentica al propietario del recurso y muestra al usuario la página de consentimiento. (el usuario debe iniciar sesión en Gmail si aún no ha iniciado sesión)

Paso 3: el usuario otorga la solicitud a LinkedIn para acceder a los datos de Gmail.

Paso 4: el servidor de autorizaciones de Gmail responde con un token de acceso.

Paso 5: LinkedIn llama a la API de Gmail con este token de acceso.

Paso 6: El servidor de recursos de Gmail devuelve tus contactos si el token de acceso es válido. (El token será verificado por el servidor de recursos de Gmail)

Puedes obtener más de los detalles sobre OAuth aquí.


86
2017-10-09 07:38



La figura 1, levantada de RFC6750:

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

20
2017-08-03 22:04



Así es como funciona Oauth 2.0, bien explicado en Este artículo

enter image description here


10
2018-05-10 18:28



Esta es una joya:

https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2

Resumen muy breve:

OAuth define cuatro roles:

  1. Propietario del recurso
  2. Cliente
  3. Servidor de recursos
  4. Servidor de autorización

Usted (propietario del recurso) tiene un teléfono móvil. Tiene varias cuentas de correo electrónico diferentes, pero desea todas sus cuentas de correo electrónico en una aplicación, por lo que no necesita seguir cambiando. Entonces, su GMail (Cliente) solicita acceso (a través del Servidor de autorización de Yahoo) a sus correos electrónicos de Yahoo (Servidor de recursos) para que pueda leer ambos correos electrónicos en su aplicación de GMail.

La razón por la que OAuth existe es porque no es seguro que GMail almacene su nombre de usuario y contraseña de Yahoo.

enter image description here


7
2018-06-10 21:22



La otra respuesta es muy detallada y aborda la mayor parte de las preguntas planteadas por el PO.

Para elaborar, y específicamente para abordar la pregunta del OP de "¿Cómo protege OAuth 2 contra cosas como los ataques de reproducción con el token de seguridad?", Hay dos protecciones adicionales en las recomendaciones oficiales para implementar OAuth 2:

1) Los tokens generalmente tendrán un período de vencimiento corto (http://tools.ietf.org/html/rfc6819#section-5.1.5.3)

Un tiempo de vencimiento corto para tokens es un medio de protección contra   las siguientes amenazas:

  • repetición...

2) Cuando el sitio A utiliza el token, la recomendación es que se presente no como parámetros de URL, sino en el campo del encabezado de solicitud de autorización (http://tools.ietf.org/html/rfc6750)

Los clientes DEBERÍAN realizar solicitudes autenticadas con un token de portador usando   el campo de encabezado de solicitud "Autorización" con el HTTP "Portador"   esquema de autorización.   ...

El método "application / x-www-form-urlencoded" NO DEBE utilizarse   excepto en contextos de aplicación donde los navegadores participantes no   tener acceso al campo de encabezado de solicitud "Autorización".   ...

El parámetro URI Query ... se incluye para documentar el uso actual; su uso no es   recomendado, debido a sus deficiencias de seguridad


6
2018-04-24 14:26