Explicación del protocolo OAuth 2

Veamos qué es el protocolo OAuth y cómo funciona, a través de un ejemplo.

Introducción

OAuth 2 es un framework de autorización, que permite a las aplicaciones obtener acceso (limitado) a las cuentas de usuario de determinados servicios, como Facebook, GitHub, Twitter, Google+ y muchos más.

Consiste en delegar la autenticación de usuario al servicio que gestiona las cuentas, de modo que sea este quien otorgue el acceso para las aplicaciones de terceros.

OAuth 2 provee un flujo de autorización para aplicaciones web, aplicaciones móviles e incluso programas de escritorio.

Roles presentes en OAuth

En el protocolo que define OAuth podemos identificar 4 roles.

  • Client
  • Resource Owner
  • Resource Server
  • Authorization Server

Veamos a qué hace referencia cada uno.

Client.- El cliente es la aplicación que quiere acceder a la cuenta de un usuario, en un servicio determinado. A fin de conseguir ello, debe contar con una autorización del usuario, y esta autorización se debe validar (a través de la API del servicio).

Resource Owner.- El "dueño del recurso" es el usuario que autoriza a una aplicación, para que pueda acceder a su cuenta. El acceso está limitado en función del "scope" que ha concedido el usuario en la autorización.

Resource & Authorization Server.- Resource server es el servidor que almacena las cuentas de usuarios, y authorization server es el servidor que verifica la identidad de los usuarios y emite access tokens a la aplicación cliente.

Desde nuestro punto de vista como desarrolladores, la API del servicio representa muy bien a estos 2 últimos roles. Por tanto, podemos referirnos a ellos en conjunto, bajo el nombre de servicio o API.

Flujo del protocolo OAuth

El flujo descrito a continuación es un flujo genérico que representa al protocolo OAuth. Sin embargo, podemos encontrar diferencias en función al authorization grant type (es decir, según las condiciones en que se está implementando OAuth; que varía principalmente si se trata de una aplicación web, móvil o de escritorio).

  1. La aplicación cliente solicita una autorización para acceder a los recursos de un usuario en un servicio determinado.

  2. Si el usuario autoriza esta solicitud, la aplicación recibe una authorization grant (concesión de autorización).

  3. La aplicación solicita un access token al authorization server (API) presentando su identidad, y el permiso concedido anteriormente.

  4. Si la identidad de la aplicación cliente se reconoce correctamente por el servicio, y la concesión de autorización es válida, el authorization server (API) emite un access token a la aplicación. Con esto la autorización se ha completado.

  5. La aplicación solicita un recurso al resource server (API) y presenta el correspondiente access token.

  6. Si el access token es válido, el resource server (API) hace entrega del recurso a la aplicación.

Con recurso generalmente nos referimos a acceder a una información del usuario, pero si la API del servicio lo permite (y el usuario nos lo ha autorizado), podríamos estar ejecutando acciones en nombre del usuario (a través del servicio).

Explicación del protocolo OAuth (a través de un ejemplo)

Veamos cómo funciona OAuth, descrito muy de cerca a través de un ejemplo.

Imaginemos que queremos iniciar sesión vía Facebook.

En ese caso, se desarrolla la siguiente secuencia.

  • Un usuario entra a nuestra página (digamos que nuestra página se llama PYM), y hace clic en "Ingresar usando Facebook".

  • Nuestra aplicación lo va a redirigir a una URL como la siguiente: facebook.com/oauth2/auth?client_id=ABC&redirect_uri=programacionymas.com/oauth_response

    Ésta URL contiene los siguientes parámetros: un client_id, una redirect_uri y opcionalmente un parámetro scopes (para indicar a qué información queremos acceder).

  • Facebook primero va a ver si nuestro client_id es válido (comparándolo con la lista de oauth_client permitidos).

  • Si todo está correcto, entonces define una variable de sesión que guarda nuestro client_id y redirect_uri. Y entonces:

    • Redirige al usuario a facebook.com/login (muestra un formulario de inicio de sesión) si el usuario aún no ha iniciado sesión.
    • O avanza directamente al siguiente paso si ya hay una sesión activa en Facebook.
  • Facebook muestra el logo de PYM y el nombre de la app (lo reconoce a partir del client_id), indicando al usuario: "Esta app quiere acceder a tus datos de Facebook, ¿le das permiso?" (según el scope indicado previamente).

