OAuth 2.0 est un accord de licence de qualité industrielle. OAuth 2.0 est hérité de OAuth 1.0, qui a été créé en 2006. OAuth 2.0 s'engage à aider les développeurs à simplifier l'autorisation et à fournir des processus d'autorisation spécifiques pour les applications Web, les applications de bureau, les applications mobiles et les applications intégrées.
OAuth 2.0 est le protocole standard pour l'autorisation. OAuth 2.0 remplace le travail effectué sur le protocole OAuth d'origine créé en 2006. OAuth 2.0 se concentre sur la simplicité du développeur client tout en fournissant des flux d'autorisation spécifiques pour les applications Web, les applications de bureau, les téléphones mobiles et les appareils de salon.
Quatre caractères d'Oauth 2.0
Pour une compréhension facile, prenez la connexion WeChat couramment utilisée comme exemple
Propriétaire de ressource
Le propriétaire de la ressource, les informations personnelles définies sur WeChat par chaque utilisateur correspondant à WeChat appartient à chaque utilisateur et n'appartient pas à Tencent.
Serveur de ressources
Les serveurs de ressources sont généralement des API de repos pour certaines opérations de données utilisateur (addition, suppression, modification et recherche), telles que l'interface de WeChat pour obtenir des informations de base des utilisateurs.
Application client
Clients tiers, par rapport aux applications développées par divers comptes publics WeChat, les applications tierces peuvent accéder à l'API REST du serveur de ressources après avoir été autorisé par le serveur d'authentification pour obtenir des informations de base telles que l'avatar utilisateur, le sexe, la région, etc.
Serveur d'autorisation
Authentifiez le serveur pour vérifier si le client tiers est légal. S'il est légal, émettez un jeton au client et le tiers utilise le jeton pour appeler l'API du serveur de ressources.
Quatre méthodes d'autorisation (type de subvention)
anthorisation_code
Type de code d'autorisation, applicable à l'application du serveur Web. Le mode est: le client appelle d'abord / oauth / autorise / à saisir l'interface d'autorisation de l'utilisateur et renvoie le code après l'autorisation de l'utilisateur, et le client obtient ensuite le jeton d'accès en fonction du code et de l'AppSecret.
Implicite simplifie le type , et il y a moins d'étapes pour obtenir le code d'autorisation que le type de code d'autorisation. Une fois l'application client autorisée, le serveur d'authentification placera directement le jeton d'accès sur l'URL du client. Le client analyse l'URL pour obtenir le jeton. Cette méthode n'est en fait pas très sécurisée, et vous pouvez utiliser des canaux sécurisés HTTPS et raccourcir le temps de validité des jetons d'accès pour réduire le risque.
mot de passe
Type de mot de passe, l'application client obtient un jeton d'accès via le nom d'utilisateur et le mot de passe. Il convient aux serveurs de ressources, les serveurs d'authentification et les clients ont une relation de confiance complète, car l'utilisateur souhaite envoyer directement le nom d'utilisateur et le mot de passe de l'utilisateur à l'application client. L'application client obtient le jeton via le nom d'utilisateur et le mot de passe envoyé par l'utilisateur, puis accède aux ressources du serveur de ressources. Par exemple, Alipay peut se connecter directement avec le nom d'utilisateur et le mot de passe de Taobao car ils appartiennent à la même entreprise et ils se font pleinement confiance.
client_credentials
Le type de client est un moyen qui ne nécessite pas la participation des utilisateurs et est utilisé pour l'amarrage entre différents services. Par exemple, l'application que vous développez vous-même doit appeler le service du fournisseur de services de code de vérification SMS, appeler le service du fournisseur de services de carte et appeler le service du fournisseur de services de push de messages de téléphone portable. Lorsque vous devez appeler le service, vous pouvez utiliser directement l'ID de l'application et l'application donnée par le fournisseur de services pour obtenir le jeton. Après avoir obtenu le jeton, vous pouvez appeler directement le service.
Autres concepts
accomplir
Parfois, le serveur de ressources et le serveur d'authentification sont deux applications différentes. Parfois, le serveur de ressources et le serveur d'authentification sont dans la même application. La différence est de savoir si le serveur de ressources doit vérifier la validité du jeton. Le premier doit vérifier, alors que le second ne le fait pas. Ce dernier est implémenté ici.
Configuration de sécurité de l'application
@ConfigurationPublic Class SecurityConfiguration étend WebSecurityConfigurerAdapter {@Override Protected void configure (httpsecurity http) exception {http.formlogin () .and (). Csrf (). Disable ().); } @Override public void configure (WebSecurity web) lève une exception {super.configure (web); } @Override Protected void Configure (AuthenticationManagerBuilder Auth) lève exception {auth.inMemoryAuthentication (). WithUser ("lyt"). Password ("Lyt"). Autorities ("Role_User") .and (). WithUser ("admin"). Word ("admin"). Password ("role_admin"); } @Bean @Override public AuthenticationManager AuthenticationManagerBean () lève une exception {return super.authenticationManagerBean (); }}Configuration du serveur d'authentification
@ PerteAuthorizationsServer @ ConfigurationPublic Class AuthautationServerConfiguration étend AuthorizeServerConfigurerAdapter {@Override public void configure (clientDetailSServiceConfigurer les clients) lance une exception {client.inMemory (). Avecclient ("client"). .AuthorizedgrantTypes ("Authorization_Code", "Mot de passe", "Implicit", "Client_Credentials");} @Override public void configure (AutorizeSerSeverseCurityConfigurer Security) lève exception {super.configure (Security); } @Override public void Configure (AutorizeServeRendpointsConfigurer Endpoints) lève une exception {endpoint.AuthenticationManager (AuthenticationManager); } @Autowired @Qualifier ("AuthenticationManagerBean") AuthenticationManager AuthenticationManager privée;}Configuration du serveur de ressources
@Enableglobalthodsecurity (prepossenabled = true) @ enableResourceServer @ configurationPublic class ResourceServerConfiguration étend ResourcesserverConfigurerAdapter {@Override public void configure (httpSecurity http) lance une exception {http.antmatcher ("/ oauth2 / api / **"). .antmatchers (httpMethod.get, "/read/**").Access("#oauth.hasscope('Read ')") .antmatchers (httpMethod.post, "/write/**").access("#oauth2.hasscope('write')") "); }}Paramètres d'ordre de filtre de serveur de ressources
Vous devez définir l'ordre de filtre sur 3 dans application.yml. Veuillez vous référer au lien pour des raisons spécifiques.
Empêcher les conflits de biscuits
Afin d'éviter les erreurs entre les cookies du serveur d'authentification et les cookies entre le client et les cookies, il est préférable de modifier le nom des cookies ou de définir ContextPath.
test
Postman fournit une méthode d'authentification OAuth 2.0. Vous pouvez obtenir le jeton et ajouter l'authentification à la demande HTTP, puis demander l'API REST du serveur de ressources.
Informations sur les clients
Autorisation
Le jeton obtenu
Accéder à l'API du serveur de ressources
Ce qui précède est tout le contenu de cet article. J'espère que cela sera utile à l'apprentissage de tous et j'espère que tout le monde soutiendra davantage Wulin.com.