Flujo de trabajo de OAuth 2.0

OAuth2.0 es un protocolo de autorización estándar de la industria abierta que permite que un tercero obtenga acceso limitado a otro servicio HTTP, como Google, Facebook y GitHub, en nombre de un usuario, una vez que el usuario otorga permiso para acceder a sus credenciales. 

La mayoría de los sitios web requieren que complete un proceso de registro antes de poder acceder a su contenido. Es probable que te hayas topado con algunos botones para iniciar sesión con Google, Facebook u otro servicio.

Al hacer clic en esos botones, obtendrá acceso a estos servicios de terceros sin ingresar ninguna credencial. Estoy seguro de que te estás preguntando cómo sucede esto. OAuth saca esto a la luz.

Hagamos un repaso rápido sobre Autenticación y Autorización antes de sumergirnos en OAuth. La autorización se refiere al proceso mediante el cual un administrador otorga acceso a usuarios autenticados, mientras que la autenticación verifica que el usuario es quien dice ser.

Considere el sitio web G eeksforGeeks como ejemplo.

Como lector, puede leer blogs sin autenticarse, pero para agregar comentarios, debe registrarse. Una vez que te hayas registrado, podrás acceder a los cursos gratuitos, mejorar artículos y contribuir. Como colaborador, tiene derecho a editar sus artículos.

Hablemos ahora de OAuth.

OAuth es un marco de autorización de estándar abierto que permite que las aplicaciones de terceros obtengan acceso limitado a los datos del usuario .

Esencialmente , OAuth se trata de acceso delegado.

La delegación es un proceso en el que un propietario autoriza a un proveedor de servicios a realizar ciertas tareas en nombre del propietario. Aquí la tarea es proporcionar acceso limitado a otra parte.

Tomemos dos ejemplos de la vida real;

Los dueños de casa a menudo se acercan a los agentes inmobiliarios para vender su casa. El dueño de la casa autoriza al agente inmobiliario entregándole la llave. Con el consentimiento del propietario, los agentes muestran la propiedad a los compradores. El comprador puede ver la propiedad, pero no puede ocuparla. En este escenario, el comprador tiene acceso limitado y el acceso está limitado por el agente inmobiliario que actúa en nombre del propietario.

A menudo se vuelve a contar un ejemplo clásico de aparcacoches para comprender este concepto. En este caso, el propietario del automóvil tiene acceso tanto al automóvil como al valet. Para que le estacionen su automóvil, el dueño del automóvil le da la llave del valet al asistente. La llave de valet enciende el automóvil y abre la puerta del lado del conductor, pero evita que el valet acceda a los objetos de valor en el maletero o la guantera.

Así, la llave Valet tiene delegada la tarea de limitar el acceso del valet.

¿Cuál es el punto de OAuth?

OAuth permite niveles de acceso granulares . En lugar de confiar todos nuestros datos protegidos a un tercero, preferiríamos compartir solo los datos necesarios con ellos. Por lo tanto, necesitamos un intermediario confiable que otorgue acceso limitado (conocido como alcance) al editor sin revelar las credenciales del usuario una vez que el usuario haya otorgado el permiso (conocido como consentimiento).

Aquí hay un ejemplo de una aplicación para editar fotos.

Vas a una aplicación de edición de fotos para cambiar el tamaño de una imagen. Te piden que subas la imagen que quieres editar desde tu cuenta de Google Drive. El tercero solo necesita acceso a la única foto que necesita editar. Oauth se asegurará de que el editor de fotos obtenga exactamente eso.

Tomemos otro ejemplo, le gustaría compartir su imagen editada con su amigo, pero deben tener el mismo software de edición. El software de edición no puede solicitar las credenciales de su cuenta de Google; en cambio, lo redirige a su cuenta. Si elige invitar a su amigo a través de esa aplicación, la aplicación solicitará acceso a su libreta de direcciones de Google para enviar la invitación.

• Solo lectura/escritura: un tercero solo puede leer sus datos, no modificarlos. En algunos casos, también puede solicitar modificaciones de contenido en su cuenta. Por ejemplo, puede publicar una imagen de su cuenta de Instagram en su cuenta de Facebook.
• Revocar acceso: puede desautorizar el acceso de Instagram a su muro de Facebook para que ya no pueda publicar en su muro.

Antes de entrar en cómo funciona OAuth, analizaremos los componentes centrales de OAuth para mayor claridad.

