funciona estandar como oauth-2.0

oauth-2.0 - estandar - oauth2 token



En un nivel alto, ¿cómo funciona OAuth 2? (8)

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

Como lo entiendo, la siguiente cadena de eventos ocurre en OAuth 2 para que el Site-A acceda a la información del Usuario desde el Site-B .

  1. Site-A registra en el Site-B y obtiene un Secreto y una ID.
  2. Cuando el Usuario le dice al Site-A que acceda al Site-B , el Usuario se envía al Site-B donde le dice al Site-B que le gustaría otorgar permisos de Site-A a información específica.
  3. Site-B redirige al usuario de nuevo al 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 al Site-B a cambio de un token de seguridad.
  5. Site-A luego realiza solicitudes al Site-B en nombre del usuario al agrupar el token de seguridad junto con las solicitudes.

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

Basado en lo que he leído, así es como funciona:

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, 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 Secreto como el token 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 su lugar, depende completamente de que el Sitio B sea responsable con estos elementos y no permita que salgan, 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 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 se solicita el token de acceso del Usuario B al Sitio B. La identificación de usuario de Just User X en el sitio B no habría funcionado, ya que podría haber muchos tokens de acceso pendientes a la espera de ser entregados a diferentes sitios al mismo tiempo.

Cómo funciona OAuth 2.0 en la vida real:

Estaba conduciendo por la panadería de Olaf en mi camino al trabajo cuando vi el donut más delicioso en la ventana. Quiero decir, la cosa estaba goteando bondad a chocolate. Así que entré y exigí "¡Debo tener esa dona!". Dijo que "seguro que serán $ 30".

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

¿Seriamente? Sí, él era serio. Casi me alejé justo allí, pero luego el donut me gritó: "Cómeme, estoy delicioso ...". ¿Quién soy yo para desobedecer las órdenes de una dona? Dije ok.

Me entregó una nota con su nombre (el chef, no la dona): "Dígales que Olaf le envió". Su nombre ya estaba en la nota, así que no sé qué sentido tenía decir eso, pero está bien.

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

Tomó mi nota, me pidió mi identificación, me preguntó cuánto dinero estaba bien para darle. Le dije $ 30 dólares. Ella 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 momento me muero de hambre. Salí corriendo de allí, una hora y media después estaba de vuelta, parado frente a Olaf con mi nota extendida. Lo tomó, lo miró y dijo: "Volveré".

Pensé que estaba recibiendo mi rosquilla, pero después de 30 minutos comencé a sospechar. Así que le pregunté al chico detrás del mostrador "¿Dónde está Olaf?". Dijo "Se fue a conseguir dinero". "¿Qué quieres decir?". "Toma nota al banco".

Huh ... entonces Olaf tomó la nota que el banco me dio y regresó al banco para sacar dinero de mi cuenta. Desde que tenía la nota que me dio el banco, el banco sabía que él era el tipo del que estaba hablando, y porque hablé con el banco, ellos solo le dieron $ 30.

Debe haberme tomado mucho tiempo darme cuenta de eso porque cuando levanté la vista, Olaf estaba parado frente a mí, finalmente me entregó mi donut. Antes de irme, tuve que preguntar: "Olaf, ¿siempre vendías donas de esta manera?". "No, solía hacerlo diferente".

Huh Mientras caminaba de regreso a mi auto, sonó mi teléfono. No me molesté en responder, probablemente mi trabajo era llamarme para despedirme, mi jefe es una mierda. Además, estaba atrapado pensando en el proceso que acababa 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 tenía que preocuparme de que sacara demasiado dinero porque ya le dije al banco que solo podía tomar $ 30. Y el banco sabía que era el hombre adecuado porque tenía la nota que me dieron para entregar a Olaf.

Ok, seguro que preferiría darle $ 30 de mi bolsillo. Pero ahora que tenía esa nota, podía decirle al banco que le permitiera tomar $ 30 cada semana, luego podrí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, será mejor que llegue a casa, tengo que empezar a buscar un nuevo trabajo. Pero no antes de que reciba uno de esos batidos de fresa de ese nuevo lugar del otro lado de la ciudad, necesito algo para eliminar el sabor de esa dona.

Esta es quizás la explicación más sencilla 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 el token de acceso'' para cada tipo de concesión varía.

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

  1. Registre previamente su aplicación (cliente) con el proveedor de OAuth, por ejemplo, Twitter, etc. para obtener el ID / 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 el usuario que haga clic se redirija al proveedor de OAuth se autentique
  3. El proveedor de OAuth solicita al usuario que otorgue permiso a su aplicación (cliente)
  4. El proveedor de OAuth emite el código
  5. La aplicación (cliente) adquiere el token de acceso

Aquí hay un diagrama en paralelo que compara cómo cada flujo de tipo de concesión es diferente según 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 solo usuario

Clave de la contraseña del propietario del recurso : se debe usar solo como último recurso, ya que el usuario debe entregar sus credenciales a la aplicación, lo que significa que la aplicación puede hacer todo lo que el usuario puede hacer.

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.

Hay una explicación más detallada de la opción aquí: https://blog.oauth.io/choose-oauth2-flow-grant-types-for-app/

Esta es una joya:

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

Muy breve resumen:

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 tener 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 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.

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

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 con el token de seguridad?", Existen dos protecciones adicionales en las recomendaciones oficiales para implementar OAuth 2:

1) Por lo general, los tokens tendrán un período de caducidad corto ( http://tools.ietf.org/html/rfc6819#section-5.1.5.3 ):

Un breve tiempo de caducidad 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 no se presente 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 usarse, excepto en los contextos de aplicación donde los navegadores participantes no tienen acceso al campo de encabezado de solicitud de "Autorización". ...

URI Query Parameter ... se incluye para documentar el uso actual; No se recomienda su uso, debido a sus deficiencias de seguridad.

OAuth es un protocolo con el que una aplicación de 3 usuarios 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 del caso de uso:

  1. Me conecto a 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. Así que hago clic en este botón:

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

  3. 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 le muestra al usuario la página de consentimiento. (el usuario debe iniciar sesión en Gmail si aún no lo ha hecho)

Paso 3: el usuario otorga la solicitud para que LinkedIn acceda 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 de los detalles sobre OAuth here .