Understanding OpenStack Keystone Authentication and Token Workflow

Today we dive into each service component of OpenStack, starting with the important Keystone component.

First, consider typical enterprise authentication scenarios.

Business system authentication diagram

The diagram shows a common model where each business system maintains its own user database; this leads to fragmented user management and inconsistent permission control.

Unified authentication diagram

By centralising user information, each system can query a single source for authentication, but independent permission control still remains.

OpenStack component authentication flow diagram

OpenStack follows a “high cohesion, low coupling” design: each component provides specific functions and communicates via standard endpoints.

In OpenStack, each service component (e.g., Nova, Glance, Neutron) behaves like an independent business system, but they cannot be used separately because they rely on the overall OpenStack architecture.

Nova manages the VM lifecycle, Glance stores VM images, and Neutron handles networking. These components are tightly coupled through Keystone.

Although you could replace the underlying technologies (e.g., KVM for compute, GlusterFS for storage, VxLAN for networking), you cannot build a standalone product by using only Nova, Glance, or Neutron without the rest of the OpenStack stack.

Keystone provides the 3A model—Authentication, Authorization, Accounting—across the whole OpenStack environment.

During a typical workflow, the user submits a username and password, Keystone returns a token, and the token is used for all subsequent service calls, making the process transparent to the front‑end user.

Keystone release timeline

Keystone was introduced in the Essex release of OpenStack and provides unified authentication services, token issuance and validation, service catalog, and role‑based access control.

Key concepts include User, Credentials, Authentication, Token, Tenant, Service, Endpoint, and Role.

Keystone core concepts mind map

Below is a simple VM creation example that illustrates the Keystone workflow.

Keystone workflow diagram

1. The user sends authentication credentials (username and password).

2. Keystone checks its MySQL database, validates the credentials, and returns a token.

3. After a successful GUI login, the user initiates a VM creation request, which is sent to the Nova service together with the token.

4. Nova asks Keystone to verify the token and the permission to create a VM.

5. Upon successful verification, Nova contacts Glance for the base VM image, also presenting the token.

6. Glance validates the token with Keystone before providing the image.

7. Glance returns the image to Nova, which creates a new *.qcow2 image for the VM.

8. Nova then requests network configuration from Neutron, again including the token.

9. Neutron validates the token with Keystone before configuring networking.

10. After Neutron completes its work, it reports back to Nova; this whole sequence is invisible to the front‑end user.

11. Nova reports the successful VM creation to the GUI, completing the process.

Two common error responses can appear in the Keystone flow:

1. A 401 error indicates an invalid token.

2. A 503 error indicates that Keystone is unable to service the request.

Summary: Understanding token‑based authentication in OpenStack clarifies the 3A control model; the token replaces repeated username/password exchanges, enhancing security and simplifying cross‑component permission checks.

Token‑based authentication also mirrors the AK/SK mechanism used by public clouds such as Alibaba Cloud and Baidu Cloud, where an Access Key and Secret Key act as credentials to access service endpoints.

Alibaba Cloud AK/SK generation page

Baidu Cloud AK/SK generation page

Both clouds use the generated AK/SK as a manual token that, together with the service endpoint, enables API access similar to OpenStack's token mechanism.

Source: adapted from “Zhang Jia Da Gong Zi”.