Automatically approve authorization code
In front of our authorization process, the first step to obtain an authorization code, that they will agree to undergo an authorization page:
This process is like a third party after a successful login, questioning whether to allow a page to obtain information as nicknames and avatars, this process can actually be automatic consent is required on the client configuration, adding an automatic approval:
We apply for authorization code directly you can get:
When the process needs to be done automatically, you need this configuration, if the user needs to click agree, this needs to be set to false, do not write the default is false.
Organize client information
The above automatic approval only client configuration in a small configuration, let's sort out the contents of the client systems all configurable. First look now configured six fields:
The above six field is the most commonly used are also essential client information. But there are many other fields in the configuration of the client, we have to look at the whole:
11 The above configuration includes a content field substantially all of the third-party clients. Let's explain in detail one by one:
withClient method: to configure client_id, must be configured, used to uniquely identify each client (client); must be filled in (the server can be automatically generated) registration, this field is necessary, the practical application also called app_key
resourceIds method: used to configure resource_ids, id represents clients can access the resource set, the client registration, according to actual needs Alternatively resource id, may be different according to the registration process, the corresponding level of resources given id. We can set a resourceid for each Resource Server (Resource Services). Give client authorization, you can set the client instance can access some of the resources which, if not set, is to have access to all of the resource.
secret method: to configure client_secret, or fill out the registration server automatically generated, practical applications also called app_secret,
Method scopes: to configure the purview of scope, the specified client, such as read and write permissions, such as a mobile terminal or the web end permissions All permissions represent all
authorizedGrantTypes method: used to configure authorized_grant_types, optional value, the authorization code pattern: authorization_code, Cipher Mode: password, refresh token: refresh_token, the Implicit mode: Implicit: client mode: client_credentials. Support for multiple separated by commas
redirectUris method: used to configure web_server_redirect_uri, client redirection uri, authorization_code implicit and need to check this value, fill registration
authorities method: used to configure the authorities, the specified user's jurisdiction, if the authorization process requires the user to log in, the field does not take effect, implicit and need client_credentials
accessTokenValiditySeconds method to configure access_token_validity, access_token set valid time (in seconds), the default (12 hours)
refreshTokenValiditySeconds method: to configure refresh_token_validity, provided refresh_token period (seconds), the default (30 days)
additionalInformation method: used to configure additional_information, represents the supplemental information, can be null, value must be json format
autoApprove method: used to configure autoapprove, default false, suitable authorization_code mode, whether to automatically set the user approval operation, the user confirms the authorization is set to true operation skip page, jump directly redirect_uri
Here we create a table in the database, the definition of which is eleven field, table named oauth_client_details:
Note that this table name must be specified oauth_client_details oauth table name, is also the default jdbc operation table name. Let's add a record:
Compared to the previous example, where a multi-field values of resource_ids, and others are the same as the previous configuration. Note that the secret is stored in encrypted ciphertext, the first encryption secret.
Authorized service more than a resource_id, resources and services have to configure their own id:
The default management jdbc client
The configuration of the death of the client information is changed from the way jdbc client queries is very simple, first introduced database relies on:
Then configure the data source:
Last Modified configure client licensing class configuration:
Client configuration can be seen after the modification is very simple, only need to configure a jdbc data source to the client, the query method is automatic. About realize, you can refer to the source code:
- org.springframework.security.oauth2.provider.client.JdbcClientDetailsService
There are written and CRUD sql statement logic:
Which has a secret key update method, encryption method is required:
So we can configure encryption method behind jdbc:
test
In addition to the above database, the other configuration changes simple, to test the following:
Access results:
Specific processes as before.
Code Address: https://gitee.com/blueses/spring-boot-security 19 20