OAuth 2.0 is an industrial-grade licensing agreement. OAuth 2.0 is inherited from OAuth 1.0, which was created in 2006. OAuth 2.0 is committed to helping developers simplify authorization and provide specific authorization processes for web applications, desktop applications, mobile applications, and embedded applications.
OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 supersedes the work done on the original OAuth protocol created in 2006. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices.
Four characters of OAuth 2.0
For easy understanding, take the commonly used WeChat login as an example
Resource Owner
The resource owner, the personal information set on WeChat by each user corresponding to WeChat belongs to each user and does not belong to Tencent.
Resource Server
Resource servers are generally REST APIs for some operations of user data (addition, deletion, modification and search), such as WeChat's interface to obtain user basic information.
Client Application
Third-party clients, compared with the applications developed by various WeChat public accounts, third-party applications can access the REST API of the resource server after being authorized by the authentication server to obtain basic information such as user avatar, gender, region, etc.
Authorization Server
Authenticate the server to verify whether the third-party client is legal. If it is legal, issue a token to the client, and the third party uses the token to call the resource server's API.
Four authorization methods (Grant Type)
anthorization_code
Authorization code type, applicable to Web Server Application. The mode is: the client first calls /oauth/authorize/ to enter the user authorization interface, and returns code after the user authorization, and the client then obtains access token according to code and appSecret.
Implicit simplifies the type , and there are fewer steps to obtain the authorization code than the authorization code type. After the client application is authorized, the authentication server will directly place the access token on the client's URL. The client parses the url to get the token. This method is actually not very secure, and you can use https secure channels and shorten the validity time of access tokens to reduce the risk.
password
Password type, client application gets access token through username and password. It is suitable for resource servers, authentication servers and clients have a complete trust relationship, because the user wants to send the user's username and password directly to the client application. The client application obtains the token through the username and password sent by the user, and then accesses the resource server resources. For example, Alipay can log in directly with Taobao username and password because they belong to the same company and they fully trust each other.
client_credentials
Client type is a way that does not require user participation and is used for docking between different services. For example, the application you develop yourself needs to call the service of the SMS verification code service provider, call the service of the map service provider, and call the service of the mobile phone message push service provider. When you need to call the service, you can directly use the app ID and appSecret given by the service provider to obtain the token. After you get the token, you can directly call the service.
Other concepts
accomplish
Sometimes the resource server and the authentication server are two different applications. Sometimes the resource server and the authentication server are in the same application. The difference is whether the resource server needs to check the validity of the token. The former needs to check, while the latter does not. The latter is implemented here.
Application security configuration
@Configurationpublic class SecurityConfiguration extends WebSecurityConfigurerAdapter { @Override protected void configure(HttpSecurity http) throws Exception { http.formLogin() .and().csrf().disable() .authorizeRequests().anyRequest().authenticated(); } @Override public void configure(WebSecurity web) throws Exception { super.configure(web); } @Override protected void configure(AuthenticationManagerBuilder auth) throws Exception { auth.inMemoryAuthentication().withUser("lyt").password("lyt").authorities("ROLE_USER") .and().withUser("admin").password("admin").password("ROLE_ADMIN"); } @Bean @Override public AuthenticationManager authenticationManagerBean() throws Exception { return super.authenticationManagerBean(); }}Authentication server configuration
@EnableAuthorizationServer@Configurationpublic class AuthorizationServerConfiguration extends AuthorizationServerConfigurerAdapter { @Override public void configure(ClientDetailsServiceConfigurer clients) throws Exception { clients.inMemory().withClient("client") .scopes("read","write") .secret("secret") .authorizedGrantTypes("authorization_code","password","implicit","client_credentials");} @Override public void configure(AuthorizationServerSecurityConfigurer security) throws Exception { super.configure(security); } @Override public void configure(AuthorizationServerEndpointsConfigurer endpoints) throws Exception { endpoints.authenticationManager(authenticationManager); } @Autowired @Qualifier("authenticationManagerBean") private AuthenticationManager authenticationManager;}Resource server configuration
@EnableGlobalMethodSecurity(prePostEnabled = true)@EnableResourceServer@Configurationpublic class ResourceServerConfiguration extends ResourceServerConfigurerAdapter { @Override public void configure(HttpSecurity http) throws Exception { http.antMatcher("/oauth2/api/**").authorizeRequests() .antMatchers(HttpMethod.GET, "/read/**").access("#oauth2.hasScope('read')") .antMatchers(HttpMethod.POST, "/write/**").access("#oauth2.hasScope('write')"); }}Resource server filter-order settings
You need to set filter-order to 3 in application.yml. Please refer to the link for specific reasons.
Prevent cookie conflicts
In order to avoid errors between cookies of the authentication server and cookies between the client and cookies, it is best to modify the cookie name or set contextPath.
test
Postman provides OAuth 2.0 authentication method. You can obtain the token and add the authentication to the http request, and then request the REST API of the resource server.
Client information
Authorization
The token obtained
Accessing the Resource Server API
The above is all the content of this article. I hope it will be helpful to everyone's learning and I hope everyone will support Wulin.com more.