{"id":71307,"date":"2020-02-24T22:18:55","date_gmt":"2020-02-24T19:18:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/identityserver4-osnovnye-ponyatiya-openid-connect-oauth-2-0-i-jwt"},"modified":"2020-03-03T16:14:27","modified_gmt":"2020-03-03T13:14:27","slug":"identityserver4-osnovnye-ponyatiya-openid-connect-oauth-2-0-i-jwt","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/identityserver4-osnovnye-ponyatiya-openid-connect-oauth-2-0-i-jwt","title":{"rendered":"IdentityServer4. Concepts de base. OpenID Connect, OAuth 2.0 et JWT","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Avec cet article, je souhaite ouvrir une s\u00e9rie d'articles d\u00e9di\u00e9s \u00e0 IdentityServer4. Nous commencerons par les concepts de base.<\/p>\n

<\/p>\n

Le protocole d'authentification le plus prometteur actuellement est OpenID Connect<\/a><\/noindex>, et le protocole d'autorisation (d'acc\u00e8s) est OAuth 2.0<\/a><\/noindex>. IdentityServer4<\/a><\/noindex> met en \u0153uvre ces deux protocoles. Il est optimis\u00e9 pour r\u00e9soudre des probl\u00e8mes typiques<\/strong> de s\u00e9curit\u00e9.<\/p>\n

<\/a><\/noindex><\/p>\n

OpenID Connect<\/a><\/noindex> \u2014 c'est un protocole et une norme d'authentification, il ne donne pas acc\u00e8s aux ressources (Web API), mais \u00e9tant donn\u00e9 qu'il est d\u00e9velopp\u00e9 au-dessus du protocole d'autorisation OAuth 2.0<\/a><\/noindex>, il permet d'obtenir les param\u00e8tres du profil utilisateur comme si vous aviez acc\u00e8s \u00e0 la ressource UserInfo<\/a><\/noindex>.<\/p>\n

JWT<\/a><\/noindex> (JSON Web Token) est une norme web qui d\u00e9finit comment transmettre des donn\u00e9es utilisateur au format JSON de mani\u00e8re s\u00e9curis\u00e9e.<\/p>\n

OAuth 2.0 (RFC 6749)<\/a><\/noindex> \u2014 est un protocole et une norme d'autorisation. Il permet aux applications d'acc\u00e9der \u00e0 des ressources prot\u00e9g\u00e9es, par exemple, des Web API.<\/p><\/blockquote>\n

Examinons le diagramme d'acc\u00e8s \u00e0 une ressource prot\u00e9g\u00e9e et comprenons les principales \u00e9tapes et la terminologie accept\u00e9e :<\/p>\n

<\/p>\n

\"IdentityServer4.<\/p>\n

<\/p>\n

    \n
  1. \n

    Le client demande \u00e0 l'utilisateur la permission de s'authentifier en son nom. Client<\/strong> \u2014 c'est l'application cliente qui acc\u00e8de aux ressources prot\u00e9g\u00e9es au nom du propri\u00e9taire des ressources. Ressource<\/strong> \u2014 ce sont tous nos services prot\u00e9g\u00e9s Web API<\/a><\/noindex>.<\/p>\n

    \n<\/li>\n

  2. \n

    L'utilisateur permet \u00e0 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\u00e9taire de la ressource)<\/strong> \u2014 un programme ou une personne qui peut accorder l'acc\u00e8s aux ressources prot\u00e9g\u00e9es, par exemple, en saisissant un identifiant (username) et un mot de passe (password) ;<\/p>\n

    \n<\/li>\n

  3. \n

    L'application cliente demande un jeton d'acc\u00e8s \u00e0 IdentityServer4<\/code> en fournissant des informations sur elle-m\u00eame (client_id<\/code>, client_secret<\/code>), en fournissant la permission d'autorisation de l'utilisateur (username<\/code>, password<\/code>) et en fournissant grant_type<\/code> et scope<\/code>. Ensuite, le serveur d'autorisation v\u00e9rifie l'authenticit\u00e9 du client et les identifiants du propri\u00e9taire de la ressource (identifiant et mot de passe). <\/p>\n

    <\/p>\n

    Le protocole OAuth 2.0 authentifie non seulement l'utilisateur, mais aussi l'application cliente acc\u00e9dant aux ressources. Pour cela, le protocole pr\u00e9voit des param\u00e8tres tels que client_id<\/strong> et client_secret<\/strong>.
    \nclient_id<\/strong> \u2014 c'est l'identifiant de l'application cliente, utilis\u00e9 IdentityServer4<\/code> pour rechercher des informations sur le client.
    \nclient_secret<\/strong> est l'\u00e9quivalent d'un mot de passe pour l'application cliente et est utilis\u00e9 pour l'authentification de l'application cliente sur IdentityServer4<\/code>. Le secret du client doit \u00eatre connu uniquement de l'application et de l'API<\/strong>. Au regard de ce qui pr\u00e9c\u00e8de, nous concluons que IdentityServer4 doit conna\u00eetre ses clients<\/strong>.<\/p><\/blockquote>\n

    \n<\/li>\n

  4. \n

    Si l'authenticit\u00e9 de l'application est confirm\u00e9e et si la permission d'autorisation est valide, IdentiryServer4<\/code> g\u00e9n\u00e8re un token d'acc\u00e8s<\/code> (access token) pour l'application et un jeton de renouvellement facultatif (refresh-token<\/code>). Le processus d'autorisation est termin\u00e9. Si la demande est invalide ou non autoris\u00e9e, le serveur d'autorisation renvoie un code avec un message d'erreur appropri\u00e9.<\/p>\n

    \n<\/li>\n

  5. \n

    L'application cliente demande des donn\u00e9es \u00e0 l'API Web prot\u00e9g\u00e9e, en fournissant le token d'acc\u00e8s pour l'autorisation. Si le code de r\u00e9ponse du serveur de ressources 401<\/a><\/noindex>, 403<\/a><\/noindex> ou 498<\/a><\/noindex>, alors le token d'acc\u00e8s utilis\u00e9 pour l'authentification est invalide ou expir\u00e9.<\/p>\n

    \n<\/li>\n

  6. \n

    Si le token est valide, Web API<\/code> il fournit les donn\u00e9es \u00e0 l'application.<\/p>\n

    \n<\/li>\n<\/ol>\n

    <\/p>\n

    Types de tokens<\/em><\/h4>\n

    <\/p>\n

    Aux clients enregistr\u00e9s il est permis de demander IdentityServer4<\/code> un identity-token, IdentityServer4<\/code> identity<\/code>-token, un access<\/code>-token et un refresh<\/code>-token.<\/p>\n

    <\/p>\n