{"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\/ro\/blog\/administrirovanie\/identityserver4-osnovnye-ponyatiya-openid-connect-oauth-2-0-i-jwt","title":{"rendered":"IdentityServer4. No\u021biuni de baz\u0103. OpenID Connect, OAuth 2.0 \u0219i JWT","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Prin aceast\u0103 postare vreau s\u0103 deschid o serie de articole dedicate IdentityServer4. Vom \u00eencepe cu conceptele de baz\u0103.<\/p>\n

<\/p>\n

Cel mai promi\u021b\u0103tor protocol de autentificare \u00een acest moment este OpenID Connect<\/a><\/noindex>, iar protocolul de autorizare (acordarea accesului) este OAuth 2.0<\/a><\/noindex>. IdentityServer4<\/a><\/noindex> implementarea acestor dou\u0103 protocoale. Este optimizat pentru a rezolva problemele tipice<\/strong> de securitate.<\/p>\n

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

OpenID Connect<\/a><\/noindex> \u2014 acesta este un protocol \u0219i standard de autentificare, nu ofer\u0103 acces la resurse (Web API), dar deoarece este dezvoltat deasupra protocolului de autorizare OAuth 2.0<\/a><\/noindex>, permite ob\u021binerea parametrilor profilului utilizatorului ca \u0219i cum a\u021bi primit acces la resurse UserInfo<\/a><\/noindex>.<\/p>\n

JWT<\/a><\/noindex> (JSON Web Token) reprezint\u0103 un standard web care define\u0219te modul de transmitere a datelor despre utilizator \u00eentr-un format JSON \u00eentr-o form\u0103 criptat\u0103.<\/p>\n

OAuth 2.0 (RFC 6749)<\/a><\/noindex> \u2014 acesta este un protocol \u0219i standard de autorizare. Permite aplica\u021biilor s\u0103 ob\u021bin\u0103 acces la resurse protejate, cum ar fi Web API.<\/p><\/blockquote>\n

S\u0103 ne uit\u0103m la diagrama de acces la o resurs\u0103 protejat\u0103 \u0219i s\u0103 analiz\u0103m pa\u0219ii principali \u0219i terminologia acceptat\u0103:<\/p>\n

<\/p>\n

\"IdentityServer4.<\/p>\n

<\/p>\n

    \n
  1. \n

    Clientul solicit\u0103 utilizatorului permisiunea de a trece la autentificare \u00een numele s\u0103u. Clientului<\/strong> \u2014 aceasta este aplica\u021bia client care solicit\u0103 acces la resursele protejate \u00een numele proprietarului resurselor. Resurs\u0103<\/strong> \u2014 acestea sunt toate serviciile noastre protejate Web API<\/a><\/noindex>.<\/p>\n

    \n<\/li>\n

  2. \n

    Utilizatorul permite aplica\u021biei client s\u0103 treac\u0103 la autentificare \u00een numele s\u0103u, de exemplu, introduc\u00e2nd un nume de utilizator \u0219i o parol\u0103. Numele de utilizator \u0219i parola vor constitui un grant de autorizare pentru aplica\u021bia client. Utilizator (proprietarul resursei)<\/strong> \u2014 este un program sau o persoan\u0103 care poate oferi acces la resursele protejate, de exemplu, prin introducerea numelui de utilizator (username) \u0219i a parolei (password);<\/p>\n

    \n<\/li>\n

  3. \n

    Aplica\u021bia client solicit\u0103 un token de acces la IdentityServer4<\/code> prin furnizarea de informa\u021bii despre sine (client_id<\/code>, client_secret<\/code>), acord\u00e2nd permisiunea de autorizare din partea utilizatorului (username<\/code>, parola<\/code>) \u0219i furniz\u00e2nd grant_type<\/code> \u0219i scope<\/code>. Apoi, serverul de autorizare verific\u0103 autenticitatea clientului \u0219i datele proprietarului resursei (numele de utilizator \u0219i parola). <\/p>\n

    <\/p>\n

    Protocolul OAuth 2.0 efectueaz\u0103 autentificarea nu doar a utilizatorului, ci \u0219i a aplica\u021biei client care acceseaz\u0103 resursele. \u00cen acest scop, protocolul prevede parametrii precum client_id<\/strong> \u0219i client_secret<\/strong>.
    \nclient_id<\/strong> \u2014 acesta este identificatorul aplica\u021biei client, folosit IdentityServer4<\/code> pentru a c\u0103uta informa\u021bii despre client.
    \nclient_secret<\/strong> este echivalentul parolei pentru aplica\u021bia client \u0219i este utilizat pentru autentificarea aplica\u021biei client pe IdentityServer4<\/code>. Secretul clientului trebuie s\u0103 fie cunoscut doar aplica\u021biei \u0219i API-ului<\/strong>. Av\u00e2nd \u00een vedere cele de mai sus, concluzion\u0103m c\u0103 IdentityServer4 trebuie s\u0103 fie con\u0219tient de clien\u021bii s\u0103i<\/strong>.<\/p><\/blockquote>\n

    \n<\/li>\n

  4. \n

    Dac\u0103 autenticitatea aplica\u021biei este confirmat\u0103 \u0219i autorizarea este valid\u0103, IdentiryServer4<\/code> creeaz\u0103 access-token<\/code> (token de acces) pentru aplica\u021bie \u0219i o cheie op\u021bional\u0103 de actualizare (refresh-token<\/code>). Procesul de autorizare este finalizat. Dac\u0103 cererea este invalid\u0103 sau neautorizat\u0103, serverul de autorizare returneaz\u0103 un cod cu un mesaj de eroare corespunz\u0103tor.<\/p>\n

    \n<\/li>\n

  5. \n

    Aplica\u021bia client acceseaz\u0103 date de la un Web API protejat, furniz\u00e2nd tokenul de acces pentru autorizare. Dac\u0103 codul r\u0103spunsului serverului de resurse 401<\/a><\/noindex>, 403<\/a><\/noindex> sau 498<\/a><\/noindex>, atunci tokenul de acces folosit pentru autentificare este invalid sau expirat.<\/p>\n

    \n<\/li>\n

  6. \n

    Dac\u0103 tokenul este valid, Web API<\/code> ofer\u0103 date aplica\u021biei.<\/p>\n

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

    <\/p>\n

    Tipuri de tokenuri<\/em><\/h4>\n

    <\/p>\n

    Clien\u021bilor \u00eenregistra\u021bi le este permis s\u0103 solicite IdentityServer4<\/code> -token, IdentityServer4<\/code> identity<\/code>access -token \u0219i<\/code>refresh -token.<\/code>identity-token (token de identitate)<\/p>\n

    <\/p>\n