Identity, Authentication, and Access Management in OpenStack

Chapter 3. Token Formats

3.1 History of Keystone Token Formats

Keystone offers several token formats, and users may wonder why there are so many. To help with understanding why, we provide a brief history of how the Keystone token formats have evolved. In the early days, Keystone supported a UUID token. This token was a 32-character string bearer token used for authentication and authorization. The advantage of this token format was that the token was small and very easy to use, and it was simple enough to add to a cURL command. The disadvantage of this token is it did not carry with it enough information to locally do authorization. OpenStack services would always have to send this token back to the Keystone server to determine if an operation was authorized. This resulted in Keystone being pinged for any OpenStack action, and becoming a bottleneck for all of OpenStack.

In an attempt to address the issues encountered with UUID tokens, the Keystone team created a new token format called the PKI token. This token contained enough information to perform local authorization and also contained the service catalog in the token as well. In addition, the token was signed and services could cache the token and use it until it expired or was revoked. The PKI token resulted in less traffic to the Keystone server, but the disadvantage of this token was that they were huge. PKI tokens could easily be 8K in size, and this made them difficult to fit in HTTP headers. Many web servers could ...