¿Cómo protege OAuth 2 contra cosas como los ataques de repetición usando el token de seguridad?

Según tengo entendido, la siguiente cadena de eventos ocurre en OAuth 2 para Site-Aacceder a la información del UsuarioSite-B .

1. Site-Ase registra Site-By obtiene un secreto y una identificación.
2. Cuando usuario le dice Site-Aal acceso Site-B, usuario se envía a Site-Bdonde dicen Site-Bque lo harían de hecho similares para dar Site-Apermisos a información específica.
3. Site-Bredirige al Usuario nuevamente Site-A, junto con un Código de autorización
4. Site-Aluego pasa ese código de autorización junto con su secreto a Site-Bcambio de un token de seguridad.
5. Site-Aluego realiza solicitudes Site-Ben nombre del usuario agrupando el token de seguridad junto con las solicitudes.

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

Cómo funciona OAuth 2.0 en la vida real:

Estaba conduciendo por la panadería de Olaf de camino al trabajo cuando vi la rosquilla más deliciosa en la ventana; quiero decir, la cosa estaba goteando chocolate. Así que entré y exigí "¡Debo tener esa rosquilla!". Él dijo "seguro que serán $ 30".

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

¿Seriamente? Sí, hablaba en serio. Casi me alejé allí mismo, pero luego la dona 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 la rosquilla): "Diles que Olaf te envió". Su nombre ya estaba en la nota, así que no sé cuál era el punto de decir eso, pero está bien.

Conduje una hora y media hasta 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 para darle. Le dije $ 30 dólares. Hizo algunos garabatos y me entregó otra nota. Este tenía un montón de números, supuse que así es como hacen un seguimiento de las notas.

En ese momento me muero de hambre. Me apresuré a salir de allí, una hora y media después estaba de regreso, de pie frente a Olaf con mi nota extendida. Lo tomó, lo miró y dijo: "Volveré".

Pensé que estaba recibiendo mi dona, 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".

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

Debió de tomarme mucho tiempo darme cuenta porque, para cuando levanté la vista, Olaf estaba parado frente a mí y finalmente me entregó mi donut. 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 auto sonó mi teléfono. No me molesté en contestar, probablemente era mi trabajo llamarme para despedirme, mi jefe es un idiota. Además, quedé atrapado pensando en el proceso que acabo de pasar.

Quiero decir, piénselo: pude dejar que Olaf tomara $ 30 de mi cuenta bancaria sin tener que darle la información de mi cuenta. Y no tuve que preocuparme de que sacaría demasiado dinero porque ya le dije al banco que solo se le permitía tomar $ 30. Y el banco sabía que él era el tipo 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 lo dejara tomar $ 30 cada semana, luego podía aparecer en la panadería y ya no tenía que ir al banco. Incluso podría pedir la dona por teléfono si quisiera.

Por supuesto que nunca haría eso, esa rosquilla era asquerosa.

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, tengo que empezar a buscar un nuevo trabajo. Pero no antes de obtener uno de esos batidos de fresa de ese nuevo lugar al otro lado de la ciudad, necesito algo para eliminar el sabor de esa rosquilla.

Según lo que he leído, así es como funciona todo:

El flujo general descrito en la pregunta es correcto. En el paso 2, el usuario X se autentica 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 devuelve su secreto al sitio B, autenticándose a sí mismo, así como el código de autorización, que indica 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 token secreto como el de seguridad son esencialmente contraseñas, y todo está protegido solo por la seguridad de la conexión https.

OAuth 2 no tiene protección contra los ataques de repetición del token de seguridad o el secreto. En cambio, depende completamente de que el Sitio B sea responsable de estos artículos 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 sensible por sí solo. Proporciona un identificador común para el token de acceso del usuario X para el sitio A cuando solicita al sitio B el token de acceso del usuario X. Solo la identificación de usuario del usuario X en el sitio B no habría funcionado, porque podría haber muchos tokens de acceso pendientes a la espera de ser entregados a diferentes sitios al mismo tiempo.

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

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

