In ancient warfare, the power to dispatch troops was often contained in one thing - the soldier talisman. It is a token that has been carefully crafted by an authority and split into two halves, and only when the two halves are combined for verification can the holder be given the legal authority to command the army. This physical document ensures the security of military operations and the effectiveness of the execution of orders, and is a vivid embodiment of the delegation of authority and identity verification.
In the modern online world, a similar authorization mechanism is embodied in OAuth 20 tokens in the protocol.
oauth2.0 tokens are like the talismans on the battlefield in ancient times, they are a key tool for power transfer and identity verification. However, in the digital world, the token has evolved from a physical to a virtual form, but the authorized mission it carries and the security logic behind it are not only in the same vein as the ancient tokens, but also expanded and deepened in technology and scale like never before.
Token in OAuth 2In the various authorization modes of the 0 protocol, it is used as the result of authorization decisions and the identity of subsequent access to services. The server verifies the token to ensure that the requester has the authority to perform the requested operation, and the information carried by the token itself can include key data such as the user's identity, validity time, and authorization scope.
Previously, we had a review of OAuth20 authorization mode is carried out **oauth2.0: The authorization mode is fully resolved.
Common types of tokens include access tokens, refresh tokens, and idtokens, each of which has its own specific roles, differences, and application scenarios
Access tokens are used for authentication, because access tokens have a certain validity period and are no longer valid after expiration, so as to ensure the security of the system. After expiration, the client usually needs to obtain a new access token through a refresh token, so the access token is also called a "short token".
Format requirements
AccessToken does not limit the fixed format from the OAuth protocol level, it can be any format, but now JWT is used to in general scenarios. It is not recommended that the user directly parse the accesstoken to obtain the information in it (because the format of the accesstoken is not mandatory to be JWT), and it needs to be determined according to the actual authorization service design specification.
Application scenarios
The accesstoken is used only for authorization and can be used to restrict access to protected resources. For example, user interface permission management, inter-application interface permission management, but at the standard protocol level, accesstoken will not be used for authentication (because accesstoken represents more of a "permission scope", which is to protect the API).
After the accesstoken is issued, the subject represented may be a "person" or a "device".
What is the expiration date configuration in the recommended solution?
For security reasons, the validity period of accesstoken is usually very short, but this also needs to be decided on a case-by-case basis. For example:
In scenarios where no user participation (such as client-side mode) is recommended, it is recommended to be slightly longer.
In scenarios with user participation: For example, it is recommended that the authorization code mode and password mode be slightly shorter, and you can rely on refreshtoken to realize the renewal of the login state; However, it is recommended to configure a slightly longer configuration like implicit authorization mode, because this mode does not support refresh tokens and cannot achieve login state renewal.
If an application is used in both the client mode and the user mode, the business side needs to consider the actual business scenario and the application scenario of the token itself.
When a user accesses a protected resource on its resource server through a client application, the authorization server will not only return an accesstoken to the client, but also generate a refreshtoken, which will be sent to the authorization when the "short token" accesstoken expires The server requests a new access token without requiring the user to log in and authorize again, thus improving the user experience and ensuring the security of the system. For this reason, RefreshToken is also known as a "long token".
Format requirements
RefreshToken in OAuth 2There is no specific format in the 0 protocol, the following is an example of a refreshtoken (note that the actual refreshtoken is usually encrypted or encoded to ensure its security, and is not necessarily in JSON format).
1eyjhbgcioijiuzi1niisinr5cci6ikpxvcj9.eyjpc3mioijodhrwczovl2f1dgguawquy29tiiwicmvmcmvzaf90b2tlbl9pzci6ijeymzq1njc4otailcjlehaioje2mdk4ntgwmdasinnjb3blijoib3blbmlkihbyb2zpbgugzw1hawwilcjhdxrob3jpdhkioijbuelfq0xjru5uihbyaxzhdguifq.rkks7lp4lohydy_fvcokcfhs3ftinilwg8yrijeql5oWhile the above example looks like a JWT (JSON Web Token), in fact the RefreshToken can be in any format, for example it can be just a long string, or a custom serialized object with multiple properties.
Although the specific format of the RefreshToken was not used by OAuth 2The 0 specification is strictly restrictive, but for security and manageability, most modern OAuth 2The 0 implementation would choose to use JWT or at least store the RefreshToken in some structured format, protecting it during storage and transmission. At the same time, security policies such as expiration date control and blacklist mechanism will also be implemented for Refreshtoken.
Application scenarios
When the user is authenticated, the server not only issues a short-term access token for the client to access the protected resources, but also issues a long-term stored refreshtoken. Due to its limited validity period (e.g., ranging from a few hours to a few days), accesstokens cannot be used after expiration; In this case, the client can carry the refreshtoken to request a new accesstoken from the authentication server, and the whole process does not require the user to log in again. This design not only ensures the security of the system (because even if the accesstoken is compromised, an attacker cannot use it to obtain a new accesstoken or update the refreshtoken) and improves the user experience (avoid frequent logins). RefreshToken is commonly used to support single sign-on (SSO) environments and OAuth 20 and other open authorization protocols to ensure that users can maintain a long-term login state between multiple connected applications and dynamically update access rights as needed.
What is the expiration date configuration in the recommended solution?
The expiration date configuration in the RefreshToken recommendation solution is usually long so that the user's login state can be maintained for a long time after the AccessToken expires without re-authentication. It can be valid for days, weeks, or even months, depending on the system's security policy and user experience needs. In addition, the system should also design corresponding logic to revoke or update the RefreshToken, and limit the number of times or the lifecycle of a single RefreshToken to prevent potential threats caused by the improper use of RefreshToken.
In OAuth 2Under the 0 protocol framework, idToken is an identity token specific to OpenID Connect (OIDC). [Note: OpenID Connect is built on OAuth 2.]A set of authentication layer protocols above 0, which is mainly used to solve the problem of user identification and authentication. 】
When the user passes OAuth 2In addition to obtaining the AccessToken required to access the resource, OpenID Connect also allows the client to request an IDTOKEN. After the client receives and verifies the idtoken, it can determine the user's identity based on its contents, and use this information for further business logic processing or user interface presentation if necessary.
IdToken is usually in the format of a JSON Web Token (JWT), which consists of three parts: a header, a payload, and a signature"Make the connection.
The JWT header contains the metadata information of the token, such as the encryption algorithm;
JWT Payload stores multiple JSON-encoded claims that provide information about the identity of an authenticated user;
JWT Signature ensures the integrity and credibility of the token content by signing the first two parts.
In order to handle the idtoken correctly, the client needs to verify the signature according to the instructions in the header and check the validity of each claim in the payload, including but not limited to confirming that the token has not expired, the audience matches itself, and the validity of the nonce value.
Application scenarios
The core application scenario of idToken in OpenID Connect is user authentication and authorization
User authentication: When a user logs in to an OpenID Connect-enabled application, the server returns an ID token that contains the user's identifier and other relevant information. The application can confirm the user's identity by verifying this token.
Single sign-on (SSO): When single sign-on is implemented between multiple applications, users only need to sign in in one place and automatically sign in in all other applications. In this scenario, each application receives an ID token that contains the user's identifier and other relevant information.
User information acquisition: In addition to the user's identity information, the idtoken can also contain other information about the user, such as user name, email address, **number, etc. Applications can get this information by resolving the ID token, rather than having to get it directly from the database or something else.
Secure Transmission: Because the ID token is a security token, it can be used to secure the secure transmission of sensitive information. For example, when an application needs to send user information to a server, it can put that information in an ID token and send it to the server so that it doesn't have to be transmitted in clear text.
RecommendedWhat is the validity period configuration in the solution?
The recommended configuration validity period of idToken is usually short to reduce security risks, and at the same time, it can be used with Refresh tokens to achieve automatic renewal. The specific validity period is adjusted based on the security requirements and user experience of the application, aiming to ensure the continuity of user sessions while controlling the risk of identity credential abuse. Expired tokens are monitored and processed through server-side logic, and refresh policies are implemented based on business rules, taking into account security and convenience.
In today's online world with a high flow of information, OAuth 2The token mechanism of 0 is undoubtedly a crucial bridge in the digital society. Token mechanisms such as AccessToken and RefreshToken act as a solid security barrier, which not only protects the privacy of users' personal data, but also provides a safe, flexible and convenient way for services to interact with each other. With this modern version of the Talisman, users can precisely manage access to their resources and ensure that every authorization is based on evidence.