À partir de ce moment, j'expliquerai comment réaliser l'authentification / l'autorisation de l'API REST à l'aide du flux d'octroi de code d'autorisation OAuth 2.0 à l'aide de Spring Security OAuth (+ Spring Boot) à plusieurs reprises (probablement environ 3 à 5 fois). Faire. En disant ... je ne suis pas familier avec OAuth 2.0 non plus ... Il peut y avoir une mauvaise explication (pas mal ...): sweat_smile: Si vous trouvez une mauvaise explication, merci de laisser un commentaire (demande de correction). S'il vous plaît! !!

Donc, cette fois de la première fois ... Je voudrais expliquer brièvement ce qu'est OAuth 2.0 (= revue). Au fait ... je ne parle pas de Spring Security OAuth et Spring Boot cette fois ~: stuck_out_tongue_winking_eye:

Partie 2: Créer une application pour le moment

Qu'est-ce que OAuth 2.0?

Tout d'abord, jetons un coup d'œil à OAuth 2.0. OAuth 2.0 est un cadre d'autorisation qui permet aux fournisseurs de services de fournir des plages d'accès (étendues) appropriées aux clients lorsqu'ils fournissent des ressources WEB à des «applications tierces (ci-après les clients)». , Certaines RFC ont des spécifications techniques.

En plus de ce qui précède, il existe également un RFC pour utiliser JWT (JSON Web Token) comme jeton d'accès.