Si aceptamos, entonces ...

  • Facebook genera un código (que tiene un sólo uso válido para PYM, el usuario en cuestión y el scope solicitado). Facebook redirige al usuario según la redirect_uri indicada al inicio.

    Es decir, esta redirect_uri es una ruta usada como callback en nuestra aplicación para recibir el permiso otorgado por Facebook y hacer posible el inicio de sesión. Facebook enviará un código generado hacia la aplicación PYM: programacionymas.com/oauth_response?code=aqui_un_codigo_extenso.

  • PYM toma el código que recibe de Facebook y vuelve a hacer una petición a Facebook, incluyendo ahora su client_secret.

    Esta última petición no se trata de una redirección a nivel de navegador, sino más bien de una solicitud de servidor a servidor.

    Para probar su identidad, PYM hace una petición de la siguiente forma: facebook.com/oauth2/token?client_id=ABC&client_secret=XYZ&code=aqui_un_codigo_extenso

  • Facebook verifica que el código sea válido, y así mismo lo invalida en ese instante (recordar que son de un único uso).

  • Entonces Facebook responde con un AccessToken, que PYM podrá usar (hasta que expire) para hacer peticiones a la API, en nombre del usuario que ha otorgado los permisos.

    Por ejemplo, con este token podemos acceder a la información básica del usuario, y usar estos datos para crear una cuenta en nuestra aplicación. Pero un token, dependiendo de la API, nos permite también realizar acciones en nombre del usuario, en función a los permisos otorgados (el parámetro scope usado inicialmente determina los permisos que estamos solicitando al usuario).

Preguntas frecuentes

¿Por qué Facebook le pasa un código de uso único a PYM y no el AccessToken directamente?

Respuesta: Porque Facebook necesita validar que realmente PYM ha solicitado el acceso. El client_id suele ser un dato que está expuesto (es público, ya que forma parte de la URL de Facebook a donde el usuario es redirigido desde un inicio). Cualquiera podría hacer una petición usando dicho client_id. Pero existe un client_secret que sólo PYM posee, y es justamente lo que se va a validar en este punto.

Si un "hacker" robó este dato (el client_secret de una aplicación), podría tener los mismos permisos que fueron otorgados a esta app por parte de sus usuarios.

Por eso Facebook debe asegurar que quien solicitó los permisos sea el mismo que va a acceder a ellos. Aquí es donde PYM se identifica frente a Facebook con su client_secret.

Otra pregunta: En vez de redirigir a una URL que contiene el "código extenso" como un parámetro, ¿por qué no se envía a PYM por detrás, de servidor a servidor?

Respuesta: Cuando Facebook redirige al usuario a una ruta de PYM, lo hace principalmente para ceder el control a la aplicación cliente, a fin de continuar con el flujo. De esta forma la app puede hacer lo que estaba intentando hacer inicialmente, una vez que el usuario ha otorgado los permisos necesarios.

Referencias

oauth

Cursos recomendados

Curso de Laravel 5.5

Aprende Laravel

Aprende Laravel 5.5 desde cero y desarrolla aplicaciones web reales, en tiempo récord, de la mano de Laravel.

Ver más
Curso práctico de Javascript

Aprende Javascript

Domina JS con este curso práctico y completo! Fundamentos, ejemplos reales, ES6+, POO, Ajax, Webpack, NPM y más.

Ver más
Curso de Laravel, Vue.js y Pusher

Aprende Vue.js

Desarrollemos un Messenger! Aprende sobre Channels, Queues, Vuex, JWT, Sesiones, BootstrapVue y mucho más.

Ver más
Logo de Programación y más

¿Tienes alguna duda?

Si algo no te quedó claro o tienes alguna sugerencia, escribe un comentario aquí debajo.

Además recuerda compartir el post si te resultó de ayuda. ¡Gracias!

Antes que te vayas

Inscríbete en nuestro curso gratuito de Laravel