Serveur d'identité4. Concepts de base. OpenID Connect, OAuth 2.0 et JWT

Avec cet article, je souhaite ouvrir un fil d'articles dédié à IdentityServer4. Commençons par les concepts de base.

Le protocole d'authentification le plus prometteur à l'heure actuelle est OpenID Connect, et le protocole d'autorisation (d'accès) est OAuth 2.0. Serveur d'identité4 implémente ces deux protocoles. Il est optimisé pour résoudre problèmes typiques la sécurité.

OpenID Connect est un protocole et un standard d'authentification, il ne donne pas accès aux ressources (API Web), mais comme il est conçu au-dessus du protocole d'autorisation OAuth 2.0, il vous permet d'obtenir les paramètres du profil utilisateur comme si vous accédiez à la ressource Informations utilisateur.

JWT (JSON Web Token) est un standard Web qui définit la manière dont les données utilisateur sont transmises au format JSON sous forme cryptée.

OAuth 2.0 (RFC6749) est un protocole et une norme d’autorisation. Il permet aux applications d'accéder à des ressources protégées telles que les API Web.

Jetons un coup d'œil au schéma d'accès à une ressource protégée et comprenons les principales étapes et la terminologie acceptée :

1. Le client demande à l'utilisateur l'autorisation de s'authentifier en son nom. Client est une application client accédant aux ressources protégées au nom du propriétaire de la ressource. ressource - ce sont tous nos services sécurisés API Web.

2. L'utilisateur autorise l'application client à transmettre l'autorisation en son nom, par exemple, saisit un nom d'utilisateur et un mot de passe. Le login et le mot de passe constitueront l'octroi d'autorisation pour l'application client. Utilisateur (propriétaire de la ressource) - un programme ou une personne pouvant donner accès à des ressources protégées, par exemple en saisissant un identifiant (nom d'utilisateur) et un mot de passe (mot de passe) ;

3. L'application client demande un jeton d'accès à IdentityServer4 en fournissant des informations sur vous-mêmeclient_id, client_secret), accordant l'autorisation d'autorisation à l'utilisateur (username, password) et en fournissant grant_type и scope. Ensuite, le serveur d'autorisation authentifie le client et les détails du propriétaire de la ressource (identifiant et mot de passe).

   Le protocole OAuth 2.0 authentifie non seulement l'utilisateur, mais également l'application client accédant aux ressources. Pour ce faire, le protocole fournit des paramètres tels que client_id и client_secret.
   identité du client est l'ID de l'application client utilisé IdentityServer4 pour rechercher des informations sur les clients.
   client_secret est un analogue du mot de passe de l'application client et est utilisé pour authentifier l'application client sur IdentityServer4. Le secret client ne doit être connu que de l'application et de l'API. Sur la base de ce qui précède, nous concluons que IdentityServer4 a besoin de connaître ses clients.

4. Si l'authenticité de la demande est confirmée et que l'autorisation d'autorisation est valide, IdentiryServer4 crée access-токен (jeton d'accès) pour l'application et une clé d'actualisation facultative (refresh-токен). Le processus d'autorisation est terminé. Si la demande est invalide ou non autorisée, le serveur d'autorisation renvoie un code avec un message d'erreur approprié.

5. L'application client demande des données à une API Web sécurisée, tout en fournissant un jeton d'accès pour l'autorisation. Si le code de réponse du serveur de ressources 401, 403 ou 498, alors le jeton d'accès utilisé pour l'authentification est invalide ou a expiré.

6. Si le jeton est valide, Web API fournit des données à l’application.

Types de jetons

Enregistré IdentityServer4 les clients sont autorisés à demander IdentityServer4 identity-jeton, access-jeton et refresh-jeton.

• jeton d'identité (jeton d'identification) - le résultat du processus d'authentification. Contient l'ID utilisateur et des informations sur la manière et le moment où l'utilisateur est authentifié. Vous pouvez étendre vos données.
• jeton d'accès (jeton d'accès) - transmis à une API sécurisée et utilisé par eux pour autoriser (permettre l'accès) à leurs données.
• jeton d'actualisation (jeton d'actualisation) est un paramètre facultatif que le serveur d'autorisation peut renvoyer en réponse à une demande de jeton d'accès.

Introduisons deux autres concepts :

URL du serveur d'authentification - Point final pour obtenir le jeton d'accès. Toutes les demandes de fourniture et de renouvellement de clés d'accès seront envoyées à cette URL.

URL de la ressource — L'URL de la ressource protégée à accéder pour y accéder, en lui transmettant la clé d'accès dans l'en-tête d'autorisation.

Demande de clé d'accès

Pour demander une clé d'accès, le client fait POST demande de point de terminaison IdentityServer4 avec le titre suivant

'Content-Type': 'application/x-www-form-urlencoded',
'Accept': 'application/json',
'Expect': '100-continue'

et en passant les paramètres suivants :

'grant_type' : 'password',
'username' : login,
'password' : password,
'scope' : 'scope',
'client_id' : 'client_id',
'client_secret' : '{client_secret}'

username, password, client_id и client_secret ont été démontés ci-dessus. Regardons le reste des options :

type_octroi — type d'octroi ou type d'autorisation d'autorisation. Le type d'autorisation d'autorisation dépend de la méthode utilisée par l'application pour demander l'autorisation, ainsi que des types d'autorisation pris en charge par l'API. Dans notre cas, ce sera important password, qui selon la spécification OAuth 2.0 correspond à l'attribution des droits d'accès du propriétaire de la ressource (autorisation par login et mot de passe).

Protocole OAuth 2.0 définit les types de subventions suivants nécessitant interaction obligatoire avec les utilisateurs:

• Code d'autorisation. Il s'agit de l'un des types d'autorisation d'autorisation les plus courants, car bien adapté aux applications côté serveur où le code source de l'application et le secret client ne sont pas accessibles aux tiers ;
• implicite. Le type d'autorisation d'autorisation implicite est utilisé par les applications mobiles et Web où la confidentialité du secret client ne peut être garantie ;

Et les types de subventions qui peut être exécuté sans interaction interactive avec les utilisateurs:

• détails du propriétaire de la ressource. Ce type d'autorisation ne doit être utilisé que si l'application client est approuvée par l'utilisateur et que l'utilisateur est à l'aise pour saisir son nom d'utilisateur et son mot de passe. Ce type d'autorisation ne doit être utilisé que lorsqu'aucune autre option n'est disponible. Ce type d'autorisation est utile pour les entreprises clientes qui ont déjà utilisé les informations d'identification des utilisateurs dans leur système et souhaitent passer à OAuth 2.0.
• informations d'identification du client. Utilisé lorsque l'application accède à l'API. Cela peut être utile, par exemple, lorsqu'une application souhaite mettre à jour ses propres informations d'enregistrement de service ou rediriger l'URI, ou accéder à d'autres informations stockées dans le compte de service de l'application via l'API du service.

portée est un paramètre facultatif. Il en définit le champ d'application. Le jeton d'accès renvoyé par le serveur autorisera uniquement l'accès aux services dans cette étendue. Ceux. nous pouvons combiner plusieurs services sous un seul périmètre et si le client reçoit une clé d'accès à ce périmètre, il a accès à tous ces services. La portée peut également être utilisée pour restreindre les droits d'autorisation (par exemple, accès en lecture ou en écriture)

Source: habr.com