Oauth 2.0

Cómo hemos visto en uno de los puntos anteriores, Oauth es un estándar abierto para la autorización que permite controlar el acceso por parte de las aplicaciones a los datos sin tener que compartir la identidad. En OAuth se define cuatro roles:

Propietario del recurso: es el usuario encargado de autorizar el acceso a sus datos y limita el alcance de dicha autorización
Cliente: es la aplicación que quiere acceder al recurso.
Servidor de recursos: es la API que expone los datos a los que se quiere acceder
Servidor de autorización: es el encargado de garantizar el acceso a los datos por parte de la aplicación después de que el cliente haya dado su consetimiento

Los roles mencionados intervienen en todos los flujos Oauth, también llamados grant types, estos flujos presentan los escenarios de negocio que se pueden dar según 3 parámetros: tipo de aplicación consumidora, grado de confianza y la interacción por parte del usuario en dicho proceso.

Antes de entrar en detalle con respecto a los diferentes flujos veremos un diagrama de cómo interactuan normalmente entre sí:

A continuación se encuentra una explicación más detallada de los pasos en el diagrama:

La aplicación solicita autorización para acceder a los recursos de servicio del usuario
Si el usuario autoriza la solicitud, la aplicación recibe la autorización
La aplicación solicita al servidor de autorización (API), presentando la autenticación de su identidad y la autorización otorgada La aplicación solicita al servidor de autorización (API) un token de acceso presentando la autenticación de su propia identidad y la autorización otorgada
Si la identidad de la aplicación es autenticada y la autorización es válida, el servidor de autorización (API) emite un token de acceso a la aplicación. La autorización finaliza
La aplicación solicita el recurso al servidor de recursos (API) y presenta el token de acceso para autenticarse
Si el token de acceso es válido, el servidor de recursos (API) provee el recurso a la aplicación

El flujo real de este proceso variará dependiendo del tipo autorización que esté en uso, sin embargo, esta es la idea general. Examinaremos diferentes tipos de autorizaciones en una sección posterior.

Como hemos mencionado anteriormente, existen diferentes flujos (grant types) para cada escenario:

Client credentials grant type
Resource Owner Password grant type
Authorization code grant type
Implicit gran type

Client Credentials

Este flujo es utilizado para aplicaciones que pueden solicitar un token de acceso y acceder a recursos por sí mismas. Estas aplicaciones suelen utilizar servicios que llaman a las API sin usuarios.

Esta concesión utiliza los siguientes roles:

Aplicación : cliente que realiza solicitudes protegidas utilizando la autorización del propietario del recurso.
Servidor de autorización : el servidor de inicio de sesión único que emite tokens de acceso a las aplicaciones cliente después de autenticar correctamente al propietario del recurso.
Servidor de recursos : el servidor que aloja recursos protegidos y acepta y responde a solicitudes de recursos protegidos utilizando tokens de acceso. Las aplicaciones acceden al servidor a través de API.

Autenticar con ID de cliente y secreto :
La aplicación consumidora se autentica con el servidor de autorización enviando sus credenciales (id y secreto).
Emitir token de acceso :
El servidor de autorización valida el ID y el secreto del cliente y emite un token de acceso.
Solicitar recurso con token de acceso :
La aplicación intenta acceder al recurso desde el servidor de recursos presentando el token de acceso.
Devolver recurso :
Si el token de acceso es válido, el servidor de recursos devuelve los recursos a la aplicación.

Se recomienda usar solo para aplicaciones internas de la organización o los datos que expone la API no son sensibles

Resource Owner Password

Este flujo se utiliza en apliaciones de gran confianza en las que los propietarios de los recursos comparten sus credenciales directamente en la aplicación del cliente, no en el servidor de autenticación.

Esta concesión utiliza los siguientes roles:

Propietario del recurso : persona o sistema capaz de otorgar acceso a un recurso protegido.
Aplicación : un cliente que realiza solicitudes protegidas utilizando la autorización del propietario del recurso.
Servidor de autorización : el servidor de inicio de sesión único que emite tokens de acceso a las aplicaciones cliente después de autenticar correctamente al propietario del recurso.
Servidor de recursos : el servidor que aloja recursos protegidos y acepta y responde a solicitudes de recursos protegidos utilizando tokens de acceso. Las aplicaciones acceden al servidor a través de API.

