¿Qué es Oauth2?

¿Qué es OAuth 2.0?

OAuth2 es un protocolo de autorización que permite a otras personas o servicios, acceder a contenidos de un usuario sin que éstos tengan que conocer las credenciales del usuario.

¿Porque OAuth 2.0?

La falta de confianza suele ser el motivo principal para querer implementar un protocolo de autorización como  OAuth 2.0 .

La falta de confianza de un usuario con una aplicación de terceros puede propiciar que el usuario quiera permitir a la aplicación realizar tareas y obtener datos en su nombre pero sin darle las credenciales de autenticación a dicha aplicación

OAuth 2.0 tiene dos grandes ventajas:

• soluciona el problema de la confianza entre un usuario y aplicaciones de terceros
• permite a un proveedor de servicios facilitar a aplicaciones de terceros a que amplíen sus servicios con aplicaciones que hacen uso de los datos de sus usuarios de manera segura.

Roles de OAuth 2.0

[pic 1]

Propietario de recursos (Resource Owner)

Entidad que dará acceso a recursos protegidos. Cuando es una persona nos referiremos a él como usuario final.

Cliente (Client)

Es la aplicación que hace las peticiones a recursos protegidos en nombre de un propietario de recursos con la autorización del mismo.

Proveedor (Provider)

Servidor de recursos (Resource Server)

Es la entidad que tiene los recursos protegidos. Es capaz de aceptar y responder peticiones usando un Access-Token que debe venir en el header de la petición.

Servidor de autorización (Authorization Server)

En muchos casos el servidor de autenticación es el mismo que el Servidor de Recursos. En el caso de que se separen, el servidor de autenticación es el responsable de generar tokens de acceso y validar usuarios y credenciales.

¿Cómo funciona?

[pic 2]

1. El cliente solicita autorización al propietario del recurso. La petición se puede realizar directamente al servidor de autorización en lugar de al propietario del recurso (aconsejable).
2. El propietario del recurso concede la autorización para acceder al recurso informando al cliente del tipo de autorización disponible (autorization code, implicit, resource owner password credentials, client credentials).  La respuesta dependerá del pedido realizado por el cliente al iniciar la petición.
3. El cliente pide al servidor de autorización un token de acceso, identificándose y presentando la autorización obtenida en el paso 2.
4. El servidor de autorización valida las credenciales del cliente y su autorización. Sí son válidas, devuelve un token de acceso.
5. El cliente y el servidor de recursos ya son capaces de intercambiar peticiones seguras con el token de acceso para servir contenido protegido.

Registro de un cliente en el servidor de recursos

Un cliente debe estar dado de alta en el servidor de recursos al que quiere acceder. Se identifica con un client_id y habitualmente también con un client_secret además de las URL de redirección para usar en el intercambio de tokens y accesos.

El proceso de registro de un nuevo cliente no está definido en las especificaciones de OAuth2.

Los datos necesarios para registrar un cliente son competencia del servidor de recursos y es éste el que marca los pasos y formas en las que un cliente debe registrarse.

OAuth2 define dos tipos de cliente dependiendo de su capacidad para mantener las credenciales del cliente seguras y no expuestas.

Los tipos de cliente son:

• Confidential: Son aquellos que son capaces de mantener las credenciales de autentificación seguras y de manera confidencial.Están implementados en servidores seguros.
• Públicos: Son los que no son capaces de mantener la confidencialidad de las credenciales. Son los clientes web puros o las aplicaciones nativas de terminales y dispositivos.

Es el proveedor el encargado de definir los tipos de acceso para cada uno de los tipos de clientes definidos.

Endpoint en el proveedor

El proveedor puede definir dos puntos finales para permitir todo el flujo de autorización-validación . Uno de ellos será el encargado de autentificación y validación de credenciales y el otro será el encargado de expedir tokens de acceso.

• Authorization end-point: este punto de acceso debe ser el encargado de validar clientes y propietarios de recursos. Cuando un cliente quiere acceder a un recurso, es en este punto en el que el proveedor valida tanto el cliente como el propietario y genera concesiones para acceder a los recursos protegidos. Normalmente recibe (aparte de las credenciales necesarias) una url de redirección a la que redirigir el flujo una vez el propietario y el cliente han sido validados y el propietario ha concedido los permisos necesarios.) Cuando esto ocurre, a la url de redirección es a la que se le traspasan las concesiones (normalmente en formato de código).
• Token end-point: este punto es el encargado de dar tokens de acceso, normalmente a cambio de concesiones previamente expedidas por el Authorization end-point.

Obteniendo permisos para acceder al recurso protegido

Cuando un cliente quiere acceder a los recursos de un propietario, lo primero que necesita es solicitar permisos al propietario del recurso. Este paso se denomina Authorization Grant.

Para que un servidor de recursos te conceda un token de acceso, es imprescindible presentarle un Authorization Grant junto a las credenciales del cliente que intenta acceder a dichos datos.

(las credenciales necesarias para cada concesión dependen del proveedor, aunque como mínimo todos los clientes deben estar identificados de manera única con un client identifier).

...