Arquitecturas basadas en Microservicios: Seguridad – OAuth

Con la explosión de las aplicaciones web y la necesidad de comunicarse entre ellas surgió una problemática de seguridad. Si una aplicación quería que otra hiciese uso de sus servicios, en nombre de uno de sus usuarios, era necesario que ésta conociese tanto el nombre de usuario como su contraseña.

Eso planteaba un problema grave de seguridad, lo que propició el nacimiento del protocolo de autenticación OAuth (Open Authorization). Rápidamente se popularizo su uso pero, debido a la complejidad de la implementación en su primera versión, rápidamente se evolucionó al protocolo en uso hoy en día, OAuth2.

En una sola frase, lo que implementa el protocolo OAuth2, es la posibilidad de representar a un usuario mediante un token y que todos los implicados puedan validar que, efectivamente, ese token representa al usuario y es válido.

Si queréis leer en detalle todo lo relacionado con el protocolo podéis hacerlo aquí.

Actores clave del protocolo OAuth2

Para el caso que vamos a explicar, vamos a centrarnos en definir los actores clave dentro del protocolo, así como en la implementación a realizar dentro de un desarrollo orientado a microservicios.

Dentro de una autenticación OAuth existen los siguientes actores:

  • Resource Owner: Propietario de recursos. Es el usuario (o una aplicación en su nombre) que cuenta con la propiedad o el acceso a los recursos que quiere acceder.
  • Client: Aplicación cliente, es la encargada de realizar las peticiones en nombre del resource owner, el cliente será el encargado de realizar todas las peticiones necesarias para comprobar que efectivamente el que está haciendo uso de él es el resource owner.
  • Authorization Server: Servidor de autorización. Es el encargado de verificar las credenciales del resource owner y en caso de ser correctas emitir los tokens que representan a los usuarios.
  • Resource Server: Servidor de recursos. Es el servicio o servidor que contiene los recursos protegidos, debe de poder comunicarse con el servidor de autorización para poder validar si la petición de acceso a sus recursos es valida o no.

Existen infinidad de posts en internet explicando estos conceptos en detalle. Os dejamos una referencia a los que nosotros consideramos más interesantes y pasamos a describir el caso de uso que corresponde al uso de OAuth dentro de una serie de microservicios.

Para la explicación supongamos que tenemos a un usuario llamado Luis que intenta acceder a nuestro servicio de cuentas. Por la tanto tenemos al Resource Owner (Luis) al cliente que es nuestro frontal basado en JavaScript (App JS) y nuestros 2 microservicios: account-service (Resource Server) y auth-service (Authorization Server).

Inicialmente la App JS intentará acceder al account-service a petición de Luis. El servicio comprobará que todavía no tiene un token válido que represente a Luis y comunicará al cliente que no tiene acceso.
Cuando la App JS reciba la respuesta, obtendrá las credenciales de Luis y se las enviará al auth-service para que las valide. Si estas son correctas, el auth-service generará un token que represente a Luis y se lo enviará al cliente.

El cliente, una vez recibido el token, realizará de nuevo la petición a account-service, pero esta vez incluirá el token que indique que es Luis el que está realizando dicha petición. Account-service validará el token contra auth-service y si este le devuelve que el token es correcto, account-service dará acceso a Luis para acceder a los recursos de su servicio a través de dicho cliente.
Como habéis visto, el uso de OAuth2 nos permite poder acceder a los recursos de cada uno de los servicios ofrecidos por nuestros microservicios sin tener que autenticarnos en cada uno de ellos. Además, la autenticación tiene en cuenta el cliente que estamos utilizando, por lo que nos posibilita establecer diferentes niveles de seguridad dependiendo del cliente.

El único inconveniente que podríamos encontrar es que los servidores de recursos cuentan con la dependencia de tener que conocer y poder acceder al servicio de autorización. Para ello, en nuestras próximas entradas hablaremos del uso de tokens autofirmados y envueltos como tokens JWT.

¡Feliz Desarrollo!

Referencias

≡   Conceptos básicos de OAuth2   ≡   Guía sobre OAuth2   ≡