1. Qu'est-ce qu'OAuth2

OAuth2.0 est actuellement un mécanisme d'autorisation très largement utilisé pour autoriser des applications tierces à obtenir des données utilisateur.

Les utilisateurs peuvent utiliser gitee en choisissant d'autres méthodes de connexion , et l'authentification tierce est utilisée ici.

OAuth introduit une couche d'autorisation pour séparer deux rôles différents : le client et le propriétaire de la ressource. ... le propriétaire de la ressource accepte

Plus tard, le serveur de ressources peut délivrer un jeton au client. Le client demande des données via le jeton.

Deuxièmement, le rôle dans OAuth2

1. Propriétaire de la ressource (personne)

Une entité capable d'accorder l'accès à une ressource protégée, également appelée utilisateur final si le propriétaire de la ressource est un particulier

2. Serveur de ressources (APP)

Un serveur qui stocke les ressources protégées, accepte et vérifie les jetons d'accès et répond aux demandes d'accès aux ressources protégées

Pour faire simple, c'est l'endroit marqué sur la photo

3. Client (site Web autorisé)

Une entité qui doit être autorisée avant d'accéder à une ressource protégée. Le terme client ne fait pas spécifiquement référence aux applications, serveurs, ordinateurs, etc.

4. Serveur d'autorisation (fait référence à OAuth2)

Après avoir vérifié le propriétaire de la ressource et obtenu l'autorisation avec succès, émettez un jeton d'accès au client

Troisièmement, le processus de certification

Explication :

Le client est équivalent à l'applet en cours d'utilisation

Le propriétaire de la ressource est équivalent à mon compte WeChat

Le serveur d'autorisation est équivalent à OAuth2

Resource Server est équivalent à WeChat

Lorsque l'utilisateur choisit WeChat pour se connecter à un petit programme, le petit programme enverra une demande au compte WeChat de l'utilisateur. Lorsque l'utilisateur clique sur Autoriser, le petit programme enverra les informations d'autorisation à OAuth2 (c'est-à-dire le serveur d'authentification) , puis le serveur d'authentification enverra un jeton Token à l'applet après avoir obtenu les informations. Une connexion à l'applet sera autorisée.

Quatre, les caractéristiques du jeton

Avantages de l'utilisation de l'approche des jetons :

(1) Les jetons sont sensibles au temps, généralement à court terme et ne peuvent pas être modifiés, et les mots de passe sont généralement valides pendant une longue période

(2) Le jeton peut être révoqué par l'émetteur et prend effet immédiatement, et le mot de passe peut généralement être valide pendant une longue période sans modification

(3) Le jeton peut définir l'étendue de l'autorité et l'utilisateur ne peut pas la modifier

Lors de l'utilisation du jeton, il est nécessaire d'assurer la confidentialité du jeton. Si le jeton est vérifié comme étant valide, il peut entrer dans le système et aucune autre vérification ne sera effectuée.

Cinq, quatre méthodes d'authentification

Comme il existe de nombreux scénarios sur Internet, OAuth2 définit quatre façons d'obtenir des jetons, et vous pouvez choisir la manière qui vous convient

(1) Code d'autorisation ( code-autorisation )

(2) Caché ( implicite )

(3) Mot de passe ( mot de passe ) :

(4) Informations d'identification du client ( informations d'identification du client )

Code d'autorisation

L'application tierce demande d'abord un code d'autorisation, puis utilise le code pour obtenir un jeton.

L'usage le plus courant, haute sécurité, adapté aux applications web . Les codes d'autorisation sont transmis via le frontend, les jetons sont stockés dans le backend et tous

La communication avec le serveur d'origine se fait entièrement sur le backend. Une telle séparation des extrémités avant et arrière peut éviter les fuites de jetons.

Le processus est le suivant :

est ce qui est mentionné ci-dessus
1. Le serveur de ressources fournit un lien. Une fois que l'utilisateur a cliqué, il accède au serveur d'authentification et autorise les données utilisateur sur le serveur de ressources.

Un exemple de connexion fournie par un serveur de ressources :
https://b.com/oauth/authorize?
response_type=code&
client_id=CLIENT_ID&
redirect_uri=CALLBACK_URL&
scope=read
response_type=code , signifie utiliser la méthode du code d'autorisation

