Identificadores de seguridad: autorización vs autentificación
El mundo ha cambiado mucho: cuando antes bastaba con un identificador y una contraseña, ahora utilizamos sistemas algo más sofisticados. En Identity Tokens Explained: Best Practices for Better Access Control hablan de los objetos de identificación identity tokens, como base para los mecanismos modernos de autentificación.
Identity tokens—particularly JSON Web Tokens (JWTs) and OpenID Connect tokens—can be considered the backbone of modern application security, as they enable most of the authentication solutions we’ve come to rely on.
La clave está en que, normalmente, una cosa es la gestión de la identidad y la autorización de lo que pueden hacer las aplicaciones.
This article will walk through what identity tokens are, the types of tokens you might encounter, and why you need to decouple authentication from authorization.
Todo ello desde el punto de vista de una solución concreta, que tampoco es muy relevante para lo que podemos aprender allí.
Estos objetos (valores, variables, …) permiten representar alguna forma de identidad dentro de entorno de alguna solución informática. Se trata de alguna información generada por un proveedor de identidad o un servicio de autentificación que la aplicación o servicio pueden validar y utilizar.
First off, when I say “identity tokens,” I’m referring to tokens intended to represent some form of identity—either a human user or a machine identity—within your software ecosystem. They’re basically a packet of information generated by an identity provider or authentication service, which your application or service can then validate.
Estamos hablando de protocolos comop OpenID Connector u OAuth 2.0 que generan típicamente cadenas de caracteres (strings) que codifican algunos detalles de identidad.
A common approach is to rely on a protocol such as OpenID Connect or OAuth 2.0 to manage these tokens. In these cases, the tokens can be short strings that encode vital identity details.
Esto nos permite delegar la confianza, sin manejar las credenciales del usuario directamente, lo que reduce la visibilidad y exposición de estas credenciales.
An interesting thing about identity tokens is how they let you delegate trust. When a user logs in through an identity provider, you don’t need to handle that user’s credentials directly. You can simply trust the identity token the provider generates, assuming you validate its signature.
Sin embargo, podemos tener la tentación de incluir en los objetos demasiada información, con lo que perdermos las ventajas de esta aproximación.
However, they’re far from all-encompassing, and if you try to cram every piece of user-related information into one token, you’re gonna have a bad time.
Luego detalla algunas características de algunos tipos de objetos de este tipo, como pueden ser los JSON Web Tokens (JWTs), OpenID Connect Tokens, Opaque Tokens, o diferentes Machine Identity Tokens / API Keys.
Las ventajas, además de la compartimentalización señalada arriba, tienen que ver con la simplificación a través de la centralización en la gestión de la autentificación, mientras se permite a las aplicaciones realizar su cometido.
That identity provider issues a token, and suddenly all your services know how to trust that user or machine without juggling credentials.
Se añaden otras ventajas como la escalabilidad, su estandarización, mecanismos de identificación única single sign-on, gestión del ciclo de vida/revocación, gestión consistente de las identidades….
Alguonos errores comunes tienen que ver con pedirles demasiado: por ejemplo, incluir ámbitos, conjutos de permisos, o información de estado más o menos complicada.
If you put entire permission sets or complicated state data into a token, you’re forcing a re-issuance of the token every time something changes. That’s not realistic for a dynamic environment, and it’s definitely not secure.
Esto puede ser hasta difícil, por las limitaciones de tamaño.
Tokens have practical limits on size. Some identity providers or networks even place limits on header sizes.
Otro problema puede tener que ver con la duración, que puede ser demasiado corta (y por lo tanto una molestia, o una sobrecarga para el proveedor de identidad) o demasiado larga (con los consiguientes riesgos de que ya no corresponda a lo que necesita el usuario, si es que todavía lo es).
A short-lived token might mean you’re validating everything on every request, hitting the identity provider too often, causing friction and performance bottlenecks. A long-lived token might stick around so long that you have no quick way to invalidate it if the user’s status changes. So you’re either locked into major performance overhead, or you risk giving out indefinite access.A short-lived token might mean you’re validating everything on every request, hitting the identity provider too often, causing friction and performance bottlenecks. A long-lived token might stick around so long that you have no quick way to invalidate it if the user’s status changes. So you’re either locked into major performance overhead, or you risk giving out indefinite access.
Otro problema puede tener que ver con la gestión de las sesiones interactivas (para los humanos) y las sesiones para los servicios (para las máquinas). Si las manejamos de forma diferente tendremos problemas de complejidad, confusión y divergencia en la gestión de las políticas de seguridad.
Sometimes teams think machine identities (service-to-service tokens) deserve a completely different approach than human tokens. While there can be some differences, if you diverge too far, you’ll cause confusion, complexity, and potentially misaligned security policies.
Por lo tanto, nuestros objetivos será:
- Desacoplar la autentificación de la autorización.
Decouple Authentication and Authorization
- Mantener los objetos sencillos
Keep Tokens Lean
- Utilizar protocolos estándar.
Use Standard Protocols
- Mantener un balance adecuado en la duración.
Balance Token Lifespan
- Disponer de mecanismos de revocación.
Plan for Token Revocation
También debemos tener en cuenta los aspectos de aseguramiento de los identificadores: utilizar HTTPs para que no pueda verlos nadie, tener cuidado al almacenarlos (cuidado con el registro de actividad, log), verificarlos, cambiarlos de vez en cuando por si alguien consiguiera robarlos, …
Además hay algunos casos de uso (identificación unificada, aplicaciones móviles, comunicaciones entre servicios, microservicios en la nube, …) y termina con algunas preguntas frecuentes.
Me ha gustado.