1. Inicio sesión en LinkedIn y quiero conectar a algunos amigos que están en mis contactos de Gmail. LinkedIn apoya esto. Solicitará un recurso seguro (mi lista de contactos de gmail) de gmail. Entonces hago clic en este botón:
   

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

3. Luego, Gmail muestra una página de consentimiento donde hago clic en "Aceptar":

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

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

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

Paso 2: el servidor de autorización 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 concede la solicitud de LinkedIn para acceder a los datos de Gmail.

Paso 4: el servidor de autorización 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 sus contactos si el token de acceso es válido. (El token será verificado por el servidor de recursos de Gmail)

Puede obtener más información sobre los detalles de OAuth aquí .

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 ---|               |
     +--------+                               +---------------+

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

Esta es una joya:

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

Muy breve resumen:

OAuth define cuatro roles:

1. Dueño del recurso
2. Cliente
3. Servidor de recursos
4. Servidor de autorizaciones

Usted (propietario del recurso) tiene un teléfono móvil. Tiene varias cuentas de correo electrónico diferentes, pero quiere todas sus cuentas de correo electrónico en una sola aplicación, por lo que no necesita seguir cambiando. Por lo tanto, 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 GMail.

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

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

Para elaborar, y específicamente para abordar la pregunta del OP de "¿Cómo protege OAuth 2 contra cosas como los ataques de repetición usando 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 los tokens es un medio de protección contra las siguientes amenazas:

• repetición...

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

Los clientes DEBEN realizar solicitudes autenticadas con un token de portador utilizando el campo de encabezado de solicitud "Autorización" con el esquema de autorización HTTP "Portador". ...

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

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

Esta es quizás la explicación más simple de cómo funciona OAuth2 para los 4 tipos de concesión, es decir, 4 flujos diferentes donde la aplicación puede adquirir el token de acceso.

Semejanza

Todos los flujos de tipo de subvención tienen 2 partes:

• Obtener token de acceso
• Usar token de acceso

La segunda parte 'usar token de acceso' es la misma para todos los flujos

Diferencia

La primera parte del flujo 'obtener token de acceso' para cada tipo de concesión varía.

Sin embargo, en general, la parte 'obtener token de acceso' se puede resumir en 5 pasos:

1. Registre previamente su aplicación (cliente) con el proveedor de OAuth, por ejemplo, Twitter, etc. para obtener la identificación / secreto del cliente
2. Cree un botón de inicio de sesión social con la identificación del cliente y los ámbitos / permisos requeridos en su página para que cuando se haga clic en el usuario se redirija al proveedor de OAuth para que se autentique
3. El proveedor de OAuth solicita al usuario que otorgue permiso a su aplicación (cliente)
4. El proveedor de OAuth emite código
5. La aplicación (cliente) adquiere el token de acceso

Aquí hay un diagrama de lado a lado que compara cómo cada flujo de tipo de concesión es diferente en función de los 5 pasos.

Este diagrama es de https://blog.oauth.io/introduction-oauth2-flow-diagrams/

Cada uno tiene diferentes niveles de dificultad de implementación, seguridad y casos de uso. Dependiendo de sus necesidades y situación, tendrá que usar uno de ellos. ¿Cuál usar?

Credencial del cliente : si su aplicación solo sirve a un único usuario

Crendencial de contraseña del propietario del recurso : Esto debe usarse solo como último recurso ya que el usuario tiene que entregar sus credenciales a la aplicación, lo que significa que la aplicación puede hacer todo lo que el usuario pueda

Código de autorización : la mejor manera de obtener la autorización del usuario

Implícito : si su aplicación es móvil o de una sola página

Aquí hay más explicaciones sobre la elección: https://blog.oauth.io/choose-oauth2-flow-grant-types-for-app/