Desarrollo Web

Seguramente hayas oído hablar de OAuth2 al tratar temas relacionados con la seguridad. Te contamos en qué consiste este protocolo estándar utilizado por APIs, qué ventajas aporta y cuál es su flujo, entre otros detalles.

Qué es OAuth 2.0

OAuth 2.0 es un estándar abierto para la autorización de APIs, que nos permite compartir información entre sitios sin tener que compartir la identidad.

Es un mecanismo utilizado a día de hoy por grandes compañías como Google, Facebook, Microsoft, Twitter, GitHub o LinkedIn, entre otras muchas.

Utiliza diferentes flujos de autenticación, como el flujo de código de autorización, el flujo de propietario de la contraseña, el flujo implícito, entre otros, así como la extensión de flujos, que también nos permiten definir nuevos flujos.

Por qué surge OAuth

Surge para paliar la necesidad que se establece del envío continuo de credenciales entre cliente y servidor.

Si nos planteamos desarrollar una API REST y una aplicación cliente que pueda consumir de nuestros servicios, si queremos tener un mínimo de mecanismos de seguridad, antes de OAuth2 necesitábamos que el usuario nos enviara las credenciales.

Si la aplicación cliente es nuestra y la API REST también, posiblemente no existan grandes dificultades. El problema está cuando se quiere hacer una integración con aplicaciones de terceros, ahí es donde aparece la dificultad.

Por ejemplo, si queremos que nuestra aplicación sea capaz de generar contenido para Twitter y que aparezca en el timeline de un usuario, tendríamos que pedirle el usuario y contraseña al mismo para poder hacer este proceso, y la verdad es que no es algo razonable ni aceptable.

Con OAuth2 el usuario delega la capacidad de realizar ciertas acciones, no todas, a las cuales da su consentimiento para hacerlas en su nombre.

Podríamos delegar en una aplicación como Runtastic, la posibilidad de escribir por nosotros en Twitter cada vez que terminemos una carrera. De esta forma, la aplicación no tiene porqué tener nuestras credenciales de Twitter, pero le permitiríamos hacer algo en Twitter por nosotros.

De esta forma, cuando desarrollamos una aplicación no tenemos por qué almacenar el nombre de usuario y contraseña del mismo, sin embargo, vamos a poder hacer algún determinado conjunto de acciones en su nombre.

Caso de uso de OAuth2

Supongamos que un usuario tiene una cuenta en Facebook o Twitter, y quiere acceder a otra plataforma, pero sin tener que registrarse. En este caso esa aplicación puede pedir al usuario que se autentique en Facebook o Twitter, y si considera que la información a la que le da acceso es correcta, le te podría permitir realizar un conjunto cerrado de acciones dentro de su plataforma.

De esa manera, esa plataforma de terceros no tendría por qué tener ese nombre de usuario ni la contraseña almacenados, sobre todo siendo un nombre de usuario y contraseña de otro servicio distinto, como podría ser alguna de estas redes sociales.

Roles

Dentro de OAuth 2.0 encontramos diferentes roles que van a participar en el proceso:

• Dueño del recurso (Owner).

• Cliente (Client).

• Servidor de recursos protegidos (Resource Server).

• Servidor de autorización (Authorization Server).

Dueño del recurso

El propietario del recurso es el usuario que da autorización a una determinada aplicación para acceder a su cuenta y poder hacer algunas cosas en su nombre.

El conjunto de cosas que puede hacer la aplicación en su nombre se denomina alcance, y podría ser, por ejemplo, solamente acceso de lectura y no poder crear ningún tipo de elemento de ningún nuevo recurso en su nombre.

Un ejemplo de esto son los widgets que nos permiten integrar Twitter o Facebook dentro de una web, pero que no nos permiten generar nuevo contenido.

Se le llama dueño del recurso porque, si bien la API no es suya, los datos que maneja sí lo son.

Cliente

El cliente sería la aplicación que desea acceder a esa cuenta de usuario.

Antes de que pueda hacerlo debe ser autorizada por el usuario, y dicha autorización debe ser validada por la API.

El cliente puede ser una aplicación web, una aplicación móvil, una aplicación de escritorio, una aplicación para smartTV, un dispositivo de IoT, otra API que consumiera de esta API, etcétera.

Servidor de autorización

El servidor de autorización es el responsable de gestionar las peticiones de autorización.

