Sur les sites Web de tous les jours, nous voyons souvent des boutons de connexion à partir de sites de réseaux sociaux, tels que Facebook, Twitter, etc. Et derrière cela se trouve la base OAuth2 un framework qui fournit des fonctionnalités d’autorisation grâce auxquelles nous pouvons permettre à des sites tiers d’obtenir notre autorisation d’utilisateur, tout comme nous pouvons obtenir les surnoms d’utilisateur, une photo de profil sur Facebook ou Weibo. OAuth2 fournit des fonctionnalités de licence qui incluent des applications de bureau, web et mobiles.

Le rôles de l'autorisation

l’autorisation définit généralement les quatre identités suivantes :

  • nom d'utilisateur
  • client id
  • serveur de ressources
  • serveur d’autorisation

nom d'utilisateur

Nous définissons généralement le propriétaire d’une ressource par un nom d'utilisateur qui permet à ces applications d’accéder à leurs informations de compte. Bien sûr, ces applications ont un accès limité, et elles sont limitées à une portée protégée (par exemple, elles ne peuvent lire que des informations, en fonction de notre propre conception, bien sûr).

autoriser les services de serveur et d’interface

une fois que l’utilisateur a correctement demande le service d’autorisation, un jeton aceess est renvoyé à l’application afin que l’application ait les informations d’identification de d'utilisateur lorsqu’elle accède au services d’interface.

application cliente id

l’application cliente id est le profile que l’utilisateur utilise actuellement. il peut accéder ou modifier certaines informations de l’utilisateur après une autorisation réussie de l’utilisateur par son intermédiaire, mais dans tous les cas, lors de la demande d’informations de l'utilisateur, nos services d’api et d’autorisation doivent vérifier leur légalité.

le processus d’autorisation

enregistrement de l’application

avant de pouvoir faire une demande l’autorisation, vous devez avoir les information de l'applications du clientes enregistrées, et vous en avez besoin pour fournir des informations de base tels que le nom de l’application, l’adresse du site web, l’adresse de rappel, etc. où l’adresse de rappel est à la fois l’adresse où l’utilisateur sera envoyer après avoir terminé l’autorisation pour que l’application sera en mesure de traiter le code d’autorisation que nous retournons ainsi que les jetons d’accès.

client_id et client_secret 

Une fois l’enregistrement de l’application terminé, nous émettons un certificat d’autorisation à l’application qui enregistre approximativement l’identification unique du client (identifiant client) et le code de sécurité du client.
client_id est une chaîne de rafales utiliser avec l’URL à laquelle l’utilisateur crée l’accès et la validation utilisée pour le serveur. La clé secrète client_secret est utilisée pour certifier l’unicité de l’application, garantissant ainsi la confidentialité de l’application et des services API.

licence

Dans le processus précédent, la première étape consistait à obtenir une licence et le type d’acces token de l'autorisation en fonction du type de demande de l’utilisateur. OAuth 2 définit les quatre types de licences suivants, qui sont utiliser dans différentes situations.

  • code d’autorisation, souvent utilisé côté service;

  • mode simplifié, souvent utilisé sur les appareils mobiles;

  • vérification du mot de passe de l’utilisateur, souvent utilisée pour des services plus fiables, tels que des projets au sein de l’équipe;

  • authentification du client pour l’accès à l’api d’application ;

code d’autorisation

Actuellement, la plupart des applications d'autorisations côté service s’appliquent de cette façon, et il maintient une clé secrète client_secret. L’application obtient le code d’autorisation de l’API via le client_id (tel que le navigateur) ;

1. l’utilisateur recevra une autorisation qui apportera probablement certaines informations de base, telles que

client_id redirect_uriresponse_type(id de l’application), (l’adresse du rappel), (type de licence, similaire), etc. 

2. autorisation de application par l’utilisateur, l’utilisateur entrera dans l’interface d’autorisation ou il peux confirmer l’acceptation de la demande d’autorisation de l’application ou de refuser la demande.

3. si l’utilisateur clique sur l’url qui confirme l’autorisation, il obtiendra le code d’autorisation à son redirect_uri pour le changer contre un acces token.

http://yousite.com?code=AUTHORIZATION_CODE

4. l’application obtient un code pour demande à l'api d'obtenir un access_token pour l'utilisation.

5. l’application acceptera la réponse de l’interface, accédera à un access_token, certaines applications apporteront également un refresh_token.

après avoir obtenu un access_token, l’application aura accès à certaines interfaces ouvertes, et si les interfaces expirent elles doivent être réautorisées. si
un refresh_token renvoie un nouveau access_token il peut être demandé par le refresh_token.

licences pour les modes simplifiés

L’autorisation en mode simplifié est plus adaptée aux applications mobiles et aux applications web car leurs sécurités n’est pas garantie. Il ons un processus simple, qui peux être renvoyé directement au client, de sorte que un access_token soit exposés directement à l’utilisateur, ainsi qu’à d’autres applications sur l’appareil. En outre, le service ne représente pas l’authentification de l’application de manière unique, en s’appuyant sur l’adresse du rappel qui utilise un access_token

l’autorisation du mode simplifié ne supporte pas le refresh_token

  1. l’application demande un access_token via un lien;
  2. lorsque l’utilisateur clique sur le lien, il ouvre l’interface de la demande l’autorisation de l’utilisateur;
  3. une fois que l’utilisateur autorisée, un access_token sera directement redirigé vers l’adresse redirect_uri similaire à la suivante:
http://yoursite.com?access_token=ACCESS_TOKEN
  1. le client enregistre le access_token apporté, tel qu’un cookie;
  2. l’application demande à l'api d'apportent cette access_token.

le formulaire de vérification du mot de passe de l’utilisateur

ce formulaire est directement le compte d’utilisateur et le mot de passe pour accéder a ses services, pour obtenir le access_token, généralement ce modèle n’est utilisé que pour leurs propres services de confiance, tels que leurs propres produits ou applications de bureau.

l’application vérifie les données lorsqu’elle obtient le mot de passe et le nom l’utilisateur à l'adresse de la demande

http://oauth.api.xxxx.com?username=USERNAME&password=PASSWORD&clientID=1232112

une fois vérifié, le service d’autorisation renvoie un access_token pour autorisée l’application.

authentification du client

l’authentification du client consiste principalement à fournir aux applications un moyen d’accéder à leurs comptes et services, et de mettre à jour certaines informations de description, d’adresses de rappel, etc. prenez votre confiance en demandant une adresse, puis obtenir un access_token.

utilisation de refresh_token

généralement access_token à une duré limite dans le temps, une fois expirée il faut demande un autre pour l’accès aux services, certains fourniront une interface pour obtenir un nouveau access_token, il vous suffit d’apporter un refresh_token et d’autres informations du client.