Once a user is authenticated, a token is generated for authorization and access to an OpenStack environment. A token can have a variable life span; however the default value for expiry is one hour. The recommended expiry value should be set to a lower value that allows enough time for internal services to complete tasks. In the event that the token expires before tasks complete, the cloud may become unresponsive or stop providing services. An example of expended time during use would be the time needed by the Compute service to transfer a disk image onto the hypervisor for local caching. Fetching expired tokens when using a valid service token is allowed.

Belirteç, çoğu zaman bir Kimlik servisi yanıtının daha geniş bir bağlamının yapısı içinde geçirilir. Bu yanıtlar aynı zamanda çeşitli OpenStack servislerinin bir katalogunu sağlar. Her servis kendi adıyla, dahili, yönetici ve genel erişim için erişim uç noktaları ile listelenir.

Tokens can be revoked using the identity API.

In the Stein release, there are two supported token types: fernet and JWT.

Neither fernet or JWT tokens require persistence. The keystone token database no longer suffers bloat as a side effect of authentication. Pruning of expired tokens happens automatically. Replication across multiple nodes is also no longer needed. As long as each keystone node shares the same repository, tokens can be created and validated instantly across all nodes.

Fernet belirteçleri

Fernet tokens are the supported token provider for Stein (default). Fernet is a secure messaging format explicitly designed for use in API tokens. They are lightweight (fall in range of 180 to 240 bytes) and reduce the operational overhead required to run a cloud. Authentication and authorization metadata is neatly bundled into a message packed payload, which is then encrypted and signed in as a fernet token.

JWT tokens

JSON Web Signature (JWS) tokens were introduced in the Stein release. Compared to fernet, JWS offer a potential benefit to operators by limiting the number of hosts that need to share a symmetric encryption key. This helps prevent malicious actors who might already have a foothold in your deployment from spreading into additional nodes.

Further details on the differences between these token providers can be found here