🚨 OpenStack Error Guide: 'The request you have made requires authentication' (HTTP 401)

Overview

Keystone is the front door to OpenStack. Almost every API call — booting an instance, listing volumes, creating a network — first validates a token with Keystone. When that validation fails, the API returns HTTP 401 and a body that looks like this:

The request you have made requires authentication. (HTTP 401) (Request-ID: req-7f3c0a2e-9b1d-4c6e-bf2a-1c4e9d8a2b50)

This error occurs whenever the credentials or token presented to Keystone cannot be authenticated: the token is expired, malformed, or was signed by a Fernet key that no longer exists; the username, password, or project scope is wrong; the client’s clock is skewed far enough that a freshly issued token already appears expired; or auth_url/the identity endpoint points at the wrong place. Because every other service delegates auth to Keystone, a single 401 here will surface as failures across Nova, Neutron, Cinder, and Glance simultaneously.

Symptoms

• Every CLI command fails immediately with (HTTP 401), regardless of which service is targeted.
• Horizon redirects back to the login page or shows “Invalid credentials”.
• Service-to-service calls log Identity response: ... Unable to validate token.
• openstack token issue itself fails, proving the problem is authentication, not authorization.

openstack server list --debug

RESP: [401] Content-Type: application/json ... 
RESP BODY: {"error":{"code":401,"message":"The request you have made requires authentication.","title":"Unauthorized"}}
The request you have made requires authentication. (HTTP 401) (Request-ID: req-7f3c0a2e-9b1d-4c6e-bf2a-1c4e9d8a2b50)

Common Root Causes

1. Expired or invalid token

Cached tokens (in os_cache, Horizon sessions, or OS_TOKEN) outlive their TTL. The default Fernet token expiry is one hour.

openstack token issue

Failed to issue a token, or token expired:
The request you have made requires authentication. (HTTP 401)

If openstack token issue succeeds but a stored token fails, the cached token is simply stale — re-authenticate.

2. Wrong credentials or project scope

A mistyped password, a renamed project, or a user with no role on the requested project all produce a 401 (Keystone returns 401, not 403, when it cannot even scope you).

env | grep ^OS_
openstack --os-username admin --os-project-name admin token issue

The request you have made requires authentication. (HTTP 401)

Confirm the project still exists and the user has a role on it:

openstack role assignment list --user admin --project admin --names

+-------+---------------+--------+--------------+
| Role  | User          | Group  | Project      |
+-------+---------------+--------+--------------+
| admin | admin@Default | (none) | admin@Default|
+-------+---------------+--------+--------------+

An empty table means the user has no role on the project, so no scoped token can be issued.

3. Clock skew breaking Fernet tokens

Fernet tokens embed a creation timestamp. If the API node’s clock and the requesting host’s clock differ by more than the token lifetime, a brand-new token can appear already expired.

timedatectl status
chronyc tracking

System clock synchronized: no
NTP service: active
...
Leap status     : Not synchronised
Last offset     : +47.218394 seconds

A multi-second offset (here ~47s) on a Fernet deployment is enough to break short-lived tokens.

4. Wrong auth_url or identity endpoint

A typo in OS_AUTH_URL, an old v2.0 path, or a stale endpoint in the catalog sends auth requests to the wrong place.

openstack endpoint list --service identity

+----------------------------------+-----------+--------------+--------------+---------+-----------+------------------------------+
| ID                               | Region    | Service Name | Service Type | Enabled | Interface | URL                          |
+----------------------------------+-----------+--------------+--------------+---------+-----------+------------------------------+
| 0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d | RegionOne | keystone     | identity     | True    | public    | https://controller:5000/v3   |
| 1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e | RegionOne | keystone     | identity     | True    | internal  | https://controller:5000/v3   |
| 2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f | RegionOne | keystone     | identity     | True    | admin     | https://controller:5000/v3   |
+----------------------------------+-----------+--------------+--------------+---------+-----------+------------------------------+

OS_AUTH_URL must match one of these (the public URL for external clients).

5. Expired Fernet keys or botched key rotation

Fernet keys live in /etc/keystone/fernet-keys/. If rotation removed the primary key that signed currently active tokens, or the key repository got out of sync across controllers, every existing token fails validation.

docker exec keystone ls -la /etc/keystone/fernet-keys/
docker logs keystone 2>&1 | grep -i fernet | tail

-rw------- 1 keystone keystone 44 Jun 23 09:00 0
-rw------- 1 keystone keystone 44 Jun 23 08:00 1
...
ERROR keystone.token.providers.fernet ... Could not recognize Fernet token

Across an HA cluster all controllers must hold the same key set; a mismatch means a token issued by node A is rejected by node B.

6. Disabled user or disabled project

An admin can disable an account or project. Keystone refuses to issue or validate tokens for either.

openstack user show admin -c enabled -f value
openstack project show admin -c enabled -f value

False
True

A False on either line explains the 401.

Diagnostic Workflow

Step 1 — Confirm it’s authentication, not authorization

Run the most basic auth call. If this fails, the problem is squarely authentication.

