Este 3 de 4 va a ser durillo, vamos a por la chicha, hay conceptos que me temo que no se pueden llegar a entender en profundidad hasta que te peleas con ellos y pierdes muchas veces. ? Voy a tratar de explicarlos lo más sencillamente posible y agregaré alguno de mis dibujillos.
En capítulos anteriores…
¡Vamos allá!
Clientes y tipos
El concepto de cliente en OAuth no va relacionado con los usuarios, sino con la aplicaciones, es una aplicación que realiza solicitudes de recursos protegidos en nombre del propietario del recurso y con su autorización.
Por ejemplo, una aplicación web, una app de móvil, un dispositivo IoT… son clientes, detrás puede haber usuario o no.
Se dice que un cliente es público cuando el servidor de autorización no puede autenticar a la aplicación y confidencial cuando si puede hacerlo. Me explico, si tengo una aplicación Server Side (WordPress por ejemplo) donde la configuración esta en el servidor y no puede ser leída por un usuario, nos permitiría decir que es un cliente confidencial. Sin embargo, en una aplicación SPA que hace uso de un API, toda su configuración va a terminar en el navegador, será accesible por el usuario y se trata de un tipo público.
Y ahora los tipo de clientes más evidentes y que suelen ser por los nos solemos referir, Clientes con usuario interactivos, que son en los que se requiere que una persona se identifique y acepte el consentimiento y Clientes no interactivo, cuando en lugar de una persona, hay una maquina detrás, por ejemplo un dispositivo IoT o un servicio automatizado accediendo a un recurso para traerse datos que procesar
Uffff, Hay un par de tipos más, ¡pero ya vale de clientes!
Endpoints
Los servidores OAuth exponen varias rutas de operación, nos vamos a centrar en las dos más importantes, Authorization endpoint y Token endpoint. Si estas integrándote con un servidor OAuth, tarde o temprano tendrás que hablar con estos dos punto de acceso, por ejemplo:
- https://svr.com/oauth/authorize
- https://svr.com/oauth/token
El primer endpoint será siempre necesario cuando estemos trabajando con un flujo interactivo, es donde le contaremos al servidor que aplicación somos y que le pida al usuario lo que necesite para autenticarlo. Lo normal es que se produzcan las redirecciones al login de usuario, al MFA y después a la ventana de consentimiento, si todo va bien, este endpoint le devolverá a la aplicación (cliente) un código que demuestra que el usuario es quien dice ser. ¡pero este código sirve de poco! tendrás que correr para convertirlo en un token de acceso.
Esta operación es en front channel, siempre pasa por la capa del usuario.
Con el segundo endpoint, /token, obtendremos el token de acceso, o bien JWT o referencia y adicionalmente el de refresco. ¿Cómo?, ok:
- Si eres un máquina. Pues lo llamarás directamente, le dirás que aplicación eres, ClientId, y un secreto, ClientSecret, y el este de devolverá los tokens. Como ves este tipo de cliente es confidencial, el secreto debe estar bien custodiado.
- Y si eres un humano, pues tendrás que llamarlo pasándole el código obtenido con el endpoint anterior y te devolverá los tokens. Pero esto puede ocurrir de dos formas, ¿El cliente puede custodiar un secreto? Es decir, ¿Es un cliente confidencial? Si, pues entonces esta operación la realizaremos en back channel, la conversión de código a token la realizará el backend sin pasar por el usuario. Si esto no es posible, por ejemplo en las aplicaciones móviles, se llama al /token únicamente con el código sin hacer uso de un secreto. Esto es menos seguro… Siempre hay que valorar la posibilidad de crear un endpoint en nuestros servidores que se encargue de esta back channel.
Flujos
Con lo que hemos comentado hasta ahora, ya podríamos deducir los flujos de trabajo del protocolo, ahora mismo, solo hay que aprenderse dos, el resto han quedado deprecated
Authorization Code Flow
Cuando el cliente es interactivo, el usuario esta esta en el centro del meollo usaremos este flujo. El usuario tendrá que demostrar su identidad.
Para reforzar la seguridad, especialmente el punto en el que convertimos el código en un token y bajo el vector de ataque de que software malintencionado se haga con este código e intente convertirlo por nosotros, se agrega al protocolo el PKCE (pissssiiii). Básicamente es mantener un secreto cifrado en la primera llamada y que cuando se realize el intercambio del código, el malo no debería ser capaz de proporcionarlo.
https://medium.com/@software_factotum/pkce-public-clients-and-refresh-token-d1faa4ef6965
Client credentials
Y cuando el cliente es una maquina o servicio no interactivo: flujo Client credentials.
Implicit y Password Resource Owner
Existían más flujos, pero han quedado obsoletos y el protocolo los está eliminando, Password resource owner y Implicit
Revocación de token
Un punto importante en la seguridad de la identidad es tener claro como se comporta el sistema en los momentos críticos, por ejemplo si necesitamos revocar a un usuario que este abusando malintencionadamente del sistema. ¿Qué posibilidades tenemos?
¿Cómo podemos revocar un token JWT? Pues malamente, como ya hemos comentado es autocontenido, por lo tanto no queda otra que esperar a que caduque su validez. Cuando caduca, el usuario intentará obtener otro o la aplicación intentará renovar utilizando del de Token de Refresco, es aquí donde podremos actuar, bien bloqueando al usuario para que no pueda obtener nuevos tokens o eliminando el token de refresco vigente.
Una posible estrategia es entregar token JWT con un tiempo de vida bajo y un token de refresco que siempre podremos caducar bajo demanda.
Otra estrategia, menos usada, pero que es la que mas me gusta en entorno donde se requiera la máxima seguridad, es no entregar token JWT, sino tokens de referencia, es decir un hash que representa al token de JWT que se guarda en el servidor, mas o menos, con esto se gana que siempre se ha de verificar el token, además el token no aporta ningún dato, ni claims, no scopes. En contra, va a requerir que el servicio de autenticación trabaje mas intensamente para realizar todas las validaciones.
Conclusiones
Este video del gran Dominick Baier, recopila casi todos los conceptos de los que hemos hablado y el señor es un crack… ¡Así que disfrútalo!
El post final y último, haremos un ejemplo de cada, repasando lo que ocurre en front y back channel paso a paso. Creo que va a ser lo más diferencial de esta serie respecto a otras que encontrará por ahí.
¡A darle caña! ?