client_id=CLIENT_ID , l' ID d'identité du demandeur

scope = read redirect_uri=CALLBACK_URL , la connexion de redirection après que le serveur d'authentification accepte la demande, et le code généré peut être envoyé au serveur de ressources en fonction de cette connexion

scope=read , la portée autorisée est en lecture seule
2. Après le saut de page, l'utilisateur se connecte au serveur d'authentification, accepte ou rejette la demande d'autorisation du serveur de ressources et le serveur d'authentification

L'adresse redirect_uri renvoie le code d'autorisation généré au serveur de ressources.
https://resouce.com/callback_url?code=AUTHORIZATION_CODE
Le code d'authentification retourné par code
3. Une fois que le client a obtenu le code d'authentification, il envoie une demande au serveur d'authentification pour demander un jeton
https://b.com/oauth/token?
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET&
grant_type=authorization_code&
code=AUTHORIZATION_CODE&
redirect_uri=CALLBACK_URL
client_id L' ID d'identité du serveur de ressources

client_secret=Paramètre de sécurité CLIENT_SECRET , ne peut envoyer des requêtes que sur le backend

grant_type=authorization_code indique que la méthode d'autorisation est le code d'autorisation

code=AUTHORIZATION_CODE Le code d'autorisation utilisé pour obtenir le jeton

redirect_uri=CALLBACK_URL a émis l'adresse après la génération du jeton
4. Le serveur d'authentification authentifie le code d'autorisation et émet un jeton après avoir transmis le code d'autorisation.
{
"access_token":访问令牌,
"token_type":"bearer",
"expires_in":过期时间,
"refresh_token":"REFRESH_TOKEN",
"scope":"read",
"uid":用户ID,
"info":{...}
}

chemin caché

Scénarios où la méthode de masquage est appropriée :

Lorsque l'application Web est une application purement frontale sans back-end, le jeton doit être enregistré sur le front-end à ce moment, en omettant l'étape de demande d'un code d'autorisation

1. Le serveur de ressources fournit une connexion et saute vers le serveur d'authentification
https://b.com/oauth/authorize?
response_type=token&
client_id=CLIENT_ID&
redirect_uri=CALLBACK_URL&
scope=read
2. L'utilisateur doit se connecter au serveur d'authentification et autoriser. Une fois l'autorisation réussie, le jeton généré sera renvoyé en fonction de l'adresse CALLBACK_URL fournie à la première étape.

Les caractéristiques de cette méthode : Cette méthode n'est pas sûre et convient aux scénarios à faible sécurité. La période de validité du jeton est généralement définie pour être relativement courte, et elle est généralement valide pendant la session. Lorsque le navigateur ferme le jeton, il va expirer

Mot de passe

Faites très confiance à une application, indiquez directement à l'application le nom d'utilisateur et le mot de passe, et demandez un jeton directement après que l'application a obtenu le nom d'utilisateur et le mot de passe

1. Le serveur de ressources demande à l'utilisateur de fournir le nom d'utilisateur et le mot de passe du serveur d'authentification, et après l'avoir obtenu, le serveur de ressources demande un jeton du serveur d'authentification
https://oauth.b.com/token?
grant_type=password&
username=USERNAME&
password=PASSWORD&
client_id=CLIENT_ID
grant_type= méthode d'authentification par mot de passe

nom d'utilisateur= NOM D'UTILISATEUR

password= PASSWORDmot de passe

client_id=CLIENT_ID identifiant client
2. Une fois que le serveur d'authentification a réussi la vérification d'identité, il émettra un jeton directement dans la réponse et le serveur de ressources obtiendra le jeton dans la réponse.

Crédits

Cette méthode convient aux applications en ligne de commande sans frontaux, demandant des jetons via la ligne de commande
1. Le serveur de ressources utilise la ligne de commande pour envoyer une requête au serveur d'authentification
https://oauth.b.com/token?
grant_type=client_credentials&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET
grant_type=client_credentials méthode d'identification

client_id=ID_CLIENT ID client

client_secret= code d'authentification CLIENT_SECRET

Le véritable avantage de cette méthode est que les applications tierces, et non les utilisateurs, peuvent partager un jeton avec plusieurs utilisateurs

Premiers pas avec OAuth2