In layman's terms, a token is a user's credential, which can only be obtained by applying to Keystone with the correct username/password. If users use username/password to access OpenStack API every time, it is easy to leak user information and bring security risks. Therefore, OpenStack requires users to obtain a token before accessing its API, and then use the token as user credentials to access the OpenStack API.
UUID type
In version D, there are only UUID type tokens. UUID tokens are easy to use, but it is easy to bring performance problems to Keystone.
UUID token is a random string with a fixed length of 32 Bytes, generated by uuid.uuid4().hex.
PKI type
Before describing PKI (Public Key Infrastruction) tokens, let's briefly review public-key cryptography and digital signatures. Public key encryption, also known as asymmetric encryption (the encryption key and the decryption key are not the same), in this cryptography method, a pair of keys are required, namely the public key and the private key. Compared with UUID, PKI token carries more user information and also attaches a digital signature to support local authentication, thereby avoiding took step 4
PKIZ type
PKIZ performs compression processing on the basis of PKI, but the compression effect is extremely limited. Generally, the compressed size is about 90% of the PKI token, so PKIZ cannot amicably solve the problem of too large token size.
Fernet token type
The community proposed Fernet token, which uses the cryptography symmetric encryption library (symmetric cryptography, the encryption key and decryption key are the same) to encrypt the token, which is specifically signed by AES-CBC encryption and hash function SHA256. Fernet is a lightweight secure message format specially designed for API tokens. It does not need to be stored in the database, which reduces the IO of the disk and brings a certain performance improvement. In order to improve security, it is necessary to use Key Rotation to replace the key.
Several commonly used authentication mechanisms
HTTP Basic Auth
The simple description of HTTP Basic Auth is to provide the user's username and password every time the API is requested. In short, Basic Auth is the simplest authentication method used with RESTful API. It only needs to provide the username and password. The risk of exposing usernames and passwords to third-party clients is less and less used in production environments. Therefore, when developing an open RESTful API, try to avoid using HTTP Basic Auth
OAuth
OAuth (Open Authorization) is an open authorization standard that allows users to allow third-party applications to access private resources (such as photos, videos, contact lists) stored by the user on a web service without providing a username and password to third-party applications.
OAuth allows users to provide a token instead of a username and password to access their data stored with a specific service provider. Each token authorizes a specific third-party system (eg, a video editing website) to access a specific resource (eg, just a video in a certain album) for a specified period of time (eg, within the next 2 hours). In this way, OAuth allows users to authorize third-party websites to access some specific information they store with another service provider, but not everything.
Here is the flow of OAuth 2.0:
This OAuth-based authentication mechanism is suitable for personal consumer Internet products, such as social apps and other applications, but it is not suitable for enterprise applications with their own authentication authority management;
Cookie Auth
The cookie authentication mechanism is to create a Session object on the server side for a request authentication, and at the same time create a Cookie object on the client's browser side; state management is achieved by bringing the Cookie object from the client to match the session object on the server side. By default, cookies are deleted when we close the browser. However, the cookie can be valid for a certain period of time by modifying the expire time of the cookie;
Token Auth
Advantages of Token Auth
What are the advantages of the Token mechanism compared to the Cookie mechanism?
- Support cross-domain access : Cookie does not allow cross-domain access, which does not exist for the Token mechanism, provided that the transmitted user authentication information is transmitted through HTTP headers.
- Stateless (also known as: server-side extensible) : The Token mechanism does not need to store session information on the server side, because the Token itself contains the information of all logged-in users, and only needs to store state information in the client's cookie or local media.
- More applicable to CDN : You can request all the data on your server (such as javascript, HTML, pictures, etc.) through the content distribution network, and your server only needs to provide API.
- Decoupling : No need to be tied to a specific authentication scheme. Tokens can be generated anywhere, as long as you can make a Token generation call when your API is called.
- More suitable for mobile applications : When your client is a native platform (iOS, Android, Windows 8, etc.), cookies are not supported (you need to process it through the cookie container), then using the Token authentication mechanism will Much simpler.
- CSRF : Since you no longer rely on cookies, you don't need to consider CSRF (Cross Site Request Forgery) prevention.
- 性能: 一次网络往返时间（通过数据库查询session信息）总比做一次HMACSHA256计算 的Token验证和解析要费时得多.
- 不需要为登录页面做特殊处理: 如果你使用Protractor 做功能测试的时候，不再需要为登录页面做特殊处理.
- 基于标准化:你的API可以采用标准化的 JSON Web Token (JWT). 这个标准已经存在多个后端库（.NET, Ruby, Java,Python, PHP）和多家公司的支持（如：Firebase,Google, Microsoft）.