OAuth 2.0 é um contrato de licenciamento de nível industrial. Oauth 2.0 é herdado do OAuth 1.0, criado em 2006. OAuth 2.0 está comprometido em ajudar os desenvolvedores a simplificar a autorização e fornecer processos de autorização específicos para aplicativos da Web, aplicativos de desktop, aplicativos móveis e aplicativos incorporados.
OAuth 2.0 é o protocolo padrão da indústria para autorização. OAuth 2.0 substitui o trabalho realizado no protocolo OAuth original criado em 2006. OAuth 2.0 se concentra na simplicidade do desenvolvedor de clientes, fornecendo fluxos de autorização específicos para aplicativos da Web, aplicativos de desktop, telefones celulares e dispositivos de sala de estar.
Quatro caracteres do OAuth 2.0
Para uma compreensão fácil, pegue o Login do WeChat comumente usado como um exemplo
Proprietário de recursos
O proprietário do recurso, as informações pessoais definidas no WeChat por cada usuário correspondente a WeChat pertencem a cada usuário e não pertence ao Tencent.
Servidor de recursos
Os servidores de recursos geralmente são APIs REST para algumas operações de dados do usuário (adição, exclusão, modificação e pesquisa), como a interface do WeChat para obter informações básicas do usuário.
Aplicativo cliente
Clientes de terceiros, em comparação com os aplicativos desenvolvidos por várias contas públicas do WeChat, aplicativos de terceiros podem acessar a API REST do servidor de recursos após serem autorizados pelo servidor de autenticação a obter informações básicas como Avatar do Usuário, Gênero, Região, etc.
Servidor de autorização
Autentique o servidor para verificar se o cliente de terceiros é legal. Se for legal, emita um token para o cliente e o terceiro usa o token para chamar a API do servidor de recursos.
Quatro métodos de autorização (tipo de concessão)
Anthorization_code
Tipo de código de autorização, aplicável ao aplicativo do servidor da web. O modo é: o cliente primeiro chama/oauth/autorize/para inserir a interface de autorização do usuário e retorna o código após a autorização do usuário, e o cliente obtém token de acesso de acordo com o código e o AppSecret.
O implícito simplifica o tipo e há menos etapas para obter o código de autorização do que o tipo de código de autorização. Depois que o aplicativo cliente for autorizado, o servidor de autenticação colocará diretamente o token de acesso no URL do cliente. O cliente analisa o URL para obter o token. Na verdade, esse método não é muito seguro e você pode usar os canais seguros HTTPS e reduzir o tempo de validade dos tokens de acesso para reduzir o risco.
senha
Tipo de senha, o aplicativo cliente recebe token de acesso através do nome de usuário e senha. É adequado para servidores de recursos, servidores de autenticação e clientes têm um relacionamento completo de confiança, porque o usuário deseja enviar o nome de usuário e a senha do usuário diretamente para o aplicativo cliente. O aplicativo cliente obtém o token através do nome de usuário e senha enviado pelo usuário e, em seguida, acessa os recursos do servidor de recursos. Por exemplo, o Alipay pode fazer login diretamente com o nome de usuário e a senha do Taobao, porque eles pertencem à mesma empresa e confiam plenamente.
client_credentials
O tipo de cliente é uma maneira que não requer participação do usuário e é usada para encaixar entre diferentes serviços. Por exemplo, o aplicativo que você desenvolve precisa ligar para o serviço do provedor de serviços de código de verificação do SMS, ligue para o serviço do provedor de serviços de mapa e ligue para o serviço do provedor de serviços de mensagem de mensagem de telefone celular. Quando você precisa ligar para o serviço, você pode usar diretamente o ID do aplicativo e o AppSecret fornecido pelo provedor de serviços para obter o token. Depois de obter o token, você pode ligar diretamente no serviço.
Outros conceitos
concluir
Às vezes, o servidor de recursos e o servidor de autenticação são dois aplicativos diferentes. Às vezes, o servidor de recursos e o servidor de autenticação estão no mesmo aplicativo. A diferença é se o servidor de recursos precisa verificar a validade do token. O primeiro precisa verificar, enquanto o último não. O último é implementado aqui.
Configuração de segurança do aplicativo
@ConfigurationPublic Classe SecurityConfiguration Estende o webcurityConfigureRAdApter {@Override Protected void Configure (httpsecurity http) lança exceção {http.formlogin () .and (). Cs (). } @Override public void Configure (webcurity web) lança exceção {super.configure (web); } @Override Protected void Configure (AuthenticationManagerBuilder Auth) lança exceção {auth.inmemoryauthentication (). Withuser ("lyt"). Senha ("lyt"). Autoridades ("Role_user"). E (). WithUser ("Admin).). } @Bean @Override public AuthenticationManager AuthenticationManagerBean () lança exceção {return super.authenticationManagerBean (); }}Configuração do servidor de autenticação
@EnableAuthorizationserver @ConfigurationPublic Autorizações AutorizaçõeserververConfiguration Estende as autorizaçõesServerConfigureRAdApter {@Override public void Configure (ClientDetailSServiceConfigurer Clients) lança excepção {clients.inmory (). .authorizedGrantTypes ("autorização_code", "senha", "implícito", "client_credentials");} @Override public void Configure (autorizaçõeserversCurityConfigurer Security) lança Exceção {super.configure (segurança); } @Override public void Configure (AuthorizationservendPointSconfigurer EndPoints) lança exceção {endpoints.authenticationManager (autenticaçãoManager); } @Autowired @qualifier ("AuthenticationManagerBean") Private AuthenticationManager AuthenticationManager;}Configuração do servidor de recursos
@EnableGlobalMethodSecurity (PrePostEnabled = true)@EnableReSourceServer@ConfigurationPublic Classe ResourceServerConfiguration estende o ResourceServerVConfigureRAdApter {@Override Public Void Configure (HttpSecurity http) Exceção/HTP.AntMatcherThuther (httpSecurity htt) Exceção/HTP.AntMatherThuther (httpSecurity htt) Exceção/HTP.AntMatherThuther " .antmatchers (httpmethod.get, "/read/**" ).access("#oauth2.hasscope('read ')") .antmatchers (httpmethod.post, "/write/**").access("#oauth2.hasscope('write')"); }}Configurações de ordem de filtro de servidores de recursos
Você precisa definir o pedido de filtro como 3 no application.yml. Consulte o link por razões específicas.
Impedir conflitos de biscoitos
Para evitar erros entre os cookies do servidor de autenticação e os cookies entre o cliente e os cookies, é melhor modificar o nome do cookie ou definir o contexto.
teste
O Postman fornece o método de autenticação OAuth 2.0. Você pode obter o token e adicionar a autenticação à solicitação HTTP e solicitar a API REST do servidor de recursos.
Informações do cliente
Autorização
O token obtido
Acessando a API do servidor de recursos
O exposto acima é todo o conteúdo deste artigo. Espero que seja útil para o aprendizado de todos e espero que todos apoiem mais o wulin.com.