Avec cet article, je souhaite ouvrir une série d'articles dédiés à IdentityServer4. Nous commencerons par les concepts de base.
Le protocole d'authentification le plus prometteur actuellement est , et le protocole d'autorisation (d'accès) est . met en œuvre ces deux protocoles. Il est optimisé pour résoudre des problèmes typiques de sécurité.
— c'est un protocole et une norme d'authentification, il ne donne pas accès aux ressources (Web API), mais étant donné qu'il est développé au-dessus du protocole d'autorisation , il permet d'obtenir les paramètres du profil utilisateur comme si vous aviez accès à la ressource .
(JSON Web Token) est une norme web qui définit comment transmettre des données utilisateur au format JSON de manière sécurisée.
— est un protocole et une norme d'autorisation. Il permet aux applications d'accéder à des ressources protégées, par exemple, des Web API.
Examinons le diagramme d'accès à une ressource protégée et comprenons les principales étapes et la terminologie acceptée :
Le client demande à l'utilisateur la permission de s'authentifier en son nom. Client — c'est l'application cliente qui accède aux ressources protégées au nom du propriétaire des ressources. Ressource — ce sont tous nos services protégés .
L'utilisateur permet à l'application cliente de s'authentifier en son nom, par exemple, en saisissant son identifiant et son mot de passe. L'identifiant et le mot de passe serviront de donneurs d'autorisation pour l'application cliente. Utilisateur (propriétaire de la ressource) — un programme ou une personne qui peut accorder l'accès aux ressources protégées, par exemple, en saisissant un identifiant (username) et un mot de passe (password) ;
L'application cliente demande un jeton d'accès à
IdentityServer4en fournissant des informations sur elle-même (client_id,client_secret), en fournissant la permission d'autorisation de l'utilisateur (username,password) et en fournissantgrant_typeetscope. Ensuite, le serveur d'autorisation vérifie l'authenticité du client et les identifiants du propriétaire de la ressource (identifiant et mot de passe).Le protocole OAuth 2.0 authentifie non seulement l'utilisateur, mais aussi l'application cliente accédant aux ressources. Pour cela, le protocole prévoit des paramètres tels que client_id et client_secret.
client_id — c'est l'identifiant de l'application cliente, utiliséIdentityServer4pour rechercher des informations sur le client.
client_secret est l'équivalent d'un mot de passe pour l'application cliente et est utilisé pour l'authentification de l'application cliente surIdentityServer4. Le secret du client doit être connu uniquement de l'application et de l'API. Au regard de ce qui précède, nous concluons que IdentityServer4 doit connaître ses clients.Si l'authenticité de l'application est confirmée et si la permission d'autorisation est valide,
IdentiryServer4génèreun token d'accès(access token) pour l'application et un jeton de renouvellement facultatif (refresh-token). 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é.L'application cliente demande des données à l'API Web protégée, en fournissant le token d'accès pour l'autorisation. Si le code de réponse du serveur de ressources , ou , alors le token d'accès utilisé pour l'authentification est invalide ou expiré.
Si le token est valide,
Web APIil fournit les données à l'application.
Types de tokens
Aux clients enregistrés il est permis de demander IdentityServer4 un identity-token, IdentityServer4 identity-token, un access-token et un refresh-token.
- identity-token (token d'identification) — résultat du processus d'authentification. Il contient l'identifiant de l'utilisateur et des informations sur la manière et le moment où l'utilisateur s'authentifie. Peut être enrichi avec vos propres données.
- access-token (token d'accès) — est transmis à l'API protégée et utilisé par celle-ci pour l'autorisation (permission d'accès) à ses données.
- refresh-token (token de renouvellement) — un paramètre optionnel que le serveur d'autorisation peut renvoyer en réponse à la demande du token d'accès.
Introduisons encore deux concepts :
Authenticatation Server Url — point final pour obtenir la clé d'accès. Toutes les demandes d'octroi et de renouvellement des clés d'accès seront dirigées vers cette URL.
Resource Url — URL du recurso protégé auquel il faut accéder, en transmettant la clé d'accès dans l'en-tête d'autorisation.
Demande de clé d'accès
Pour demander la clé d'accès, le client effectue un POST requête au point final IdentityServer4 avec l'en-tête suivant
'Content-Type': 'application/x-www-form-urlencoded',
'Accept': 'application/json',
'Expect': '100-continue'et en transmettant 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 et client_secret ont été discutés ci-dessus. Analyserons les autres paramètres :
grant_type — type de grant ou type de permission d'autorisation. Le type de permission d'autorisation dépend de la méthode de demande d'autorisation utilisée par l'application, ainsi que des types de permissions pris en charge par l'API. Dans notre cas, il aura la valeur password, ce qui conformément à la spécification OAuth 2.0 correspond au grant de credentials d'accès du propriétaire de la ressource (authentification par identifiant et mot de passe).
Protocole OAuth 2.0 définit les types de grants suivants nécessitant une interaction obligatoire avec les utilisateurs:
- code d'autorisation (authorization code). C'est l'un des types de permission d'autorisation les plus répandus, car il convient bien aux applications côté serveur, où le code source de l'application et le secret client ne sont pas accessibles aux tiers;
- implicite (implicit). Le type implicite de permission d'autorisation est utilisé par des applications mobiles et web, où la confidentialité du secret client ne peut pas être garantie;
Et les types de grants qui peuvent être exécutés sans interaction active avec les utilisateurs:
- credentials du propriétaire de la ressource (resource owner). Ce type d'autorisation ne doit être utilisé que lorsque l'application cliente jouit de la confiance de l'utilisateur et que l'utilisateur est à l'aise avec la saisie de son identifiant et de son mot de passe. Ce type d'autorisation doit être utilisé uniquement lorsque d'autres options ne sont pas disponibles. Ce type d'autorisation est pratique pour les clients d'entreprise qui ont déjà utilisé les identifiants de l'utilisateur dans leur système et souhaitent passer à
OAuth 2.0. - les identifiants du client. Ils sont utilisés lorsque l'application accède à l'API. Cela peut être utile, par exemple, lorsque l'application souhaite mettre à jour ses propres informations d'enregistrement sur le service ou l'URI de redirection, ou accéder à d'autres informations stockées dans le compte de l'application sur le service, via l'API du service.
scope — c'est un paramètre facultatif. Il définit la portée. Le jeton d'accès renvoyé par le serveur garantira l'accès uniquement aux services qui entrent dans cette portée. Autrement dit, nous pouvons regrouper plusieurs services sous une seule portée et si le client obtient la clé d'accès à cette portée, il obtient accès à tous ces services. La portée peut également être utilisée pour limiter les droits d'autorisation (par exemple, accès en lecture ou en écriture)
Source : habr.com
