OAuth 2.0 es un acuerdo de licencia de grado industrial. OAuth 2.0 se hereda de OAuth 1.0, que se creó en 2006. OAuth 2.0 se compromete a ayudar a los desarrolladores a simplificar la autorización y proporcionar procesos de autorización específicos para aplicaciones web, aplicaciones de escritorio, aplicaciones móviles y aplicaciones integradas.
OAuth 2.0 es el protocolo estándar de la industria para la autorización. OAuth 2.0 reemplaza el trabajo realizado en el protocolo OAuth original creado en 2006. OAuth 2.0 se centra en la simplicidad del desarrollador de clientes al tiempo que proporciona flujos de autorización específicos para aplicaciones web, aplicaciones de escritorio, teléfonos móviles y dispositivos de sala de estar.
Cuatro personajes de OAuth 2.0
Para una fácil comprensión, tome el inicio de sesión de WeChat de uso común como ejemplo
Propietario de recursos
El propietario del recurso, la información personal establecida en WeChat por cada usuario correspondiente a WeChat pertenece a cada usuario y no pertenece a Tencent.
Servidor de recursos
Los servidores de recursos generalmente son API REST para algunas operaciones de datos del usuario (adición, deleción, modificación y búsqueda), como la interfaz de WeChat para obtener información básica del usuario.
Aplicación del cliente
Los clientes de terceros, en comparación con las aplicaciones desarrolladas por varias cuentas públicas de WeChat, las aplicaciones de terceros pueden acceder a la API REST del servidor de recursos después de ser autorizados por el servidor de autenticación para obtener información básica como avatar de usuarios, género, región, etc.
Servidor de autorización
Autenticar el servidor para verificar si el cliente de terceros es legal. Si es legal, emita un token al cliente, y el tercero usa el token para llamar a la API del servidor de recursos.
Cuatro métodos de autorización (tipo de subvención)
anthorization_code
Tipo de código de autorización, aplicable a la aplicación del servidor web. El modo es: el cliente primero llama/oauth/autorize/para ingresar a la interfaz de autorización del usuario, y devuelve código después de la autorización del usuario, y el cliente obtiene token de acceso de acuerdo con el código y la appSecret.
Implicit simplifica el tipo , y hay menos pasos para obtener el código de autorización que el tipo de código de autorización. Después de autorizar la aplicación del cliente, el servidor de autenticación colocará directamente el token de acceso en la URL del cliente. El cliente analiza la URL para obtener el token. Este método en realidad no es muy seguro, y puede usar los canales seguros HTTPS y acortar el tiempo de validez de los tokens de acceso para reducir el riesgo.
contraseña
Tipo de contraseña, la aplicación del cliente obtiene token de acceso a través del nombre de usuario y la contraseña. Es adecuado para servidores de recursos, servidores de autenticación y clientes tienen una relación de confianza completa, porque el usuario desea enviar el nombre de usuario y la contraseña del usuario directamente a la aplicación del cliente. La aplicación del cliente obtiene el token a través del nombre de usuario y la contraseña enviados por el usuario, y luego accede a los recursos del servidor de recursos. Por ejemplo, Alipay puede iniciar sesión directamente con el nombre de usuario y la contraseña de Taobao porque pertenecen a la misma compañía y confían completamente entre sí.
client_credentials
El tipo de cliente es una forma que no requiere participación del usuario y se utiliza para acoplar entre diferentes servicios. Por ejemplo, la aplicación que desarrolla usted mismo debe llamar al servicio del proveedor de servicios de código de verificación SMS, llamar al servicio del proveedor de servicios de mapas y llamar al servicio del proveedor de servicios de mensajes de teléfono móvil. Cuando necesite llamar al servicio, puede usar directamente la ID de aplicación y la AppSecret dada por el proveedor de servicios para obtener el token. Después de obtener el token, puede llamar directamente al servicio.
Otros conceptos
lograr
A veces, el servidor de recursos y el servidor de autenticación son dos aplicaciones diferentes. A veces, el servidor de recursos y el servidor de autenticación están en la misma aplicación. La diferencia es si el servidor de recursos necesita verificar la validez del token. El primero necesita verificar, mientras que el segundo no. Este último se implementa aquí.
Configuración de seguridad de la aplicación
@ConfigurationPublic Class SecurityConfiguration extiende WebSecurityConfigurerAdapter {@Override Protected void configure (httpsecurity http) lanza excepción {http.formlogin () .and (). Csrf (). Disable (). } @Override public void configure (WebSecurity Web) lanza la excepción {super.configure (web); } @Override Protected void configure (AuthenticationManagerBuilder Auth) lanza la excepción {Auth.inMemoryAuthentication (). Withuser ("Lyt"). Password ("Lyt"). Autoridades ("role_user") .and (). Withuser ("Admin"). Password ("Admin"). Password ("Role_admin"); } @Bean @Override public AuthenticationManager AuthenticationManagerBean () lanza excepción {return super.authenticationManagerBean (); }}Configuración del servidor de autenticación
@EnableAuthorizationserver @ConfigurationPublicPublic Class AutorizationserverConfiguration extiende AutorizationserverConfigurerAdapter {@Override public void Configure (ClientDetailsServiceConFigurer Clients) lanza la excepción {Clients.InMemory (). .AuthorizedGrantTypes ("Authorization_Code", "Password", "ImpliTe", "Client_Credentials");} @Override public void configure (autorizationServerSecurityConfigurer Security) lanza una excepción {super.configure (seguridad); } @Override public void configure (autorizationserverEndpointSconfigurer endpoints) lanza la excepción {EndPoints.AuthenticationManager (AuthenticationManager); } @AUtowired @Qualifier ("AuthenticationManagerBean") Autenticación privada Manager AuthenticationManager;}Configuración del servidor de recursos
@EnableGlobalMethodSecurity (prepOSTENLED = true)@enableReSourceserver@ConfigurationPublic Class ResourcesServerConfiguration extiende ResourcesServerCigureRAdapter {@Override public Void Configurar (HttpSecurity Http) Lanza la excepción {http.antmatcher ("/oauth2/api/**"). .antMatchers (httpmethod.get, "/read/**").access("#oauth2.hasscope('Read ')") .antmatchers (httpmethod.post, "/write/**").access("#oauth2.hasscope('Write')"); }}Configuración de orden de filtro de servidor de recursos
Debe establecer Filter-Order en 3 en Application.yml. Consulte el enlace por razones específicas.
Prevenir conflictos de galletas
Para evitar errores entre las cookies del servidor de autenticación y las cookies entre el cliente y las cookies, es mejor modificar el nombre de la cookie o establecer el traje de contexto.
prueba
Postman proporciona el método de autenticación OAuth 2.0. Puede obtener el token y agregar la autenticación a la solicitud HTTP, y luego solicitar la API REST del servidor de recursos.
Información del cliente
Autorización
El token obtenido
Acceder a la API del servidor de recursos
Lo anterior es todo el contenido de este artículo. Espero que sea útil para el aprendizaje de todos y espero que todos apoyen más a Wulin.com.