Los elementos de OAuth se enumeran a continuación:

1. Actores
2. Alcances y Consentimiento
3. fichas
4. Flujos

Actores:

 Las interacciones de OAuth tienen los siguientes actores:

• Los recursos son datos protegidos que requieren OAuth para acceder a ellos.
• Propietario del recurso : posee los datos en el servidor de recursos. Una entidad capaz de otorgar acceso a datos protegidos. Por ejemplo, una cuenta de usuario de Google Drive.
• Servidor de recursos : la API que almacena los datos. Por ejemplo, Google Fotos o Google Drive.
• Cliente : Es una aplicación de terceros que quiere acceder a tus datos, por ejemplo, una aplicación de edición de fotos.

Parece haber una interacción entre dos servicios para acceder a los recursos, pero el problema es quién es responsable de la seguridad. El servidor de recursos, en este caso Google Drive, es el encargado de garantizar la autenticación requerida.

OAuth está acoplado con el servidor de recursos . Google implementa OAuth para validar la autorización de quien accede al recurso.

• Servidor de autorización : el motor principal de OAuth que crea tokens de acceso.

Alcance y Consentimiento:

Los ámbitos definen las acciones específicas que las aplicaciones pueden realizar en nombre del usuario. Son los paquetes de permisos que solicita el cliente al solicitar un token.

Por ejemplo, podemos compartir nuestras publicaciones de LinkedIn en Twitter a través del propio LinkedIn. Dado que tiene acceso de solo escritura, no puede acceder a otros datos, como nuestras conversaciones.

En la pantalla de Consentimiento, un usuario sabe quién está intentando acceder a sus datos y a qué tipo de datos quiere acceder, y el usuario debe expresar su consentimiento para permitir el acceso de terceros a los datos solicitados. Usted otorga acceso a su IDE, como CodingSandbox, cuando vincula su cuenta de GitHub o importa un repositorio existente. La cuenta de Github que está utilizando le enviará un correo electrónico para confirmarlo.

Ahora hablemos sobre los tokens de acceso y actualización. 

¿Qué es una ficha?

Un token es un dato que contiene la información suficiente para poder verificar la identidad de un usuario o autorizarlo a realizar una determinada acción.

Podemos comprender los tokens de acceso y los tokens de actualización utilizando la analogía de las salas de cine. Supongamos que usted (propietario del recurso) quisiera ver la última película de Marvel (Shang Chi y las Leyendas de los Diez Anillos), iría al proveedor de boletos (servidor de autenticación), elegiría la película y compraría el boleto (token) para esa película (alcance). La validez de la entrada ahora se refiere solo a un período de tiempo determinado y a un espectáculo específico. Después de que el tipo de seguridad revise su boleto, lo deja entrar al teatro (servidor de recursos) y lo dirige a su asiento asignado.

Si le das tu entrada a un amigo, puede usarla para ver la película. Un token de acceso OAuth funciona de la misma manera. Cualquiera que tenga el token de acceso puede usarlo para realizar requests de API. Por lo tanto, se denominan “fichas portadoras”. No encontrará su información personal en el billete. Del mismo modo, los tokens de acceso de OAuth se pueden crear sin incluir información sobre el usuario para el que se emitieron. Al igual que una entrada de cine, un token de acceso OAuth es válido durante un período determinado y luego caduca. El personal de seguridad generalmente solicita una prueba de identificación para verificar su edad, especialmente para películas con clasificación A. Las reservas realizadas en línea serán autenticadas por la aplicación antes de que se le proporcionen los boletos.

Entonces, los tokens de acceso son credenciales que se utilizan para acceder a recursos protegidos . Cada token representa el alcance y la duración del acceso otorgado por el propietario del recurso y aplicado por el servidor de autorización. El formato, la estructura y el método de utilizar tokens de acceso pueden ser diferentes según las necesidades de seguridad del servidor de recursos.

Un token de acceso decodificado, que sigue un formato JWT. 

