A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

¿Qué es OAuth?

OAuth, abreviatura de “autorización abierta”, es un protocolo abierto comúnmente utilizado para otorgar a los sitios web o aplicaciones acceso a la información del usuario almacenada en otros sitios web, todo sin compartir contraseñas. Con OAuth, una persona puede permitir de manera selectiva y segura que dos sitios web interactúen directamente, con el objetivo de facilitar una tarea en particular. OAuth otorga permiso o autorización para acceder a datos, lo cual es diferente de autentificar una identidad (como cuando un usuario inicia sesión en un servicio).

OAuth se puede utilizar en situaciones que implican un navegador web, una aplicación móvil o un dispositivo del Internet de las Cosas (IoT), y está destinado a facilitar tareas como mover archivos, encontrar amigos en un sitio de redes sociales o cambiar la configuración de un termostato doméstico. El servicio que recibe el permiso para acceder a los datos de un usuario puede tener acceso limitado solo a algunos datos y capacidades variables (por ejemplo, solo lectura o lectura y edición). OAuth a veces se confunde con la función de inicio de sesión de terceros que permite a un usuario iniciar sesión en un sitio usando las credenciales de Google o Facebook. El inicio de sesión de terceros, llamado “open ID connect” (OIDC), es solo una aplicación específica de OAuth. Este artículo se centra en OAuth, pero también discutirá la aplicación OIDC de las capacidades de OAuth.

¿Cómo se ve OAuth?

Aquí hay un ejemplo de OAuth en acción. Cuando creas una cuenta en un servicio de redes sociales como LinkedIn, una de las primeras cosas que el sitio o la aplicación te pedirá es si deseas conectar tu libreta de direcciones para que LinkedIn pueda sugerirte otras personas que podrías agregar a tu red. Si declaras que tu libreta de direcciones está en Gmail, LinkedIn te dará un portal para iniciar sesión en Google. Si procedes a iniciar sesión en Google y autorizas esta conexión de la libreta de direcciones, LinkedIn entonces recopilará las direcciones de correo electrónico en tu libreta de direcciones y buscará esas direcciones en la base de datos de usuarios registrados de LinkedIn. Esto te ahorra el trabajo de tener que buscar conexiones porque tu información puede ser importada directamente desde Gmail.

Esta autorización permanecerá vigente hasta que le digas a Google que la revoque, o hasta que alcance su fecha de vencimiento. Si agregas direcciones de correo electrónico a tu cuenta de Gmail y deseas que LinkedIn realice otra búsqueda, no necesitarás reautorizar el acceso de LinkedIn a la libreta de direcciones de Gmail.

Este ejemplo ilustra algunas ventajas de OAuth:

  • Puedes conectar estos servicios sin tener que compartir tu información de inicio de sesión de Google con LinkedIn. Esto mantiene tus credenciales almacenadas en menos lugares, y por lo tanto menos expuestas al riesgo de una violación de datos.
  • El proceso está simplificado para ti. LinkedIn y Gmail manejan el intercambio de datos, con un esfuerzo mínimo de tu parte.
  • Puedes revocar el permiso de LinkedIn en cualquier momento.
  • LinkedIn solo obtiene acceso a las direcciones de correo electrónico en tu libreta de direcciones, y nada más en tu libreta de direcciones o en la cuenta de correo electrónico en general.

¿Cómo funciona OAuth?

Hay varias partes involucradas y varios pasos para configurar una situación de intercambio de datos con OAuth. Algunos de estos pasos son visibles, mientras que otros ocurren en segundo plano (es decir, directamente entre los dos servicios). Los pasos exactos pueden variar según para qué se esté utilizando OAuth, pero utilizando el ejemplo de LinkedIn/Google podemos explicar aproximadamente OAuth a través de las partes involucradas y los pasos reales de configuración.

Las partes involucradas

  • Propietario del recurso: La entidad, generalmente una persona, que desea permitir que un servicio acceda a datos en un servicio diferente.
  • Cliente: La aplicación o servicio que desea acceder a ciertos datos o realizar ciertas tareas para el propietario del recurso. En nuestro ejemplo, LinkedIn es el cliente porque quiere acceder a una libreta de direcciones almacenada en Gmail.
  • Servidor de autorización: El servicio (en este caso Google) que recibe una solicitud de acceso del cliente y verifica el permiso con el propietario del recurso. El servidor de autorización prepara el token de acceso (como una llave) que el cliente usará para acceder a los datos solicitados (direcciones de correo electrónico) ahora y en el futuro.
  • Servidor de recursos: La entidad que realmente tiene los datos (direcciones de correo electrónico) a los que el propietario del recurso le gustaría que el cliente accediera. En algunos casos, este es el mismo que el servidor de autorización, pero en otros puede ser diferente (en nuestro ejemplo, el servidor de recursos es Gmail).

Los pasos para configurar un acuerdo OAuth

