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

How to look at the spring Oauth2 data structure, I believe that many inexperienced people are helpless about this, this article summarizes the causes and solutions of the problem, through this article I hope you can solve this problem.

oauth_client_details

client_id primary key, must be unique, cannot be empty.

Used to uniquely identify each client; must be filled in during registration (can also be automatically generated by the server).

This field is required for different grant_types. In practice, another name is appKey, which is the same concept as client_id. resource_ids A collection of resource ids that a client can access. Multiple resources are separated by commas (,), for example: "unity-resource,mobile-resource".

The value of this field must be derived from a value consistent with the resource-id attribute of the tag ‹oauth3:resource-server in security.xml. If there are several <$oauth3:resource-server tags configured in security.xml, several of these values can be used for this field.

In practical application, we generally classify resources and configure corresponding <$oauth3:resource-server respectively, such as order resources configure a <$oauth3:resource-server, user resources configure another <$oauth3:resource-server. When registering the client, you can select the resource id according to actual needs, or assign the corresponding resource id according to different registration processes.client_secret is used to specify the access key of the client; it must be filled in during registration (it can also be automatically generated by the server).

This field is required for different grant_types. Another name in practice is appSecret, which is the same concept as client_secret.scope specifies the scope of permissions requested by the client. Optional values include read,write,trust; if there are multiple permission ranges separated by commas (,), for example: "read,write".

The scope value is related to the access attribute of ‹intercept-url configured in security.xml. For example, the configuration of intercept-url is

‹intercept-url pattern="/m/** " access="ROLE_MOBILE,SCOPE_READ"/>

The client must have read permission to access the URL. The configuration value of write is SCOPE_WRITE, and the configuration value of trust is SCOPE_TRUST.

In practice, this value is usually specified by the server. Common values are read,write.authorized_grant_types Specify the grant_type supported by the client. Optional values include authorization_code,password,refresh_token,implicit,client_credentials. If multiple grant_types are supported, they are separated by commas (,), such as "authorization_code,password".

In practice, when registering, this field is generally specified by the server, rather than selected by the applicant. The most common grant_type combinations are: "authorization_code,refresh_token"(for clients accessed through browsers); "password,refresh_token"(for clients on mobile devices).

implicit and client_credentials are rarely used in practice.web_server_redirect_uri The redirect URI of the client, which can be empty. When grant_type is authorization_code or implicit, it will be used in the Oauthority process and checked to see if it is consistent with the redirect_uri filled in during registration. The following are explained separately:

When grant_type=authorization_code, the first step is to get 'code' from spring-oauth-server. When the client initiates the request, it must have the redirect_uri parameter, and the value of this parameter must be consistent with the value of web_server_redirect_uri. Step 2: When exchanging 'code' for 'access_token' the client must also pass the same redirect_uri.

In practice, web_server_redirect_uri must be filled in when registering, generally used to process the code returned by the server, verify whether the state is legal and exchange the access_token value with the code.

In the spring-oauth-client project, refer to AuthorizationCodeController.java for authorizationCodeCallback method.

When grant_type=implicit, the access_token value is passed through the hash value of redirect_uri. For example:

http://localhost:7777/spring-oauth-client/implicit#access_token=dc891f4a-ac88-4ba6-8224-a2497e013865&token_type=bearer&expires_in=43199

Then the client obtains the access_token value from the hash value through JS, etc. authorities Specify the Spring Security permission value owned by the client, optional, if there are multiple permission values, separated by commas (,), such as: "ROLE_UNITY,ROLE_USER".

Whether to set the value of this field depends on different grant_types. If the client needs (authorization_code,password) of the user's username and password in the Oauth process,

Then this field may not need to be set, because the server will determine whether the user has permission to access the corresponding API according to the permissions owned by the server.

But if the client does not need user information (implicit,client_credentials) in the Oauth process,

The corresponding permission value must be set for this field, because the server will determine whether it has permission to access the corresponding API according to the permission value of this field.

access_token_validity Set the validity time (in seconds) of the access_token on the client, optional, or use the default validity time (60 * 60 * 12, 12 hours) if no value is set.

The value of the expires_in field in the access_token JSON data obtained by the server is the valid time value of the current access_token.

In the project, refer to the accessTokenValiditySeconds property in DefaultTokenServices.java for details.

In practice, this value is typically handled by the server and does not require client customization.refresh_token_validity

Set the refresh_token valid time value (unit: seconds) of the client, optional, if not set, use the default valid time value (60 * 60 * 24 * 30, 30 days).

If the grant_type of the client does not include refresh_token, then do not care that this field is in the project, please refer to the property refreshTokenValiditySeconds in DefaultTokenServices.java for details.

In practice, this value is usually handled by the server and does not require client customization.

additional_information This is a reserved field that is not actually used in the Oauth process, optional, but if the value is set, it must be data in JSON format, such as:

{"country":"CN","country_code":"086"}

Follow the description of this field in the spring-security-oauth project

Additional information for this client, not need by the vanilla OAuth protocol but might be useful, for example,for storing descriptive information.

(See comments on getAdditionalInformation() method in ClientDetails.java) In practice, this field can be used to store other information about the client, such as the client's country, region, IP address at registration, etc. autoapprove sets whether the user automatically approves the operation, default value is 'false', optional values include' true','false',' read','write'.

This field is only applicable to grant_type="authorization_code". When the user successfully logs in, if the value is 'true' or a supported scope value, the page approved by the user will be skipped and authorization will be directly granted.

This field has similar functionality to trusted and is a new property added since version 2.0 of spring-security-oauth3.

After reading the above, do you know how to look at the Spring Oauth2 data structure? If you still want to learn more skills or want to know more related content, welcome to pay attention to the industry information channel, thank you for reading!

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.