Autorización de Recursos: OAuth 2.0

Open Authorization 2.0 (OAuth2) es un estándar diseñado para permitir que una aplicación acceda a recursos alojados por otras aplicaciones web en nombre de un usuario. Sustituyó a OAuth 1.0 en 2012 y es ahora el estándar de facto de la industria para la autorización en línea.

OAuth 2.0 proporciona acceso consentido y restringe las acciones que la aplicación cliente puede realizar en los recursos en nombre del usuario, sin compartir nunca las credenciales de este, desacoplando autenticación de autorización

Aunque la web es la principal plataforma de OAuth 2, la especificación también describe cómo gestionar este tipo de acceso delegado a otros tipos de clientes (aplicaciones basadas en el navegador, aplicaciones web del lado del servidor, aplicaciones nativas/móviles, dispositivos conectados, etc.)

Un buen ejemplo que explica el funcionamiento del framework, es el que utiliza Paradigma Digital en su blog:

“De una manera simplificada, el uso de OAuth es análogo al uso de una tarjeta de acceso a un hotel.

Para obtener la tarjeta de acceso, el primer paso es pasar un proceso de autenticación tras el cual te dan la tarjeta (un access token), posteriormente puedes usar la tarjeta para acceder a los distintos partes del hotel (recursos de la API) a las cuales se tiene permiso para acceder o no dependiendo de la autorización.”

Dada la complejidad que puede llegar a tener una comunicación OAuth2, su explicación se va a dividir en tres post, este primero en el que se abordarán los conceptos fundamentales y flujo funcional, un segundo post en el que se profundizará en otros elementos relacionados con el protocolo de comunicación, y un tercero en el que se explicará a bajo nivel el flujo de comunicación OAuth2 más habitual.

La estructura será:

Post 1
- Actores
- Tipos de autorización
- Flujo lógico
Post 2
- Protocolo
- Registro de la aplicación cliente
- Token de acceso
- Respuesta OAuth
Post 3
- Código de Autorización: Diagrama de secuencia
- Código de Autorización: Cabeceras HTTP

1. Actores

Los actores que intervienen en una operación OAuth 2.0 son cuatro:

Propietario del Recurso (PR) o Usuario (U) de la Aplicación Cliente. Se utilizará indistintamente un término u otro.
Servidor de Autorización (SA)
Servidor de Recursos (SR)
Aplicación Cliente (AC)

Propietario del Recurso

Es el usuario de la Aplicación Cliente, que a la vez posee una cuenta en el Servidor de Recursos, de la que se va compartir información con la Aplicación Cliente.

Servidor de Autorización

Es responsable del proceso de autenticación para verificar la identidad del Propietario del Recurso, y de la Aplicación Cliente. Emite tokens de acceso a la Aplicación Cliente que autorizan el acceso a la información del Propietario del Recurso en el Servidor de Recursos.

Servidor de Recursos

Aloja las cuentas de usuario. En general desde el punto de vista de la comunicación entre cliente y proveedor, no suele existir diferencia entre Servidor de Autorización y Servidor de Recursos. El cliente se comunica de forma transparente mediante protocolo HTTP con ambos sin conocer cuál es cuál, ya que muchas compañías implementan un servidor que desempeña ambos roles.

Aplicación cliente

Es la aplicación que desea acceder a la información de la cuenta del usuario en el Servidor de Recursos. Antes de poder hacerlo debe ser autorizada por el usuario, y por el Servidor de Autorización.

Además OAuth2 distingue entre Aplicaciones Cliente confidenciales y públicas. Las primeras son capaces de guardar una contraseña sin que esta sea expuesta, y las segundas no.

2. Tipos de autorización (Grant Types)

Los tipos de autorización se corresponden con el grado de confianza entre Servidor de Recursos, la Aplicación Cliente, y el tipo de contenido. Dependiendo del tipo de autorización la secuencia de comunicación entre los actores varía. Los principales tipos de autorización son:

Código de autorización: Se necesita la interacción entre Propietario del Recurso, Aplicación Cliente y Servidor de Autorización, para obtener una autorización de acceso al Servidor de Recursos.
Autorización implícita: Es un flujo diseñado para aplicaciones que no pueden guardar de forma segura las credenciales que la identifican en el Servidor de Recursos.
Credenciales de Propietario del Recurso: El Propietario del Recurso confía sus credenciales de acceso a la Aplicación Cliente. Este flujo impide la gestión de niveles de autorización, la Aplicación Cliente podrá acceder a todos los recursos del usuario.
Credenciales de cliente: Se utiliza cuando una Aplicación Cliente quiere acceder a datos que no tienen propietario o no requieren autorización.

3. Flujo lógico

Una vez entendida la finalidad del framework y los actores implicados, el siguiente paso es describir las relaciones que se dan entre ellos. La secuencia de acciones que se da hasta que la Aplicación Cliente obtiene el recurso en el Servidor de Recursos es:

El usuario accede a la Aplicación Cliente. Ésta para proporcionar servicio necesita acceder a la información del usuario en el Servidor de Recursos.
La Aplicación Cliente solicita autorización al Usuario para acceder a su cuenta en el Servidor de Recursos.
El Usuario concede la autorización.
La Aplicación Cliente con la autorización concedida por el Propietario del Recurso, solicita un identificador de acceso al Servidor de Autorización.
El Servidor de Autorización proporciona credenciales de acceso a la Aplicación Cliente mediante un Access Token. La fase de autorización es completada.
La Aplicación Cliente presenta el access token al Servidor de Recursos
El Servidor de Recursos pregunta al Servidor de Autorización por la validez del token recibido
Si el access token es válido el Servidor de Recursos, entrega la información solicitada a la Aplicación Cliente.

Workflow Flujo OAuth

El flujo anterior, aunque válido para entender las implicaciones a nivel funcional, desde el punto de vista técnico es incompleto, ya que, no se menciona nada sobre el protocolo, agente de comunicación, ámbitos (scopes) a los que puede tener acceso el Cliente, o condiciones de registro de la Aplicación Cliente.

En las próximas entradas se profundizará paulatinamente en el resto de elementos, hasta llegar a las cabeceras de las peticiones y respuestas HTTP: OAuth 2.0: Protocolo y contenido

Referencias

Seguridad Identidad Digital Autorización OAuth2 OAuth