Continuamos la serie, en este post vamos a afianzar conceptos (por el sofisticado, vanguardista, disruptivo método… eh, noooo, por repetición), también ampliaremos conocimientos, hablaremos de la ventana de consentimiento, de los tokens y de los claims.
En capítulos anteriores… Vimos cual es el sentido de emplear un proveedor de identidad externo y las ventajas de incluir una aplicación en él.
Recuerda que el proveedor de identidad externo nos va a resolver la identificación de los usuarios, y a su vez nos va a entregar un token de acceso con el que nuestra aplicación podrá realizar accesos en nombre del usuario… este token tiene unos scopes para los que será válido el token, que pueden ser solo relevantes para nuestra aplicación o también para acceder a recursos que dispone el propio proveedor de identidad.
Ok, importantísimo, si el usuario va a delegar el acceso a estos recursos bajo su identidad a nuestra aplicación, deberá aprobarlo/consentirlo expresamente. Esto es la…
Ventana de consentimiento
¿Te suena?
La aplicación ‘Google OAuth 2.0 Playground, pero bien podría ser la tuya, le esta diciendo al usuario que acaba de identificarse, que le va a entregar un token a la aplicación con el que va a poder ‘ver, editar, crear y borrar archivos en tu Google drive’… Si le das que sí, estás delegando la autorización en la aplicación. Podrá hacerlo en tu nombre.
¿Y esta?
En este otro caso, es el proveedor de identidad de Microsoft, si aceptas, la aplicación recibirá un token con el que tendrá acceso a tus ficheros, calendarios y perfil de usuario.
Aceptas y a continuación la aplicación recibe el…
Token de acceso
Sí todo ha ido bien, nuestra aplicación habrá recibido un token de acceso, con el, nos presentaremos a los recursos para demostrar que estamos autorizados, adicionalmente, también puede recibir un token de refresco.
Ya ves que hay varios tipos de token, pero el más popular es el JWT (Json Web Token), que es autocontenido, es decir, toda la información para verificar su validez reside en el mismo, no necesita repreguntar al proveedor de identidad. Salvo… para verificar su firma. Todo el token está firmado por el PdI y la API o el recurso que lo va a consumir debe descargarse la clave de firma y verificar que es correcta.
Su estructura es así, un cabecera con la info para general ( algoritmo de firma, etc), la sección donde contiene los datos de autorización y finalmente la firma del token. Si esta ha sido modificada o no es verificable… ¡algo malo/raro está pasando!
En el contenido de un token JWT es la chica del asador, comentamos el de la siguiente captura
Campos interesantes:
iss: es el proveedor que nos ha creado el token
sub: el identificador de usuario único dentro del proveedor, muy buena idea que sea aleatorio
aud: El recurso para el que tenemos delegada la autorización
iat, exp: fechas de creación de token y su tiempo de validez
scope: ¿Recuerdas la ventana de consentimiento? Pues aquí están los identificadores que consentimos.. leer y escribir
Podemos resumir que, cuando este token le lleve a un API o recurso, deberá comprobar que:
- Procede de un sitio de confianza. ISS conocido y el token correctamente firmado
- Que no ha caducado (iat, exp)
- Es para ella (aud) y que que puede acceder a (scope)
- Y finalmente si (sub) debe o no debe
Si todo ha ido bien, ¡Barra libre!
¿Y si ha caducado?
pues hay dos opciones,
- volver a solicitar que el usuario demuestre su identificación obteniendo un nuevo token
- O utilizar el token de refresco, si esta disponible y es valido. Es un token para obtener otro token de acceso. Una de las diferencias es que no es autocontenido y se debe verificar contra el PdI para usarlo.
Existe una web muy popular para ver estos decodificar estos tokens de acceso
Claims
Aquí tenemos otro ejemplo de token JWT, para explicar un nuevo concepto, los claims.
¿Ver el la entrada ‘roles’?, pues eso es un claim, pero otro podría ser:
{
...
"apertivofavorito": ["vermu", "gambitas", "aceituras" ],
"telefono": 123456789,
...
}es información adicional que es agregada el token, y por lo tanto firmada, la cual podremos explotar para nuestra conveniencia, en el caso de la captura, el proveedor se ha tomado la molestia de perfilarnos el usuario en roles, con lo cual, nuestra aplicación podría aprovecharse de este conocimiento. El usuario tiene el rol de admin. ?
Conclusiones
- El usuario debe aprobar expresamente a que recursos va a conceder el acceso a la aplicación que los solicita
- Si todo va bien, obtienes un token de acceso y quizás uno de refresco. Con el te presentarás ante los recursos para demostrar que tienes el acceso.
- Estos token, suelen ser autocontenidos y pueden albergar información adicional que ayuden a perfilar al usuario o la aplicación… ¡pero no se debe abusar!
- El token autocontenido debe tener una validez limitada en el tiempo, ya que si no, es difícil revocar el acceso si surge la necesidad.
¿Próxima parada?, ¿entraremos en el protocolo y quizás un ejemplo?
¡A darle caña!