openstack token issue

Step 2 — Inspect the client environment

Verify the variables the CLI is actually using, then re-source a known-good RC file.

env | grep ^OS_
source /etc/kolla/admin-openrc.sh
openstack token issue

Step 3 — Read the Keystone logs

Find the matching req-... ID from the failed call and trace it in Keystone.

# Kolla-Ansible (containerized)
docker logs keystone 2>&1 | grep req-7f3c0a2e | tail -20
# Package-based deployment
journalctl -u devstack@keystone --since "10 min ago" | tail -50
tail -50 /var/log/keystone/keystone.log

WARNING keystone.common.wsgi ... Authorization failed. The request you have made requires authentication.
INFO keystone.token.providers.fernet ... Failed to validate token

Step 4 — Check time sync and Fernet keys

Rule out clock skew and key-rotation damage.

chronyc tracking
docker exec keystone ls /etc/keystone/fernet-keys/

Step 5 — Verify the account and endpoint

Confirm the user/project are enabled and OS_AUTH_URL matches the catalog.

openstack endpoint list --service identity
openstack user show admin -c enabled -f value
openstack project show admin -c enabled -f value

Example Root Cause Analysis

Scenario. After a routine maintenance window, an operator reports that all OpenStack commands across the entire cloud started returning 401, even openstack server list from the admin host that worked an hour earlier.

Failing log. Keystone shows token validation failures for tokens issued only minutes before:

docker logs keystone 2>&1 | grep -i fernet | tail
ERROR keystone.token.providers.fernet [req-9d2e...] Could not recognize Fernet token
INFO  keystone.token.providers.fernet [req-9d2e...] Failed to validate token

Investigation. openstack token issue against controller01 succeeds; against controller02 it fails. That points to inconsistent state between controllers. Comparing the key repositories confirms it:

docker exec -it keystone-controller01 sha256sum /etc/keystone/fernet-keys/*
docker exec -it keystone-controller02 sha256sum /etc/keystone/fernet-keys/*

controller01: 0 -> 8f14...   controller02: 0 -> 2b9c...

The keys differ. During maintenance, keystone-fernet-rotate ran on controller01 only, and the new keys were never synchronized to the others. Tokens issued by controller01 with its new primary key are rejected by controller02, which still has the old key set — and the load balancer spreads requests across both.

Fix. Re-synchronize the key repository across all controllers and restart Keystone:

# Push controller01's authoritative key set to the other controllers, then:
kolla-ansible -i multinode reconfigure --tags keystone
# or, manually after syncing /etc/keystone/fernet-keys/ to every node:
docker restart keystone

After all controllers share an identical key set, a fresh openstack token issue succeeds on every node and the cloud-wide 401s clear.

Prevention Best Practices

• Automate Fernet key rotation with a single source of truth and push keys to all controllers atomically; never rotate on one node by hand. Re-run kolla-ansible reconfigure --tags keystone rather than editing in place.
• Enforce NTP everywhere and alert on offset. A simple check: chronyc tracking | awk '/Last offset/ {if (($4<-1)||($4>1)) exit 1}' flags any controller drifting more than a second.
• Monitor the Keystone error rate. Scrape docker logs keystone (or /var/log/keystone/keystone.log) for requires authentication and Failed to validate token and alert when the rate spikes — a cluster-wide jump almost always means key or clock trouble.
• Keep token TTL reasonable (the 1-hour default is sane) and avoid caching tokens longer than their lifetime in scripts.
• Rehearse credential rotation and validate OS_AUTH_URL against openstack endpoint list --service identity after any endpoint change.
• For recurring auth incidents, route alerts into a runbook-driven workflow such as the one at /dashboard/incident-response/ so the first responder gets the Keystone-specific checks automatically.

Quick Command Reference

# Confirm authentication vs authorization
openstack token issue

# Inspect and reset client credentials
env | grep ^OS_
source /etc/kolla/admin-openrc.sh

# Trace a failed request in Keystone
docker logs keystone 2>&1 | grep req-7f3c0a2e | tail -20
journalctl -u devstack@keystone --since "10 min ago" | tail -50

# Clock and Fernet key checks
chronyc tracking
timedatectl status
docker exec keystone ls -la /etc/keystone/fernet-keys/

# Verify identity endpoint and account state
openstack endpoint list --service identity
openstack user show admin -c enabled -f value
openstack project show admin -c enabled -f value
openstack role assignment list --user admin --project admin --names

Conclusion

An OpenStack “requires authentication” (HTTP 401) almost always traces back to one of:

1. An expired or stale cached token.
2. Wrong credentials or a user with no role on the requested project.
3. Clock skew that prematurely invalidates Fernet tokens.
4. A wrong auth_url or stale identity endpoint in the catalog.
5. Expired or out-of-sync Fernet keys after a botched rotation.
6. A disabled user or disabled project.

Work the diagnostic workflow top-down — prove it’s authentication, check the client, read Keystone’s logs, then verify time, keys, and account state. For more OpenStack troubleshooting guides, see /categories/openstack/.