OAuth2, protocolo de autorización

OAuth2 es un protocolo de autorización, que surgió a partir del nacimiento de la Web Social. Permite que los usuarios autoricen a terceros a acceder a su información sin que estos tengan que conocer las credenciales del usuario.

Hay múltiples entidades involucradas en el flujo de OAuth2:

• Propietario de recursos: Parte que puede autorizar el acceso a los recursos protegidos. Puede ser una autorización de ciertos recursos y de otros no. Generalmente es una persona.
• Cliente: Es el sitio web o aplicación que accederá a los recursos protegidos de un usuario con la autorización del mismo
• Proveedor:
  • Servidor de autorización: Valida usuario y credenciales; y genera tokens de acceso.
  • Servidor de recursos: Recibe peticiones de acceso a los recursos protegidos autorizando acceso si el token que viene (en el cuerpo o en las cabeceras, generalmente en las cabeceras) en la petición es válido.

Google, Facebook, Microsoft, Twitter o Ping Identity son proveedores de servicios Oauth2.

 

Casos de uso del protocolo de autorización OAuth2

• Una persona con cuenta en Facebook o Twitter quiere publicar contenido a través de otra aplicación. A través de Oauth2, el usuario da autorización a esa aplicación a publicar en su muro.
  Pero no la autoriza a ver su lista de amigos y por supuesto nunca le da acceso a sus credenciales.
  En cualquier momento, por razones de seguridad podemos rescindir la autorización de acceso de la aplicación, sin tener que modificar nuestra contraseña en Facebook o Twitter.
  El propietario sería la persona, el cliente la aplicación desde la que queremos hacer publicaciones y el proveedor Twitter o Facebook.

• Una persona con cuenta en Facebook o Twitter quiere acceder a otra plataforma pero sin tener que registrarse. En este caso, la aplicación te pide que te autentiques en Facebook o Twitter, y si considera que la información a la que le das acceso es correcta, te permite realizar acciones en su plataforma.
  El propietario sería la persona, y damos acceso a la información que necesita la aplicación para considerar que somos un usuario válido. El cliente la aplicación a la que queremos acceder sin tener que registrarnos y el proveedor Twitter o Facebook.

 

Esto tiene la desventaja de que algunas aplicaciones nos pueden dejar autenticarnos usando Facebook o Twitter, y luego publicar mensajes en nuestro perfil, sin que ello sea lo deseado por nosotros. Por eso hay que leerse bien la letra pequeña de que autorización estamos dando a la aplicación cliente.

 

Ejemplo de flujo para una aplicación cliente

Vamos a ver un ejemplo de como sería el flujo para una aplicación cliente usando como proveedor de servicio OAuth2 a Linkedin. Otros proveedores funcionan de manera similar.

Configurar tu aplicación en Linkedin

Cuando configuremos nuestra aplicación en Linkedin, obtendremos un identificador de cliente y un secreto de cliente.

El identificador de cliente y el secreto de cliente son únicas por aplicación, y sirven para identificarlo en el proveedor.
Se considera el identificador de cliente como una información pública que se usa en la construcción de la url de autenticación. El secreto de cliente debe permanecer confidencial por motivos de seguridad.

Para prevenir transacciones fraudulentas durante el proceso de autenticación, Linkedin solo se comunicará con esos puntos de acceso o direcciones que nosotros hayamos incluido como confiables.
Así que vamos a añadir una lista de url permitidas para la redirección cuando estemos esperando el código de autenticación.
Además es necesario configurar los permisos para indicar que información del usuario puede acceder la aplicación cliente. En este caso, vamos a añadir use r_basicprofile y r_emailaddress.

 

Solicitar código de autorización

Para obtener un código de autorización, debemos acceder al recurso de autorización

GET https://www.linkedin.com/oauth/v2/authorization

pasándole estos datos:

• response_type: En este caso será code.
• client_id: Es el identificador de cliente que obtuvimos cuando creamos la aplicación.
• redirect_uri: La url a la que te redirige mandando el código, después del proceso de autenticación.
• state: Una cadena única de nuestra elección.
• scope: El permiso o permisos que queremos que nos autoricen. En nuestro caso pondremos «r_basicprofile r_emailaddress».

Este recurso mostrará la pantalla de autenticación del proveedor de servicio OAuth2, y el usuario podrá introducir su usuario y contraseña. En este caso, las credenciales de Linkedin. La aplicación cliente no tendrá acceso a esos datos.
Cuando el usuario se haya autenticado, nos redirigirán a la redirect_uri pasando el código de autenticación en la url, que es la información a la que la aplicación cliente va a tener acceso.

El código de autorización no es nuestro token final que usaremos para hacer peticiones, si no que es usado en el siguiente paso para intercambiarlo por un token de acceso.

 

Intercambiar código de autenticación por Access Token

Para obtener el token, debemos acceder a este recurso

POST https://www.linkedin.com/oauth/v2/accessToken

pasándole estos parámetros:

• grant_type: authorization_code.
• code: El código de autenticación que acabamos de obtener.
• redirect_uri: Debe ser la misma url que en la petición anterior. En este caso no nos van a redirigir a ella.
• client_id: Es el identificador de cliente que obtuvimos cuando creamos la aplicación.
• client_secret: Es el identificador de cliente que obtuvimos cuando creamos la aplicación.

La respuesta de esta petición va a ser el access_token. En algunos proveedores, además devuelven un refresh_token.

En este articulo se puede leer un ejemplo del uso del refresh token.

 

Realizar una petición de autenticación

Una vez que tenemos el token, podemos realizar peticiones al API dónde se necesita estar autorizado. Por ejemplo, para obtener información del usuario

GET https://api.linkedin.com/v1/people/~:(id,first-name,last-name,email-address)?format=json

mandando el token obtenido como una cabecera.
Si el token es válido y no ha expirado, se devolverá la información de usuario.

 

¿Qué otros servidores OAuth2 has usado tú?

 

 

Articulos relacionados

Refresh token con autenticación JWT. Implementación en Node.js