{ "iss": "https://YOUR_DOMAIN/",
 "sub": "auth0|123456",
  "aud": [   "my-api-identifier",   "https://YOUR_DOMAIN/userinfo" ],
  "azp": "YOUR_CLIENT_ID", "exp": 1474178924, "iat": 1474173924,
  "scope": "openid profile email address phone read:meetings" }    

 Ahora que su tiempo de presentación ha expirado y desea ver otra película, necesita comprar un nuevo boleto. En su última compra, recibió una tarjeta de regalo válida por tres meses. Puede utilizar esta tarjeta para comprar un nuevo billete. En este escenario, la tarjeta de regalo es análoga a Refresh Tokens . Un token de actualización es una string emitida al cliente por el servidor de autorización y se usa para obtener un nuevo token de acceso cuando el token de acceso actual deja de ser válido.

No actualizan un token de acceso existente, simplemente solicitan uno nuevo. El tiempo de caducidad de los tokens de actualización tiende a ser mucho más largo que el de los tokens de acceso. En nuestro caso, la tarjeta regalo tiene una validez de tres meses, mientras que el billete tiene una validez de dos horas. A diferencia del token de acceso original, contiene menos información.

Veamos ahora cómo funciona OAuth al cargar una imagen en un editor de fotos para comprender el flujo de trabajo.

1. El propietario o usuario del recurso desea cambiar el tamaño de la imagen, por lo que se dirige al editor (cliente), le dice al cliente que la imagen está en Google Drive (propietario del recurso), y le pide al cliente que la traiga para editarla.
2. El cliente envía una solicitud al servidor de autorización para acceder a la imagen. El servidor le pide al usuario que otorgue permisos para el mismo.
3. Una vez que el usuario permite el acceso de terceros e inicia sesión en el sitio web con Google, el servidor de autorización envía un código de autorización de corta duración al cliente.
4. Los clientes intercambian códigos de autenticación por tokens de acceso, que definen el alcance y la duración del acceso del usuario.
5. El servidor de autorización valida el token de acceso y el editor obtiene la imagen que el usuario desea editar desde su cuenta de Google Drive.

Una descripción general del flujo de trabajo de OAuth

1. Flujo de código de autorización:

1. El cliente solicita autorización dirigiendo al propietario del recurso al servidor de autorización.
2. El servidor de autorización autentica al propietario del recurso e informa al usuario sobre el cliente y los datos solicitados por el cliente. Los clientes no pueden acceder a las credenciales de usuario ya que el servidor de autenticación realiza la autenticación.
3. Una vez que el usuario otorga permiso para acceder a los datos protegidos, el servidor de autorización redirige al usuario al cliente con el código de autorización temporal.
4. El cliente solicita un token de acceso a cambio del código de autorización.
5.  El servidor de autorización autentica al cliente, verifica el código y emite un token de acceso al cliente.
6. Ahora el cliente puede acceder a los recursos protegidos presentando el token de acceso al servidor de recursos.
7. Si el token de acceso es válido, el servidor de recursos devuelve los recursos solicitados al cliente.

2. Flujo implícito:

El flujo de concesión implícita es un flujo de autorización para aplicaciones basadas en navegador. El tipo de concesión implícita se diseñó para aplicaciones de JavaScript de una sola página para obtener tokens de acceso sin un paso de intercambio de código intermedio. Las aplicaciones de una sola página son aquellas en las que la página no se recarga y los contenidos requeridos se cargan dinámicamente. Tome Facebook o Instagram, por ejemplo. Instagram no requiere que vuelvas a cargar tu aplicación para ver los comentarios en tu publicación. Las actualizaciones se producen sin recargar la página. Por lo tanto, el flujo de subvenciones implícito es aplicable en tales aplicaciones.

El flujo implícito emite un token de acceso directamente al cliente en lugar de emitir un código de autorización.

La concesión implícita:

• Construye un enlace y la redirección del navegador del usuario a esa URL.

https://example-app.com/redirect  #access_token=g0ZGZmPj4nOWIlTTk3Pw1Tk4ZTKyZGI3  &token_type=Bearer  &expires_in=400  &state=xcoVv98y3kd55vuzwwe3kcq    

• Si el usuario acepta la solicitud, el servidor de autorización devolverá el navegador a la URL de redirección proporcionada por la aplicación del cliente con un token y un estado adjuntos a la parte del fragmento de la URL. (Un estado es una string de caracteres únicos y no predecibles).
• Para evitar ataques de falsificación entre sitios, la aplicación debe probar el valor del estado entrante con el valor que se estableció originalmente, una vez que se inicia una redirección. (Somos blanco de un ataque si recibimos una respuesta con un estado que no coincide).
• El URI de redirección incluye el token de acceso, que se envía al cliente. Los clientes ahora tienen acceso a los recursos otorgados por los propietarios de los recursos.

