¿Qué es OAuth? Definición y cómo funciona

Hemos hablado de dar tus contraseñas y de cómo nunca deberías hacerlo. Cuando un sitio web quiere utilizar los servicios de otro -como la publicación de Bitly en tu flujo de Twitter- en lugar de pedirte que compartas tu contraseña, debería utilizar un protocolo llamado OAuth en su lugar.

Es importante entender cómo un programa, sitio web o aplicación podría autenticarte como usuario: ¿tienen los permisos adecuados? ¿Les has concedido algún tipo de forma de verificar quién eres y acceder a los datos en tu nombre? OAuth ayuda a agilizar este proceso: pero incluso con la automatización, siempre sea consciente de cómo una persona o empresa utiliza (o almacena) sus datos.

¿Qué es OAuth?

OAuth es un protocolo o marco de autorización de estándar abierto que proporciona a las aplicaciones la capacidad de «acceso seguro designado». Por ejemplo, puedes decirle a Facebook que está bien que ESPN.com acceda a tu perfil o publique actualizaciones en tu línea de tiempo sin tener que darle a ESPN tu contraseña de Facebook. Esto minimiza el riesgo de manera importante: En el caso de que ESPN sufra una brecha, tu contraseña de Facebook permanece a salvo.

OAuth no comparte datos de contraseñas, sino que utiliza tokens de autorización para probar una identidad entre consumidores y proveedores de servicios. OAuth es un protocolo de autenticación que le permite aprobar que una aplicación interactúe con otra en su nombre sin revelar su contraseña.

SAML frente a OAuth

SAML (Security Assertion Markup Language) es un estándar alternativo de autenticación federada que muchas empresas utilizan para el inicio de sesión único (SSO). SAML permite a las empresas controlar quién tiene acceso a los recursos corporativos.

Hay muchas diferencias entre SAML y OAuth. SAML utiliza XML para pasar mensajes, y OAuth utiliza JSON. OAuth proporciona una experiencia móvil más sencilla, mientras que SAML está orientado a la seguridad empresarial. Este último punto es un diferenciador clave: OAuth utiliza mucho las llamadas a la API, por lo que las aplicaciones móviles, las aplicaciones web modernas, las consolas de juegos y los dispositivos del Internet de las Cosas (IoT) encuentran en OAuth una mejor experiencia para el usuario. SAML, por otro lado, deja caer una cookie de sesión en un navegador que permite a un usuario acceder a ciertas páginas web – genial para días de trabajo de corta duración, pero no tan genial cuando tienes que iniciar sesión en tu termostato todos los días.

Ejemplos de OAuth

El ejemplo más simple de OAuth en acción es un sitio web que dice «oye, ¿quieres iniciar sesión en nuestro sitio web con el login de otro sitio web?» En este caso, lo único que quiere saber el primer sitio web, al que llamaremos consumidor, es que el usuario es el mismo en ambos sitios web y que ha iniciado la sesión con éxito en el proveedor de servicios, que es el sitio en el que el usuario inició la sesión, no el consumidor.

Las aplicaciones de Facebook son un buen ejemplo de uso de OAuth. Digamos que estás usando una aplicación en Facebook, y te pide que compartas tu perfil y tus fotos. Facebook es, en este caso, el proveedor de servicios: tiene tus datos de acceso y tus fotos. La aplicación es el consumidor y, como usuario, quieres utilizarla para hacer algo con tus fotos. Le diste específicamente a esta aplicación acceso a tus fotos, que OAuth está gestionando en segundo plano.

Tus dispositivos domésticos inteligentes – tostadora, termostato, sistema de seguridad, etc. – probablemente utilizan algún tipo de datos de acceso para sincronizarse entre sí y permitirte administrarlos desde un navegador o dispositivo cliente. Estos dispositivos utilizan lo que OAuth llama autorización confidencial. Eso significa que conservan la información de la clave secreta, para que no tengas que iniciar sesión una y otra vez.

Explicación de OAuth

OAuth trata de la autorización y no de la autenticación. La autorización es pedir permiso para hacer cosas. La autenticación consiste en demostrar que eres la persona correcta porque sabes cosas. OAuth no pasa los datos de autenticación entre los consumidores y los proveedores de servicios, sino que actúa como una especie de token de autorización.

La analogía común que he visto utilizar mientras investigaba sobre OAuth es la llave del coche. La llave permite al aparcacoches arrancar y mover el coche, pero no le da acceso al maletero o a la guantera.


Un token OAuth es como la llave del aparcacoches. Como usuario, puedes decirle a los consumidores lo que pueden usar y lo que no pueden usar de cada proveedor de servicios. Puedes dar a cada consumidor una llave valet diferente. Nunca tienen la clave completa o cualquiera de los datos privados que les da acceso a la clave completa.

Cómo funciona OAuth