Lo que sigue es un flujo general del código de autorización que representa lo que sucede con OAuth. Ten en cuenta que también existen muchos otros flujos, ligeramente diferentes, que han sido creados para diferentes escenarios.

  1. Vas al sitio web de LinkedIn y le pides a LinkedIn que busque personas que puedas conocer.
    • (El propietario del recurso inicia el proceso OAuth diciéndole a la aplicación cliente que quiere hacer algo usando sus datos.)
  2. LinkedIn le dice a Google que quieres compartir tu libreta de direcciones de Gmail con LinkedIn.
    • (El cliente envía un ping al servidor de autorización diciendo que el propietario del recurso quiere que el cliente acceda a ciertos datos.)
  3. Google verifica que está tratando con LinkedIn y no con un impostor, y qué datos se están solicitando.
    • (La solicitud de autorización contiene el alcance de la solicitud y los datos que se están solicitando—direcciones de correo electrónico—lo que el cliente puede hacer con los datos—solo descargar—y dónde devolver la solicitud de autorización—como una URL, como linkedin.com/callback. La solicitud de autorización también contiene un código que tanto el servidor de autorización como el cliente usan para verificarse mutuamente durante cualquier proceso de autorización.)
  4. Google devuelve un token a LinkedIn.
    • (El servidor de autorización le da al cliente un token de solicitud—un paquete digital que incluye una reiteración del alcance y un secreto específico para este acuerdo.)
  5. LinkedIn muestra una pantalla donde puedes iniciar sesión en Google y confirmar que quieres compartir direcciones de correo electrónico con LinkedIn.
    • (El propietario del recurso ve una pantalla de autorización que les pide que verifiquen que quieren permitirle al cliente el acceso a los datos especificados. Cuando el propietario del recurso valida la solicitud, la validación también envía de vuelta el token de solicitud—junto con el alcance y el secreto—como prueba de que nada se desvió durante el proceso de validación.)
  6. Google registra que has otorgado permiso a LinkedIn para descargar direcciones de correo electrónico de tu cuenta de Gmail.
    • (El servidor de autorización recibe la validación con el token de solicitud, verifica que todo esté como se espera y marca en sus registros que el propietario del recurso confirmó la solicitud.)
  7. LinkedIn confirma que Gmail tiene todo lo que necesita y solicita acceso a las direcciones de correo electrónico guardadas en la libreta de direcciones. Gmail responde con una clave que LinkedIn puede usar para acceder a las direcciones de correo electrónico por un cierto período de tiempo.
    • (El cliente ahora puede formalmente enviar el token de solicitud junto con una solicitud de acceso al servidor de recursos. El servidor de recursos ve que el token de solicitud fue validado y emite un token de acceso al cliente. El token de acceso detalla qué datos pueden ser accedidos, qué permisos fueron otorgados con respecto a esos datos y cuánto tiempo es válido el token de acceso. El token no contiene nada que identifique específicamente al propietario del recurso, solo qué datos pueden ser accedidos.)
  8. Cuando le pides a LinkedIn que realice otra búsqueda de amigos, LinkedIn puede acceder a tu libreta de direcciones sin tener que repetir todos los pasos anteriores.
    • (El cliente ahora puede usar el token de acceso para acceder directamente a los datos específicamente permitidos en el servidor de recursos sin necesitar la confirmación repetida del propietario del recurso.)

¿Cómo es diferente OIDC de OAuth?

OIDC, o inicio de sesión de terceros, es un protocolo de autentificación que está construido sobre el marco OAuth; la diferencia entre los dos no siempre es obvia. OIDC te permite iniciar sesión en un servicio, como Spotify, usando credenciales de otro servicio, como Google. La diferencia clave es que OIDC te autentifica, mientras que OAuth da autorización para realizar acciones con tus datos en tu nombre. Donde un proceso OAuth resulta en un token de acceso que contiene permisos de acceso a datos, un proceso OIDC resulta en un token de acceso emparejado con un token de identificación que contiene el estado de verificación de la autentificación del usuario (básicamente que eres quien dices ser), y tal vez información sobre el usuario, como nombre o correo electrónico.

Cuando el servicio al que el usuario quiere acceder (Spotify) recibe el token de identificación del servicio de autentificación (Google), sabe que la autentificación es exitosa. El proceso OIDC no otorga al servicio accedido ningún privilegio respecto a los datos del usuario en el servicio de autentificación. Otro resultado de esta transacción es que el servicio de autentificación también confirma la autenticidad del servicio al que se está accediendo.

Riesgos de seguridad y privacidad con OAuth y OIDC

OAuth y OIDC ofrecen ambas una mejor seguridad. Los protocolos OAuth resultan en no tener que compartir credenciales entre servicios, y menor exposición a violaciones de datos; también dan a la persona un control más refinado de cómo otros usan sus datos. La ventaja de usar un inicio de sesión de terceros (OIDC) cuando esté disponible es que reduce el número de inicios de sesión que necesitas registrar, lo cual a su vez puede traducirse en mejores hábitos de seguridad (como usar contraseñas fuertes y únicas).

Pero como con cualquier avance en seguridad, los riesgos también evolucionan en respuesta. Con el proceso OAuth, los hackers con credenciales de inicio de sesión robadas pueden inyectar una URL falsa en el proceso, desviando tokens destinados para el cliente a los sitios web de los hackers. Los hackers luego pueden usar los tokens secuestrados para acceder ilegalmente a los datos de un usuario.

Con OIDC, los hackers pueden engañar a una persona para que use una pantalla de inicio de sesión de terceros falsa con el fin de recoger la identificación y contraseña de un usuario. Con respecto a la privacidad, usar un inicio de sesión de terceros le da a Google o Facebook más datos para recopilar sobre tu actividad, ya que pueden ahora monitorear tu uso de esas aplicaciones y sitios web en los que inicias sesión.

¿Te atreves a descubrir el nuevo Internet de Brave?

Brave está desarrollado por un equipo de precursores de la web centrados en el rendimiento y la privacidad. Ayúdanos a solventar las deficiencias de la navegación.