Basic knowledge of OAuth2.0
There are a lot of introductions about OAuth2.0 on the Internet, so I won't do too much introduction here. Friends who don't know much can refer to Understanding OAuth 2.0
Spring Security OAuth2
basic configuration
Here we still use maven for management
<dependency>
<groupId>org.springframework.security.oauth</groupId>
<artifactId>spring-security-oauth2</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>Authentication server
Authorization Server
After we have the basic concept of OAuth2.0, we will know that there is a service provider, and we will complete it first.
Here you just need to create a new class and add the corresponding annotations.
@Configuration
@EnableAuthorizationServer
public class MyAuthorizationServerConfig {
}Then we start the project, and we will find that the console has the following statement printed:
This indicates that the Authorization Server has been established. We can access the corresponding interface according to the rules of OAuth.
Third-party application User authenticates
After we have the service provider, we can ask the user to authorize according to the rules of OAuth. Here we take the code mode as an example.
So here you need a third-party application to call the interface
Here is a brief introduction to the interface parameters.
- localhost:8080 here is the address and port of my service, it is different according to everyone's situation
- /oauth/authorize This is the default interface provided by Spring Security OAuth2
- response_type: indicates the authorization type, required, the value here is fixed to "code"
- client_id: Indicates the ID of the client, required. What is used here is the security.oauth2.client.clientId output by the console when the project is started, of course, this value can be customized in the configuration file
- redirect_uri: Indicates the redirect URI, optional. That is, the place where the user will jump after successful authorization, usually the third-party application's own address
- scope: Indicates the scope of permission to apply, optional. This item is used by service providers to distinguish which service data is provided
- state: Indicates the current state of the client, any value can be specified, and the authentication server will return this value intact. This value is not used here
Here, after we access the interface, the following interface will appear.
This interface is mainly used for user login. Otherwise, how do you know which user's data you want?
After the login is successful, you will come to the following interface
. Here is the interface that requires user authorization, which is somewhat similar to the interface when we use QQ for third-party login. What data is required by which third-party application is written above.
We click here to confirm the authorization, and here we will redirect_urijump according to the configuration, and there is a parameter.
Here we jump to: https://www.baidu.com/?code=XKxYIx .
This code is used by the third-party application to apply for the token from the server in the next step.
Request Token
Here we take the code obtained in the previous step, and the clientId and secret printed when the project was initialized to obtain the Token.
Here you need to use the POST method,
POST /oauth/token HTTP/1.1
Host: localhost:8082
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
There is an Authorization parameter in the Header of the request, and the value of this parameter is Basic + (clientId:secret Base64 value)
- grant_type: Indicates the authorization mode used, a required option, the value here is fixed to "authorization_code".
- code: indicates the authorization code obtained in the previous step, required.
- redirect_uri: Indicates the redirection URI, which is required and must be the same as the parameter value in step A.
- client_id: Indicates the client ID, required.
If the request is successful, you can successfully get the Token
Get Token
After the request token is successful, the HTTP reply sent by the authentication server
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
- access_token: Indicates the access token, required.
- token_type: Indicates the token type. The value is case-insensitive and required. It can be bearer type or mac type.
- expires_in: Indicates the expiration time, in seconds. If this parameter is omitted, the expiration time must be set in other ways.
- refresh_token: Indicates the update token, used to obtain the next access token, optional.
- scope: Indicates the scope of authority. If it is consistent with the scope applied by the client, this item can be omitted.
resource server
Like the authentication server, it is easy to implement a resource server here
@Configuration
@EnableResourceServer
public class MyResourceServerConfig {
}In this way, we can use Token to access the interface.
E.g:
GET /user HTTP/1.1
Host: localhost:8082
Authorization: bearer 9b2aaea4-d161-4636-8883-6756a372e735
Here in Authorization, bearer is the token_type returned in the previous step.
Remaining problem
At present, the basic functions have been realized, but there are still two remaining problems to be solved:
1. The current Token is stored in the Session, and the original client's Token will be invalid after the server restarts.
2. Token is now automatically generated. Can JWT be used for custom generation?