Dans cette entrée, je pense que vous devriez savoir au moins si vous utilisez OAuth 2.0, et je voudrais expliquer brièvement l'architecture d'OAuth 2.0 en me concentrant sur le contenu (rôle, octroi d'autorisation, portée, jeton d'accès, jeton d'actualisation, etc.). Je vais.

Rôle

OAuth 2.0 définit les quatre rôles suivants qui apparaissent lors de l'exécution de l'authentification / autorisation.

rouleau	La description
Resource Owner	Le propriétaire de la ressource, chargé d'autoriser l'accès à la ressource (octroi des autorisations). Les utilisateurs de services (humains) jouent souvent ce rôle.
Resource Server	Il est chargé de fournir les ressources du propriétaire de la ressource sous un contrôle d'accès approprié (contrôle d'accès utilisant la portée attribuée au jeton d'accès). Le serveur Web du fournisseur de services joue ce rôle.
Authorization Server	Authentification du propriétaire de la ressource, autorisation du propriétaire de la ressource(Obtention d'une subvention sous licence), Responsable de l'émission des jetons d'accès correspondant aux subventions autorisées. Le serveur Web du fournisseur de services joue ce rôle.
Client	Responsable de l'accès aux ressources protégées au nom du propriétaire de la ressource à l'aide du jeton d'accès correspondant à l'octroi d'autorisation fourni par le propriétaire de la ressource. Application Web, application client basée sur un agent utilisateur(JavaScript, etc.), Les applications natives, etc. jouent ce rôle.

La représentation graphique de l'interaction entre les rouleaux (flux de protocole) ressemble à ce qui suit.

spring-security-oauth-oauth2.0.png

Subvention autorisée

Dans OAuth 2.0, l'octroi de l'accès aux ressources est appelé "octroi d'autorisation" et les quatre types suivants sont définis comme types d'octroi.

Type de subvention	La description
Authorization Code	Le propriétaire de la ressource émet un code d'autorisation (un code indiquant que l'accès à la ressource est autorisé) via le serveur d'autorisation et le fournit au client. Étant donné que le client échange le jeton d'accès avec le code d'autorisation fourni par le propriétaire de la ressource, les informations d'identification du propriétaire de la ressource (nom d'utilisateur et mot de passe) ne sont pas transmises au client et on peut dire qu'il s'agit du type d'octroi le plus sécurisé.
Implicit	Le point où le propriétaire de la ressource autorise l'accès à la ressource via le serveur d'autorisation est le même que l'octroi du code d'autorisation, mais dans le cas de l'octroi implicite, le jeton d'accès est émis directement après l'autorisation. Comme pour l'octroi du code d'autorisation, les informations d'identification du propriétaire de la ressource (nom d'utilisateur et mot de passe) ne sont pas transmises au client, mais la sécurité est inférieure à l'octroi du code d'autorisation car le client n'est pas authentifié.
Resource Owner Password Credential	Émettez un jeton d'accès en transmettant les informations d'identification du propriétaire de la ressource (nom d'utilisateur et mot de passe) en tant qu'octroi d'autorisation. Puisqu'il est nécessaire de transmettre les informations d'identification du propriétaire de la ressource au client, il existe un risque accru d'utilisation abusive des informations d'identification du propriétaire de la ressource dans le cas d'un client non approuvé ou malveillant.
Client Credential	Un jeton d'accès est émis en transmettant les informations d'identification du client (ID client et mot de passe) en tant qu'octroi d'autorisation. Il s'agit d'un type d'octroi utilisé lorsque le client lui-même est comme un propriétaire de ressource.

portée

OAuth 2.0 utilise le concept d'étendue pour limiter les ressources auxquelles les clients peuvent accéder. La portée qui peut être gérée est gérée par le serveur d'autorisation et le client peut spécifier la «portée que vous souhaitez autoriser» lors de la demande de délivrance du code d'autorisation ou du jeton d'accès.

Jeton d'accès

Dans OAuth 2.0, le jeton d'accès est échangé avec l'octroi d'autorisation fourni par le propriétaire de la ressource, et lors de l'accès à la ressource, le jeton d'accès est transmis pour authentification / autorisation. Le jeton d'accès peut avoir une date d'expiration, et lorsque la date d'expiration expire, il est nécessaire d'obtenir à nouveau l'autorisation du propriétaire de la ressource. Si la date d'expiration est courte, l'utilisabilité de l'utilisateur de l'application sera faible, et inversement, si la date d'expiration est longue, le risque de mauvaise utilisation due à une fuite / fuite de jetons d'accès augmentera.

Jeton d'actualisation

Existe-t-il un moyen de réduire la convivialité sans augmenter le risque de fuites de jetons d'accès? ... bien sûr qu'il y en a! !! "Refresh token" résout ce problème à la fois. Un jeton d'actualisation est un jeton utilisé pour réémettre un jeton d'accès lorsque le jeton d'accès a expiré. En utilisant le jeton d'actualisation, vous pouvez émettre un nouveau jeton d'accès avec la même portée que lorsque vous avez obtenu le jeton d'accès, de sorte que vous pouvez éviter de demander au propriétaire de la ressource de réautoriser. Vous pouvez également définir une date d'expiration pour le jeton d'actualisation, et une fois que le jeton d'actualisation expire, vous ne pourrez pas réémettre le jeton d'accès (= vous devrez à nouveau obtenir l'autorisation du propriétaire de la ressource).

Stratégie d'expiration du jeton d'accès et d'actualisation du jeton

Il semble être une pratique courante de conserver la convivialité de l'utilisateur sans augmenter le risque de fuite de jeton d'accès en raccourcissant autant que possible la date d'expiration du jeton d'accès et en prolongeant la date d'expiration du jeton d'actualisation.

Flux de flux d'octroi de code d'autorisation

L'introduction est devenue un peu longue, mais à partir de là, voyons comment accéder aux ressources en utilisant le "flux d'octroi de code d'autorisation" traité dans cette entrée.

spring-security-oauth-oauth2.0-code-grant.png

Numéro d'article	La description
(1)	Le propriétaire de la ressource fait une demande d'affichage d'une page arbitraire (page accédant au serveur de ressources) fournie par le client via l'agent utilisateur. Le client répond par une instruction de redirection vers l'écran d'autorisation du serveur d'autorisation afin d'obtenir l'autorisation du propriétaire de la ressource.
(2)	L'agent utilisateur est la page instruite par le client(Écran d'autorisation du serveur d'autorisation)Faites une demande d'affichage (redirection). Le serveur d'autorisation répond avec un écran pour obtenir l'autorisation du propriétaire de la ressource via l'agent utilisateur.
(3)	Le propriétaire de la ressource fait une demande d'approbation pour la demande d'autorisation demandée par le client via l'agent utilisateur. Le serveur d'authentification émet un code (code d'autorisation) indiquant que le propriétaire de la ressource a autorisé l'accès à la ressource, puis à nouveau.(1)Le propriétaire de la ressource répond avec une instruction de redirection vers la page du client qui a effectué la demande d'affichage. De plus, le code d'autorisation est ajouté au paramètre de l'URL pour la redirection et lié.
(4)	L'agent utilisateur fait une demande d'affichage (redirection) pour la page demandée par le serveur d'autorisation (la page du client que le propriétaire de la ressource a demandé en premier à afficher). Le client récupère la ressource du propriétaire de la ressource auprès du serveur de ressources (détails 5),(Reportez-vous à 6), puis répondez avec une page qui intègre les informations sur les ressources acquises.
(5)	Le client acquiert un code d'autorisation à partir du paramètre de demande, spécifie le code d'autorisation acquis et demande l'émission d'un jeton d'accès. Le serveur d'autorisation émet un jeton d'accès après avoir vérifié la validité du code d'autorisation et répond le jeton d'accès au client.
(6)	Le client appelle l'API REST du serveur de ressources en spécifiant le jeton d'accès obtenu du serveur d'autorisation. Après avoir vérifié la validité du jeton d'accès et de l'étendue, le serveur de ressources appelle le processus d'API REST et répond au client avec les ressources renvoyées par l'API REST.

Résumé

La partie 1 était un examen rapide d'OAuth 2.0. Le contenu décrit dans cette entrée n'est qu'une partie des spécifications définies par OAuth 2.0, mais nous vous serions reconnaissants si vous pouviez imaginer à peu près le flux du flux d'octroi de code d'autorisation. (Je n'en suis pas sûr ...: sweat_smile :) La prochaine fois, j'aimerais utiliser Spring Security OAuth (+ Spring Boot) pour faire l'expérience de l'authentification / autorisation de l'API REST à l'aide du flux d'octroi de code d'autorisation. (Je ne sais pas quand ce sera, mais la prochaine fois ~)

[JAVA] Expérimentons le flux d'octroi de code d'autorisation avec Spring Security OAuth-Part 1: Review of OAuth 2.0