Verifica la identidad de los usuarios y emite una serie de tokens de acceso a la aplicación cliente.

En muchas ocasiones, podemos implementar el servidor de autorización nosotros mismos, o podemos delegar en un tercero (Facebook, Twitter, Github, Google, etcétera) y tener solamente un servidor de recursos. Incluso podemos desarrollar el cliente y delegar la autorización en un tercero.

Servidor de recursos

El servidor de recursos será la API propiamente, es decir, el servidor que aloja el recurso protegido al cual queremos acceder.

Puede que también forme parte de la misma aplicación que el propio servidor de autenticación.

Flujo de OAuth2

El flujo más o menos genérico de este protocolo el que vemos en la siguiente imagen:

Una aplicación cliente, ya sea otra API o cualquier otra aplicación, quiere acceder a un recurso, y para ello lo que hace es pedir autorización al dueño del recurso. Si todo va bien, este se la concede.

Al concederle la autorización pasaría al servidor de autorización para obtener el token de acceso, una vez obtenido el mismo, podríamos ir al servidor de recursos y obtener el recurso protegido.

Como ya comentamos antes, puede darse el caso que el servidor de autorización y el servidor de recursos no sean de aplicaciones separadas, sino que estén dentro del mismo servidor.

Tipos de clientes

Existen varios tipos de clientes:

• Clientes confidenciales: son aquellos que son capaces de guardar una contraseña sin que sea expuesta. Una aplicación nativa compilada es un buen ejemplo de este tipo de clientes.

• Clientes públicos: son aquellos que no son capaces de mantener esta contraseña a salvo, como por ejemplo aplicaciones JavaScript, Angular, etcétera.

En función del tipo de cliente, necesitaremos implementar un flujo de OAuth2 de diferentes formas.

Tipos de concesión (Grant types)

Disponemos de diferentes tipos de concesión, algunas de las más conocidas son:

• Authorization code: basada en un código de autorización.

• Implícit: implícita.

• Resource owner password credentials: contraseña del propietario de los recursos.

• Device code flow: basada en el dispositivo.

• Cliente credentials flow: basada en las credenciales de cliente.

Además de todas las existentes, tenemos la posibilidad de extenderlas para crear nuevos tipos de tipos de concesión.

Authorization code

Se basa en un código de autorización. Es la más completa de todas y se utiliza en clientes confidenciales.

Sigue una serie de pasos:

• El cliente redirige al usuario al endpoint de autorización, con una URL con una serie de parámetros, como el tipo de respuesta que esperamos un código (response_type), el identificador de cliente (client_id), una URL de vuelta a nuestra aplicación (redirect_uri) y un ámbito sobre la autorización o para qué se quiere (scope).

Un ejemplo sería el siguiente:

https://autorizacion.servidor.com//authorize?response_type=code&client_id=the-client-id&state=xyz&redirect_uri=https://cliente.ejemplo.com/cb&scope=api_read

• Una vez allí, pediría al dueño que se autenticase, y una vez que lo ha hecho, a través de esa URL de retorno, se devuelve un código (code) que representa el consentimiento del usuario y su autorización, y un estado (state) que debe ser igual que en la petición.

Un ejemplo sería:

https://cliente.ejemplo.com/cb?code=AbCdEfGHiJK12345&state=xyz

• Con ese código podemos hacer una petición de tipo POST con esta estructura:

POST /token HTTP/1.1
Host: autorizacion.servidor.com
Authorization: Basic afds8709afs8790asf

grant_type=authorization_code
&code=AbCdEfGHiJK12345
&redirect_uri=https://cliente.ejemplo.com/cb

O con esta estructura alternativa:

POST /token HTTP/1.1
Host: autorizacion.servidor.com

grant_type=authorization_code
&code=AbCdEfGHiJK12345
&redirect_uri=https://cliente.ejemplo.com/cb
&client_id=the-client-id
&client_secret=qwepuirqewipor09748nmenads

• Si todo es correcto, se obtendría la respuesta válida, que sería de este tipo:

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-caché

{
        “access_token”:”2YotnFZFEjr1zCsicMWpAA”,
        “token_type”:”example”,
        “expires_in”:3600,
        “refresh_token”:”tGzv3JOkF0XG5Qx2TIKWIA”,
        “example_parameter”:”example_value”
}

• Con este token obtenido, se podría hacer, en nombre del cliente, todas las cosas para lo que se hubiera dado el consentimiento.