トークンは、ユーザーの資格情報、キーストーンのアプリケーションに到達するために、正しいユーザー名/パスワードを取る必要があります。OpenStackのAPIにアクセスするためのユーザー名/パスワードを使用して、ユーザーごとに場合は、簡単なユーザー情報、セキュリティ上のリスクを開示します。OpenStackのそれはそのAPIにアクセスするユーザーを必要とする前に、あなたは最初のトークンを取得し、その後、アクセスOpenStackのAPIへのユーザーの資格情報としてトークンを使用する必要があります。
1.UUID認定の原則
ユーザーが（仮想マシンを作成し、そのようなアクセス新星として）動作する必要がある場合は、キーストーンを行くために有効なユーザ名/パスワード認証を保持しているユーザーは、キーストーンは、ユーザートークン（すなわちUUID）に戻りました。ユーザが実行した後に（例えばアクセスノヴァのような）その他の動作は、最初のトークンは、トークン検証要求先キーストーンを使用するように、要求の受領後新星-API、新星に提示します。比較キーストーン有効なトークンにより、トークンとチェックは、トークンの有効性を判断し、新星に結果を返します
欠陥：各要求は、パフォーマンスのボトルネックを引き起こし、キーストンによって検証されなければなりません
1。キーストーンに送信されたユーザ名・パスワード
2。クライアントに送信されたキーストーンのユーザー名とパスワードの認証、および（UUID）トークンを生成し、
3。クライアント側のキャッシュUUIDトークン
4。クライアントは、キーストーンに、特定の実行要求（新星ブート）とUUIDを送ります
5。HTTPリクエストからトークンを取得し、トークンのチェックキーストンが有効です
6。有効なトークン、要求を処理し、クライアントの要求の結果を返します。
7。トークンの失敗、401を返し、クライアントの要求を拒否
UUID方法ソースコード解析：
ランダムな文字列であるトークンUUID）は、32バイトの固定長を有する。Hexがuuid.uuid4によって生成されました（
デフ _get_token_id（自己、token_data）： リターン uuid.uuid4（）進。
生成されたサンプル：144d8a99a42447379ac37f78bf0ef608
2.PKI認定の原則
初期化キーストーンは、キーストーンCA.pem CAの公開鍵と秘密鍵CA.keyを生成する場合、キーストーンは、自身の公開鍵と秘密鍵keystone.pubのkeystone.keyを生成しながら、その後、CAの署名もkeystone.pub keystone.pem生成
ユーザーがキーストーンへのユーザ名/パスワード認証を保持している場合は、キーストーンの基本的なユーザー情報がkeystone.keyにより暗号化され、暗号文をトークンとしてユーザーに返されます。以前に台形証明keystone.pem（一度だけこのプロセスは）ユーザ情報を取得する復号取得することにより、ユーザは、時間（例えば、アクセスノヴァ）を保持するトークン要求を送信し、ノヴァは、ユーザトークンを取得すると
ユーザーのトークンのために、時間は、トークンの判断があるかどうかも正当なトークンを実施するために必要な、と。トークンリストを取得するように依頼するためにあらゆる新星の必要性はキーストーンにトークンを失敗したときに、トークンが無効で確認してください。負荷のキーストーンのためのプロセスはまだ非常に軽いので、PKIは、効果的にキーストーンパフォーマンスのボトルネックの問題を解決しました。
概要：OpenStackのサービスの各APIエンドポイントは失効リストとルート証明書によって発行されたキーストーンの証明書を持っています。APIはちょうど、正当なものであるトークン認証におけるキーストーンに直接移動し、証明書失効リストのキーストーンをもとにしていないトークンが正当なものであるかを決定することができます。しかし、それでもまだ、必然的な動作不良のリストを取得するたびに要求キーストンが必要となります
PKI処理、CA、次のようにコードが関連付けられているトークン機構、pki_setupコマンドジェネレータ台形-管理を使用する最初の必要性：
def _get_token_id(self, token_data): try: token_json = jsonutils.dumps(token_data, cls=utils.PKIEncoder) token_id = str(cms.cms_sign_token(token_json, CONF.signing.certfile, CONF.signing.keyfile)) #DEFAULT_TOKEN_DIGEST_ALGORITHM=sha256
其中，‘token_data’是获取的user、role、endpoint、catlog等信息集合,而最重要的语句是cms使用签名生成token的过程：cms_sign_token，使用默认的sha256方式加密，处理过程使用process，进行数据的读取、处理，
process = subprocess.Popen(['openssl', 'cms', '-sign', '-signer', signing_cert_file_name, '-inkey', signing_key_file_name, '-outform', 'PEM', '-nosmimecap', '-nodetach', '-nocerts', '-noattr', '-md', message_digest, ], stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE, close_fds=True)
最后output, err = process.communicate(data) 生成Token-id,这个过程涉及到openssl相关的加密技术
CMS token一般都超过1600个字节，样例：
3.Fernet认证原理
1.user在客户端输入用户名密码，发送给keystone
2.Keystone验证用户名密码，并且生成token（UUID），发送给客户端
3.客户端缓存token(UUID)
4.客户端发送具体的执行请求给openstack API
5.OpenStack API向 keystone请求token认证
6.Keystone从http请求中获取token，并检查token是否有效
7.Token有效，处理请求，并返回openstack api请求结果
8.Token失效，拒绝客户端请求，返回401
当集群运行较长一段时间后，访问其 API 会变得奇慢无比，究其原因在于 Keystone 数据库存储了大量的 token 导致性能太差，解决的办法是经常清理 token。为了避免上述问题，社区提出了Fernet token，fernet 是当前主流推荐的token格式，它采用 cryptography 对称加密库(symmetric cryptography，加密密钥和解密密钥相同) 加密 token，具体由 AES-CBC 加密和散列函数 SHA256 签名。Fernet 是专为 API token 设计的一种轻量级安全消息格式，不需要存储于数据库，减少了磁盘的 IO，带来了一定的性能提升。为了提高安全性，需要采用 Key Rotation 更换密钥
以上代码表明，token 包含了 user_id，project_id，domain_id，methods，expires_at 等信息，重要的是，它没有 service_catalog，所以 region 的数量并不影响它的大小。self.pack() 最终调用如下代码对上述信息加密：
该token 的大小一般在 200 多 Byte 左右，样例：
gAAAAABWfX8riU57aj0tkWdoIL6UdbViV-632pv0rw4zk9igCZXgC-sKwhVuVb-wyMVC9e5TFc7uPfKwNlT6cnzLalb3Hj0K3bc1X9ZXhde9C2ghsSfVuudMhfR8rThNBnh55RzOB8YTyBnl9MoQ XBO5UIFvC7wLTh_2klihb6hKuUqB6Sj3i_8
简要叙述一下fernet采用 Key Rotation 更换密钥的原理，默认的轮换长度是3，当以keystone-manage fernet-setup生成密钥时，会看到0、1两个索引表征，这分别是什么意思呢？
在此，需要提一下三个概念：
primary key（主密钥）有且只有一个，名为为x，当前用于加密解密token
secondary key（次次密钥）有x-1个，从Primary退役下来的，用于解密当初它加密过的token
staged key（次密钥）有且只有一个，命名为0，准备下一个rotation时变为Primary key，可以解密token
那么上述0 表示的是staged key，1 表示的是primary key，
primary key相比较另外两种key，它的索引最高，并且可以加密、也可以解密；
staged key 相较于secondary key，它更有机会变为primary key
AES256加密token，SHA256 HMAC验证完整性，
只要Keystone具有访问这些key的权限，token就不需要在keystone数据库中存储
fernet的数据性能最好，原因是它不需要后端持久化操作(采用 Key Rotation定期 更换密钥,只要Keystone具有访问这些key的权限，更新后的token就不需要在keystone数据库中存储,缓解了数据库负载压力)，并且token的认证，使用的是密钥进行解密，能够直接得出token Data的信息，从而进行token的过期认证。它的失败原因，只可能是token过期了，或者是token放到了cache缓存中，但是已经被回收了。归根到底，还是token过期了
参考链接：