Not knowing anything about the token properties in the Keystone database structure, I jumped into the database to expose a bit of the schema. What follows is a summary of my exploration as well as some recommendations we can use to ascertain its health.

First, here are the tables associated with the keystone database:

SHOW tables;

The user table has the following schema:

SHOW columns FROM user;

Each person that connects to the Keystone service is given an entry in the user database. How many have logged in?

SELECT count(*) AS users
FROM user;

Keep in mind that some of these entries are for the other OpenStack components and our CI accounts:

SELECT COUNT(*) as non_users
FROM user
WHERE extra LIKE '{"email": ""}';

An active user is given a token during the authentication process, and that record is stored in the token table. Here is its schema:

SHOW columns FROM token;

How many token entries are there at this time?

SELECT count(*) AS tokens
FROM token;

Is the expires timestamp something that can be in the past?

SELECT count(*) AS expired
FROM token
WHERE expires < NOW();

Clearly that is a lot of expired tokens. How old is the oldest expired token?

SELECT expires,
 (UNIX_TIMESTAMP(expires) - UNIX_TIMESTAMP(NOW()))/60 AS minutes_ago,
 (UNIX_TIMESTAMP(expires) - UNIX_TIMESTAMP(NOW()))/60/60 AS hours_ago
FROM token
ORDER BY expires DESC
LIMIT 1

That is almost 24 hours ago. Is that our policy? Actually, it is indeed a configurable policy. The default value is set to 24 hours, in case long running stories cache that token. If we think data storage is still an issue, we could lower that policy in order to force the excise of those expire tokens. If a system does cache it, the token can be renewed, or the script could be easily reset.

What is the token duration? According to the database entries, this would be the value with the greatest expires entry:

SELECT expires,
 (UNIX_TIMESTAMP(NOW()) - UNIX_TIMESTAMP(expires))/60/60 AS hours
FROM token
ORDER BY expires ASC
LIMIT 1

Since we can easily re-new a token, why is that value so large? How many tokens are expiring in the next ten minutes? Are those tokens from normal users or from the other cluster components?

SELECT user.name AS soon_to_expire
FROM token, user
WHERE
   user.id = token.user_id AND
   expires > NOW() AND expires < DATE_ADD(NOW(), INTERVAL 10 MINUTE);

Clearly, this will depend on the activity of our system. We have someone here with two tokens. How many tokens are assigned to active user account?

SELECT user.name, count(token.id) AS tokens
FROM token LEFT JOIN user
ON user.id = token.user_id
GROUP BY token.user_id
ORDER BY tokens DESC

I guess I can see why the neutron account has the most tokens, but normal user accounts seem to have quite a bit. Why? Are they expired?

SELECT user.name, count(token.id) AS expired_tokens
FROM token LEFT JOIN user
ON user.id = token.user_id
WHERE token.expires < NOW()
GROUP BY token.user_id
ORDER BY expired_tokens DESC

While it appears that most of the tokens are indeed expired, the non-expired tokens seem to be more than needed. But I guess that is just the OpenStack way.

The token table has a valid field that is either 1 or 0. How many tokens are invalid (equal to zero instead of one)? The OpenStack documentation describes this field as revoked:

SELECT count(*) AS invalid
FROM token
WHERE valid = 0;

Which user has these invalid tokens. Are invalid tokens also expired? No, since the expires field can be either greater or less than the current time:

SELECT name, expires,
   (UNIX_TIMESTAMP(NOW()) - UNIX_TIMESTAMP(expires))/60 AS minutes_when
FROM token, user
WHERE user.id = token.user_id AND valid = 0;

The revoked tokens can come about due to actually calling the Delete API on the token (even though I don’t remember doing anything like that with my account):

DELETE: /token/{token_id}

This API sets the valid field of token to false in the database (1). Then the token is now called a revoked token. The code for accessing and managing the revoked tokens are in keystoneclient.middleware.auth_token, so we might want to read the code to see the details.

Note: Token revocation is often a side effect of some other operation. For example, changing a password revokes all tokens issued prior to the password change. Removing a role assignment from a user revokes all tokens that have that role assignment.

Does someone with invalid or revoked tokens also have valid tokens?

SELECT count(*) as howards_tokens
FROM token, user
WHERE  token.user_id = user.id AND valid = 1
  AND  user.name = "howard.abrams"

I guess so….