Hay 3 actores principales en una transacción OAuth: el usuario, el consumidor y el proveedor de servicios. Este triunvirato ha sido llamado cariñosamente el Triángulo del Amor de OAuth.

En nuestro ejemplo, Joe es el usuario, Bitly es el consumidor, y Twitter es el servicio proporcionado que controla el recurso seguro de Joe (su flujo de Twitter). A Joe le gustaría que Bitly pudiera publicar enlaces acortados en su stream. Así es como funciona:

Paso 1 – El usuario muestra su intención

  • Joe (usuario): «Oye, Bitly, me gustaría que pudieras publicar enlaces directamente en mi stream de Twitter.»
  • Bitly (Consumidor): «¡Genial! Déjame ir a pedir permiso»

Paso 2 – El consumidor obtiene el permiso

  • Bitly: «Tengo un usuario que quiere que publique en su stream. ¿Puedo tener un token de solicitud?»
  • Twitter (proveedor de servicios): «Claro, aquí tienes un token y un secreto»

El secreto se utiliza para evitar la falsificación de solicitudes. El consumidor utiliza el secreto para firmar cada solicitud para que el proveedor de servicios pueda verificar que realmente proviene de la aplicación del consumidor.

Paso 3 – El usuario es redirigido al proveedor de servicios

  • Bitly: «OK, Joe. Te envío a Twitter para que puedas aprobar. Llévate este token»
  • Joe: «¡Ok!»

<Bitly dirige a Joe a Twitter para su autorización>

Esta es la parte que da miedo. Si Bitly fuera la súper sombría Evil Co. podría hacer aparecer una ventana que se pareciera a Twitter pero que en realidad fuera un phishing para tu nombre de usuario y contraseña. Asegúrate siempre de verificar que la URL a la que te dirigen es realmente el proveedor del servicio (Twitter, en este caso).

Paso 4 – El usuario da su permiso

  • Joe: «Twitter, me gustaría autorizar este token de solicitud que me ha dado Bitly.»
  • Twitter: «Vale, para estar seguro, ¿quieres autorizar a Bitly a hacer X, Y y Z con tu cuenta de Twitter?»
  • Joe: «¡Sí!»
  • Twitter: «Vale, puedes volver a Bitly y decirles que tienen permiso para usar su token de solicitud».

Twitter marca el token de solicitud como «good-to-go», así que cuando el consumidor solicite el acceso, será aceptado (siempre que esté firmado usando su secreto compartido).

Paso 5 – El consumidor obtiene un token de acceso

  • Bitly: «Twitter, ¿puedo cambiar este token de solicitud por un token de acceso?»
  • Twitter: «Claro, aquí tienes el token de acceso y el secreto»

Paso 6 – El consumidor accede al recurso protegido

  • Bitly: «Me gustaría publicar este enlace al stream de Joe. Aquí está mi token de acceso!»
  • Twitter: «¡Hecho!»

En nuestro escenario, Joe nunca tuvo que compartir sus credenciales de Twitter con Bitly. Simplemente delegó el acceso utilizando OAuth de forma segura. En cualquier momento, Joe puede iniciar sesión en Twitter y revisar el acceso que ha concedido y revocar tokens para aplicaciones específicas sin afectar a otras. OAuth también permite niveles de permiso granulares. Puedes dar a Bitly el derecho de publicar en tu cuenta de Twitter, pero restringir a LinkedIn el acceso de sólo lectura.

OAuth 1.0 vs. OAuth 2.0

OAuth 2.0 es un rediseño completo de OAuth 1.0, y los dos no son compatibles. Si creas una nueva aplicación hoy, utiliza OAuth 2.0. Este blog sólo se aplica a OAuth 2.0, ya que OAuth 1.0 está obsoleto.

OAuth 2.0 es más rápido y fácil de implementar. OAuth 1.0 utilizaba complicados requisitos criptográficos, sólo soportaba tres flujos y no era escalable.

OAuth 2.0, por el contrario, tiene seis flujos para diferentes tipos de aplicaciones y requisitos, y permite secretos firmados sobre HTTPS. Los tokens de OAuth ya no necesitan ser encriptados en los puntos finales en 2.0, ya que están encriptados en tránsito.

Otros recursos

Espero que esto haya sido un buen manual para que te familiarices con OAuth, de modo que la próxima vez que veas «Iniciar sesión con Twitter» o una verificación de identidad delegada similar, tengas una buena idea de lo que está pasando.

Si quieres profundizar en la mecánica de OAuth, aquí tienes algunos enlaces útiles:

  • http://marktrapp.com/blog/2009/09/17/oauth-dummies
  • https://dev.twitter.com/docs/auth/oauth/faq
  • http://stackoverflow.com/questions/4113934/how-is-oauth-2-different-from-oauth-1
  • http://googlecodesamples.com/oauth_playground/

Deja una respuesta

Tu dirección de correo electrónico no será publicada.