Shulou(Shulou.com)06/02 Report--

This article will explain in detail about the storage and management of OAuth2.0 token in SpringBootSecurity. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have some understanding of the relevant knowledge after reading this article.

Store token in memory

Let's move on to the next optimization of the authorization service code. Now in the authorization service, the storage of token is stored in memory, and we use InMemoryTokenStore:

The tokenStore method in the figure supports many ways to store tokens. Take a look at this:

InMemoryTokenStore: this version of the implementation is adopted by default, it works perfectly on a single server (that is, when the access concurrency pressure is low, and it does not backup when it fails), most projects can use this version of the implementation to try, you can use it for management during development, because it will not be saved to disk, so it is easier to debug.

JwtTokenStore: the full name of this version is JSON Web Token (JWT), which encodes token-related data (so it doesn't need to be stored for back-end services, which would be a major advantage), but it has a disadvantage that it will be very difficult to revoke an authorized token, so it is usually used to deal with a token with a short lifetime and to revoke a refresh token (refresh_token). Another disadvantage is that this token takes up a lot of space if you add more user credential information. JwtTokenStore does not save any data, but it plays the same role as DefaultTokenServices in converting token values and authorization information.

JdbcTokenStore: this is a JDBC-based implementation where tokens are stored in a relational database. When using this implementation, you can share token information between different servers, and be careful to add the dependency "spring-jdbc" to your classpath when using it.

RedisTokenStore: this is a Redis-based implementation where tokens are kept in the Redis cache. When using this implementation, you can share token information between different servers, and be careful to add redis dependencies to your classpath when using it. It is no longer described here about the differences and caveats between redis and database data storage.

The default InMemoryTokenStore storage can also be queried and deleted. Let's take a look. First, configure InMemoryTokenStore as a bean:

Then the bean is called during configuration:

Let's take a look at what you do with token in the InMemoryTokenStore class:

As can be seen from the name of the method, the operations of adding, deleting, modifying and querying token are basically complete. Let's write two methods to query and delete token:

The InMemoryTokenStore injected into the class is the bean defined earlier, and only in this way can you operate the token in memory. Let's take a look at the test. First, apply for a token according to the previous process, and then query the token:

Then test the delete token:

Then query the protected resources based on the token, and you can find that it is inaccessible.

Although the way of using memory has all the basic functions, the disadvantage mentioned above is that it can only work on a single server and cannot realize token sharing by default. In addition, it is a good choice for testing environment to use memory storage.

Redis Storage token

In addition to storing tokens in memory, tokens can also be stored in public places, such as redis, so that the problem of unsynchronized data on a single server can be solved. The first step to storing in redis is to introduce dependencies:

Then configure the data source:

Then modify the authorization configuration class to configure the bean stored in redis:

In this way, the configuration of the redis storage token is basically completed, and then following the previous memory storage operation, write two interfaces to query and delete the token in the redis:

Start the project, follow the previous process to obtain the token, access the protection resources, and then check the redis. You can see that the token we obtained is stored in it:

Take a look at the effect of querying the token API:

Let's see the effect of deleting the token API:

After deletion, the token in redis is also deleted:

There are only three refreshed key left.

JDBC Storage token

You can also share token by using jdbc to store token. The operation class is JdbcTokenStore. Let's take a look at this class:

Class defines a number of sql statements for default actions, involving a total of two tables: oauth_access_token and oauth_refresh_token (which will not be used if the client's grant_type does not support refresh_token). Take a look at the structure of the oauth_access_token table:

Token_id: the value of this field is stored after the value of access_token is encrypted through MD5

Token: stores the binary data after serializing the OAuth3AccessToken.java object, which is the data value of the real AccessToken

Authentication_id: this field is unique and its value is generated by MD5 encryption based on the current username (if any), client_id and scope. For specific implementation, please refer to DefaultAuthenticationKeyGenerator.java class.

User_name: the user name when logging in. If the client does not have a user name (such as grant_type= "client_credentials"), this value is equal to client_id

Client_id: you know

Authentication: stores binary data after serialization of OAuth3Authentication.java objects

Refresh_token: the value of this field is stored after the value of refresh_token is encrypted through MD5

Take a look at the field structure of the oauth_refresh_token table:

Token_id: the value of this field is stored after the value of refresh_token is encrypted through MD5.

Token: stores binary data after serializing OAuth3RefreshToken.java objects.

Authentication: stores binary data after serialization of OAuth3Authentication.java objects

Create these two tables in the database:

Then introduce the jdbc dependency in pom and configure the data source in the configuration file, which is not demonstrated here. Next, modify the authorization configuration class:

Finally, following the example above, write two interfaces for querying and deleting token:

Using a database to store token has a lot more methods and operations than the previous two ways. Take a look at the JdbcTokenStore class:

In addition to the operation of adding, deleting, changing and checking, there are several more methods, including the default writing of sql statements also has an overridden set method. To test, first follow the previous process to obtain the token token, and then query the database:

You can see that two pieces of token data have been added to the database. Take a look at the query token API:

Delete an interface:

Take a look at the method source code for deleting API calls:

Only the token is deleted, and the record of updating the token is retained.

Code address: https://gitee.com/blueses/spring-boot-security 23 24

About how the storage and management of OAuth2.0 token in SpringBootSecurity is shared here, I hope the above content can be of some help to you and learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.