Este flujo está en desuso debido a la falta de autenticación del cliente. Una aplicación maliciosa puede hacerse pasar por el cliente si obtiene las credenciales del cliente, que son visibles si se inspecciona el código fuente de la página, y esto deja al propietario vulnerable a los ataques de phishing.

No existe un canal secundario seguro como un código de autorización intermedio: toda la comunicación se lleva a cabo a través de redireccionamientos del navegador en el procesamiento de concesión implícita. Para mitigar el riesgo de que el token de acceso quede expuesto a posibles ataques, la mayoría de los servidores emiten tokens de acceso de corta duración.

3. Flujo de credenciales de contraseña del propietario del recurso:

En este flujo, las credenciales del propietario, como el nombre de usuario y la contraseña, se intercambian por un token de acceso. El usuario le da a la aplicación sus credenciales directamente y la aplicación luego utiliza esas credenciales para obtener un token de acceso de un servicio.

1. Las aplicaciones cliente solicitan credenciales al usuario.
2. El cliente envía una solicitud al servidor de autorización para obtener el token de acceso.
3. El servidor de autorización autentica al cliente, determina si está autorizado para realizar esta solicitud y verifica las credenciales del usuario. Devuelve un token de acceso si todo se verifica con éxito.
4. El cliente de OAuth realiza una llamada API al servidor de recursos utilizando el token de acceso para acceder a los datos protegidos.
5. El servidor de recursos otorga acceso.

La plataforma de identidad de Microsoft , por ejemplo, admite el flujo de credenciales de contraseña del propietario del recurso, lo que permite que las aplicaciones inicien la sesión de los usuarios utilizando directamente sus credenciales.

Es apropiado para propietarios de recursos con una relación de confianza con sus clientes. No se recomienda para aplicaciones de terceros que no hayan sido lanzadas oficialmente por el proveedor de la API.

¿Por qué no se recomienda el tipo de concesión de credenciales de contraseña del propietario del recurso?

1. Suplantación de identidad : alguien puede hacerse pasar por el usuario para solicitar el recurso, por lo que no hay forma de verificar que el propietario realizó la solicitud.
2. Ataques de phishing : una aplicación cliente aleatoria solicita al usuario las credenciales. En lugar de redirigirte a tu cuenta de Google cuando una aplicación solicita tu nombre de usuario y contraseña de Google.
3. Las credenciales del usuario podrían filtrarse malintencionadamente a un atacante.
4. Una aplicación cliente puede solicitar cualquier alcance que desee del servidor de autorización. A pesar de los ámbitos controlados, una aplicación cliente puede acceder a los recursos del usuario sin el permiso del usuario.

Por ejemplo, en 2017, se utilizó una aplicación falsa de Google Docs para engañar a los usuarios haciéndoles creer que era el producto legítimo ofrecido por Google. Los atacantes utilizaron esta aplicación para acceder a las cuentas de correo electrónico de los usuarios abusando del token OAuth.

4. Flujo de Credenciales de Cliente:

El flujo de credenciales del cliente permite que un servicio de cliente use sus propias credenciales, en lugar de hacerse pasar por un usuario para acceder a los datos protegidos. En este caso, el alcance de la autorización se limita a los recursos protegidos controlados por el cliente.

1. La aplicación cliente realiza una solicitud de autorización al servidor de autorización utilizando sus credenciales de cliente.
2. Si las credenciales son precisas, el servidor responde con un token de acceso.
3. La aplicación usa el token de acceso para realizar requests al servidor de recursos.
4. El servidor de recursos valida el token antes de responder a la solicitud.

OAuth 2.0 frente a OAuth 1. 0

Las versiones de OAuth no son compatibles, ya que OAuth 2.0 es una revisión completa de OAuth 1.0. Implementar OAuth 2.0 es más fácil y rápido. OAuth 1.0 tenía requisitos criptográficos complicados, admitía solo tres flujos y no era escalable.

Ahora que sabe lo que sucede detrás de escena cuando olvida su contraseña de Facebook, y lo verifica a través de su cuenta de Google y le permite cambiarla, o cada vez que cualquier otra aplicación lo redirige a su cuenta de Google, comprenderá mejor cómo funciona. cómo funciona.