In some cases, such as when deploying services or building Terraform providers, it is desirable to have a persistent token that can be used to access resources. Token storage is generally risky, however, and opaque tokens present auditability barriers in terms of knowing what exactly a token confers access to.
One way to resolve these issues is to support the minting of persistent tokens, bound to a subject and tenant, which themselves must still be exchanged in identity-manager-sts for tokens consumable by backend resources. In this model, the only information about the token that the service would need to retain is an identifier (likely the value of a jti claim) that could be stored in a revocation list to prevent revoked tokens from being exchanged.
The outcome of this issue will hopefully be a model and PR for minting such tokens via the management API.
In some cases, such as when deploying services or building Terraform providers, it is desirable to have a persistent token that can be used to access resources. Token storage is generally risky, however, and opaque tokens present auditability barriers in terms of knowing what exactly a token confers access to.
One way to resolve these issues is to support the minting of persistent tokens, bound to a subject and tenant, which themselves must still be exchanged in identity-manager-sts for tokens consumable by backend resources. In this model, the only information about the token that the service would need to retain is an identifier (likely the value of a
jticlaim) that could be stored in a revocation list to prevent revoked tokens from being exchanged.The outcome of this issue will hopefully be a model and PR for minting such tokens via the management API.