Autenticar con nombre de usuario y contraseña :
El usuario se autentica con la aplicación utilizando su nombre de usuario y contraseña.
Enviar nombre de usuario / contraseña :
La aplicación envía el nombre de usuario y la contraseña al servidor de autorización para su validación.
Emitir token de acceso :
El servidor de autorización valida el nombre de usuario y la contraseña y emite un token de acceso.
Solicitar recurso con token de acceso :
La aplicación intenta acceder al recurso desde el servidor de recursos presentando el token de acceso.
Devolver recurso :
Si el token de acceso es válido, el servidor de recursos devuelve los recursos que el usuario autorizó a recibir a la aplicación

Se utiliza en aplicaciones si son confiables y no una third party.

Authorization code

Este flujo se caracteriza por la intervención del usuario para autorizar de forma explícita el acceso a sus datos por parte de la aplicación y por el uso de un código proporcionado por el servidor de autenticación para que la aplicación pueda obtener un access token.

Esta concesión utiliza los siguientes roles:

Propietario del recurso : persona o sistema capaz de otorgar acceso a un recurso protegido.
Aplicación : un cliente que realiza solicitudes protegidas utilizando la autorización del propietario del recurso.
Servidor de autorización : el servidor de inicio de sesión único que emite tokens de acceso a las aplicaciones cliente después de autenticar correctamente al propietario del recurso.
Servidor de recursos : el servidor que aloja recursos protegidos y acepta y responde a solicitudes de recursos protegidos utilizando tokens de acceso. Las aplicaciones acceden al servidor a través de API.

Aplicación de acceso :
El usuario accede a la aplicación y activa la autenticación y autorización.
Autenticación y solicitud de autorización :
La aplicación redirige al usuario al servidor de autorización donde solicita al usuario su nombre de usuario y contraseña. La primera vez que el usuario pasa por este flujo para la aplicación, el usuario ve una página de aprobación. En esta página, el usuario puede elegir permisos para autorizar a la aplicación a acceder a los recursos en su nombre.
Autenticación y concesión de autorización :
El servidor de autorización recibe la concesión de autenticación y autorización.
Enviar código de autorización :
Después de que el usuario autoriza la aplicación, el servidor de autorización envía un código de autorización a la aplicación mediante un redireccionamiento.
Solicitar intercambio de código para token :
La aplicación utiliza el código de autorización para solicitar un token de acceso del servidor de autorización. Esto le da a la aplicación acceso a los permisos aprobados.
Emitir token de acceso :
El servidor de autorización valida el código de autorización y emite un token de acceso.
Solicitar recurso con token de acceso :
La aplicación intenta acceder al recurso desde el servidor de recursos presentando el token de acceso.
Devolver recurso :
Si el token de acceso es válido, el servidor de recursos devuelve los recursos que el usuario autorizó a recibir a la aplicación.

Este flujo es el más utilizado ya que es para aplicaciones del lado del servidor.

Implicit

El tipo de concesión implícita es para aplicaciones con un secreto de cliente que no se garantiza que sea confidencial. Recibe el nombre de implícito porque toda la comunicación reside en el navegador, es decir, no hay un servidor backend. Se trata del flujo de OAuth menos seguro, de forma que su utilización debe limitarse a casos muy concretos.

Esta concesión utiliza los siguientes roles:

Propietario del recurso : persona o sistema capaz de otorgar acceso a un recurso protegido.
Aplicación : un cliente que realiza solicitudes protegidas utilizando la autorización del propietario del recurso.
Servidor de autorización : el servidor de inicio de sesión único que emite tokens de acceso a las aplicaciones cliente después de autenticar correctamente al propietario del recurso.
Servidor de recursos : el servidor que aloja recursos protegidos y acepta y responde a solicitudes de recursos protegidos utilizando tokens de acceso. las aplicaciones acceden al servidor a través de API.

Aplicación de acceso :
El usuario accede a la aplicación y activa la autenticación y autorización.
Autenticación y solicitud de autorización :
La aplicación solicita al usuario su nombre de usuario y contraseña. La primera vez que el usuario pasa por este flujo para la aplicación, el usuario ve una página de aprobación. En esta página, el usuario puede elegir permisos para autorizar a la aplicación a acceder a los recursos en su nombre.
Autenticación y concesión de autorización :
El servidor de autorización recibe la concesión de autenticación y autorización.
Emitir token de acceso :
El servidor de autorización valida el código de autorización y devuelve un token de acceso con la URL de redireccionamiento.
Solicitar recurso con token de acceso en :
La aplicación intenta acceder al recurso desde el servidor de recursos presentando el token de acceso en la URL.
Devolver recurso :
Si el token de acceso es válido, el servidor de recursos devuelve los recursos que el usuario autorizó a recibir a la aplicación.

El caso tipo es una aplicación de una sola página, generalmente en Javascript, que obtiene el access token sin pasar por un servidor entre medias y que no tienen forma de almacenar las claves de una forma segura