Un Capability Token, también conocido como 'capability' o 'ticket', es un mecanismo de seguridad que implementa el principio de la capacidad (capability-based security). A diferencia de los sistemas de control de acceso basados en listas (ACLs) o roles (RBAC), donde la autorización se verifica contra una política centralizada, un Capability Token es un objeto que intrínsecamente confiere derechos. Es un token opaco, normalmente criptográficamente firmado o generado de forma que no puede ser falsificado ni modificado por un cliente, que encapsula la identidad del recurso, la acción permitida y, opcionalmente, el alcance o las condiciones de uso. Su posesión es suficiente para demostrar la autorización, eliminando la necesidad de una verificación de permisos en cada solicitud.
La implementación de Capability Tokens se observa en varios sistemas distribuidos y de seguridad. Un ejemplo clásico son los 'tickets' de Kerberos, que son tokens de servicio que otorgan a un cliente la capacidad de acceder a un servicio específico. En el ámbito de la web, los JSON Web Tokens (JWT) pueden ser utilizados como Capability Tokens cuando se firman adecuadamente y se usan para autorizar el acceso a APIs o microservicios, donde el payload del JWT describe las capacidades otorgadas. Sistemas de archivos distribuidos como Tahoe-LAFS utilizan 'capabilities' para controlar el acceso a archivos y directorios, donde una 'read capability' permite leer, una 'write capability' permite escribir, etc. También son fundamentales en algunos diseños de sistemas operativos basados en microkernels, donde los 'capabilities' controlan el acceso a objetos del kernel.
Para un arquitecto de sistemas, los Capability Tokens son cruciales por su capacidad de simplificar la lógica de autorización y mejorar la escalabilidad y la seguridad. Al delegar la autorización a la posesión del token, se reduce la carga en los servicios de recursos, que solo necesitan validar la autenticidad del token, no consultar una base de datos de permisos. Esto es particularmente valioso en arquitecturas de microservicios. Sin embargo, presentan trade-offs: la revocación de tokens puede ser compleja si no se diseñan con mecanismos de expiración cortos o listas de revocación distribuidas. Además, la gestión segura de los tokens (almacenamiento, transmisión) es fundamental, ya que su compromiso implica el compromiso de las capacidades que otorgan. La elección entre un sistema basado en capacidades y uno basado en ACL/RBAC depende de la granularidad de control requerida, la dinámica de los permisos y la topología del sistema distribuido.