Categorías
IAM Seguridad

Gestión de Identidad y acceso. OAuth 2. 4 de 4

Y llegamos al último post, vamos a por un resumen de todo lo que hemos visto y le doy unas pinceladas a la seguridad.

Antes visto en el contador…

Resumiendo

OAuth es un protocolo que estandariza la delegación del acceso a aplicaciones. Como resultado la aplicación (un spa, un mvc, o una app nativa) obtiene un token que es utilizado para acceder a las APIs con los recursos.

Si estás desarrollando una aplicación, es más que probable que requieras de un sistema de gestión de usuarios, es decir un proveedor de identidad. Podrías desarrollar o adoptar uno, o usar uno de los sociales, Google ID, Facebook, Twitter, etc. Todos ellos disponen de OAuth para facilitar el proceso de integración con terceros.

Pero el especial interés de OAuth, como hemos dicho, es si requieres recibir una autorización del usuario para realizar acciones en su nombre, es decir, que el proveedor de identidad nos delegue la autorización del usuario para operaciones concretas a nuestra aplicación.

Por ejemplo, imagina que tu aplicación va a gestionar un calendario, una lista de tareas y generar informes, si utilizas las APIs de Google para este fin, tendrás mucho desarrollo solucionado y le darás al usuario una mejor experiencia, ya que a su vez estos servicios son accesibles desde otras aplicaciones. Para acometer esto, tendrás que configurar el PdI para que los usuarios de tu app autorice los scopes para escribir y leer en su calendario, sus tareas y sus documentos a tu app.

La experiencia de usuario será la siguiente

  1. Entrará en tu app, será redireccionado al PdI, se autenticará (usuario contraseña, SMS, un rezo a la virgen de las palabras olvidadas,…)
  2. El sistema le preguntará si estás seguro de querer delegar la autorización a la app de donde procede.
  3. Si acepta el consentimiento, la app tendrá el acceso, y podrá durante la sesión de usuario acceder a esos recursos e incluso cuando el usuario no este presente.

El resultado de esto es un token de acceso, los más comunes tienen un formato autocontenido, dispone en su interior toda la información del contexto y esta firmado por el proveedor. Comprobando la firma, se constata su autenticidad, pero su validez depende de los valores autocontenidos.

Authorization code flow

Este es el caso mas común, cuando disponemos de un usuario interactuando con la aplicación, pero como vimos, existe también la posibilidad de que sea una maquina la que solicite un token para hablar con otro servicio.

Client Credential Flow

Un poco de seguridad

Si alguien o algo obtiene este token, podrá suplantar la identidad del usuario, para evitar este mal, se deben tener en cuenta las siguientes medidas de seguridad, son todas desde el punto de vista del cliente.

  1. Tráfico deberá ir cifrado con TLS (https://…). ¡Como siempre!
  2. Utilizar para la implementación de una biblioteca confiable. https://openid.net/developers/certified/
  3. No implementar flujos implicit ni resource owner password. Solo Authorization Code + PKCE para flujos interactivos y Client Credential para flujos maquina a maquina.
  4. Hay muchos elementos de seguridad en el protocolo, mejor no ser muy creativos en la implementación. Debemos seguir las indicaciones de la biblioteca correctamente, si no, podríamos anular la correcta validación de la firma del token (vital) y de su caducidad (vital+), transmitirlos por GET (horroroso), almacenarlas mal (chungo), no utilizar correctamente state para evitar ataques CSRF (vaya), y un sin fin…
  5. Cuando configuremos el cliente, debemos intentar que el cliente sea siempre confidencial, es decir, que la obtención del token sea en back-channel utilizando un identificador y secreto de cliente. La mayoría de los proveedores ya lo están obligando.
  6. Si el flujo es interactivo, utilizar siempre PKCE, impedirá que una app malintencionada que haya obtenido el código de intercambio, pueda realizar la conversión de este por un token. Además nos protegerá contra CSRF. Doble Combo.
  7. Limitar específicamente las ubicaciones que pueden recibir la redirección con los resultados de la autorización. Esto se hace en el servidor alimentando correctamente una lista blanca de URIs de callback.
  8. Configurar CORS correctamente, desde que ubicaciones vamos a permitir solicitar token via Ajax
  9. Minimizar el tiempo de vida del token lo máximo posible y utilizar token de refresco si es necesario tener sesiones largas. Un token robado tendrá menos utilizada y además podremos revocar el acceso anulando el refresco.
  10. Rotación del token de refresco, si alguien lo roba al utilizarlo le entregará uno nuevo. En el momento que la app legitima lo intente utilizar… pues el servidor verá la inconsistencia y lo eliminará
  11. Que un auditor haga una prueba de intrusión para verificar la correcta implantación.

Conclusiones

OAuth se utiliza bastante, existe una evolución que se llama OpenId Connect, es básicamente una extensión del protocolo OAuth para incorporar la delegación de la autenticación… y esto es muy potente, ya que resolvemos tanto AuthN como AuthZ con un solo protocolo

Con esto entramos en otro nivel y más complejidad, ya podríamos hablar de Single-Sign On y sus necesarios y tan olvidados logouts distribuidos. De la administración de usuarios y sus claims de identidad.

Da para otra serie dedicada, quizás más adelante.

¡A darle caña!

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *