{"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\/et\/blog\/administrirovanie\/identityserver4-osnovnye-ponyatiya-openid-connect-oauth-2-0-i-jwt","title":{"rendered":"IdentityServer4. Peamised m\u00f5isted. OpenID Connect, OAuth 2.0 ja JWT","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Selle postitusega soovin alustada artiklite seeriat, mis on p\u00fchendatud IdentityServer4-le. Alustame peamistest m\u00f5istetest.<\/p>\n

<\/p>\n

Praegu on k\u00f5ige perspektiivikam autentimisprotokoll OpenID Connect<\/a><\/noindex>, autoriseerimise (juurdep\u00e4\u00e4su andmise) protokoll on OAuth 2.0<\/a><\/noindex>. IdentityServer4<\/a><\/noindex> , mis toetab neid kaht protokolli. See on optimeeritud t\u00fc\u00fcpiliste probleemide lahendamiseks turvalisuse.<\/strong> \u2014 see on autentimisprotokoll ja standard, mis ei anna juurdep\u00e4\u00e4su ressurssidele (Web API), kuid kuna see on v\u00e4lja t\u00f6\u00f6tatud autoriseerimisprotokolli pinnal<\/p>\n

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

OpenID Connect<\/a><\/noindex> , v\u00f5imaldab see saada kasutaja profiili parameetreid, justkui oleksite saanud juurdep\u00e4\u00e4su ressursile OAuth 2.0<\/a><\/noindex>UserInfo (JSON Web Token) on veebistandard, mis m\u00e4\u00e4ratleb viisi kasutajaandmete edastamiseks JSON-formaadis kr\u00fcpteeritud kujul.<\/a><\/noindex>.<\/p>\n

JWT<\/a><\/noindex> OAuth 2.0 (RFC 6749)<\/p>\n

\u2014 see on autoriseerimisprotokoll ja standard. See v\u00f5imaldab rakendustel p\u00e4\u00e4seda juurde kaitstud ressurssidele, n\u00e4iteks Web API-le.<\/a><\/noindex> Vaadakem, kuidas kaitstud ressursse kutsuda, ja selgitage peamisi samme ja aktsepteeritud terminoloogiat:<\/p><\/blockquote>\n

Kliendi rakendus palub kasutajalt luba autoriseerimise l\u00e4biviimiseks tema nimel.<\/p>\n

<\/p>\n

\"IdentityServer4.<\/p>\n

<\/p>\n

    \n
  1. \n

    \u2014 see on kliendirakendus, mis p\u00f6\u00f6rdub kaitstud ressursside poole omaniku nimel. Kliendi<\/strong> \u2014 need on k\u00f5ik meie kaitstud teenused Allikas<\/strong> Kasutaja lubab kliendirakendusel autoriseerimise l\u00e4bi viia tema nimel, n\u00e4iteks sisestades sisselogimise ja parooli. Sisselogimine ja parool on autoriseerimis\u00f5iguse andmise t\u00f5end kliendirakendusele. Veebi API<\/a><\/noindex>.<\/p>\n

    \n<\/li>\n

  2. \n

    Kasutaja (ressursi omanik) \u2014 programm v\u00f5i inimene, kes v\u00f5ib anda juurdep\u00e4\u00e4su kaitstud ressurssidele, n\u00e4iteks sisselogimise (username) ja parooli (password) sisestamise teel;<\/strong> Kliendirakendus k\u00fcsib juurdep\u00e4\u00e4su m\u00e4rki<\/p>\n

    \n<\/li>\n

  3. \n

    esitamata enda kohta teavet ( IdentityServer4<\/code> client_secretclient_id<\/code>, ), kasutades kasutaja autoriseerimisluba (<\/code>) ja esitadesusername<\/code>, parool<\/code>grant_type . Seej\u00e4rel kontrollib autoriseerimiserver kliendi ja ressursi omanikku (sisselogimine ja parool) autentimist.<\/code> ja scope<\/code>OAuth 2.0 protokoll t\u00f5endab mitte ainult kasutaja, vaid ka kliendirakenduse, mis p\u00e4\u00e4seb ressurssidele. Selleks on protokollis ette n\u00e4htud sellised parameetrid nagu <\/p>\n

    <\/p>\n

    client_id client_id<\/strong> ja ), kasutades kasutaja autoriseerimisluba (<\/strong>.
    \n\u2014 see on kliendirakenduse identifikaator, mida kasutatakse<\/strong> kliendi teabe otsimiseks. IdentityServer4<\/code> on kliendirakenduse parooli analoog ja seda kasutatakse kliendirakenduse autentimiseks.
    \n), kasutades kasutaja autoriseerimisluba (<\/strong> \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0430\u043d\u0430\u043b\u043e\u0433\u043e\u043c \u043f\u0430\u0440\u043e\u043b\u044f \u0434\u043b\u044f \u043a\u043b\u0438\u0435\u043d\u0442\u0441\u043a\u043e\u0433\u043e \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u0438 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442\u0441\u044f \u0434\u043b\u044f \u0430\u0443\u0442\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438 \u043a\u043b\u0438\u0435\u043d\u0442\u0441\u043a\u043e\u0433\u043e \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u043d\u0430 IdentityServer4<\/code>. Kliendi saladus peab olema teada ainult rakendusele ja API-le<\/strong>. \u00dclaltoodust l\u00e4htudes j\u00e4reldame, et IdentityServer4 peab teadma oma kliente<\/strong>.<\/p><\/blockquote>\n

    \n<\/li>\n

  4. \n

    Kui rakenduse ehtsust on kinnitatud ja autoriseerimise luba on kehtiv, IdentiryServer4<\/code> loob access-token'i<\/code> (ligip\u00e4\u00e4sutoken) rakenduse jaoks ja valikulise v\u00e4rskendust\u00f5e (refresh-token<\/code>). Autoriseerimisprotsess on l\u00f5petatud. Kui p\u00e4ring on kehtetu v\u00f5i volitamata, tagastab autoriseerimiserver vastuse koos vastava veateatega.<\/p>\n

    \n<\/li>\n

  5. \n

    Kliendirakendus k\u00fcsib andmeid kaitstud Web API-lt, esitades samas ligip\u00e4\u00e4sutokeni autoriseerimiseks. Kui serveri ressursside vastuskood 401<\/a><\/noindex>, 403<\/a><\/noindex> v\u00f5i 498<\/a><\/noindex>, siis on autoriseerimiseks kasutatud ligip\u00e4\u00e4sutoken kehtetu v\u00f5i aegunud.<\/p>\n

    \n<\/li>\n

  6. \n

    Kui token on kehtiv, Veebi API<\/code> tagastab andmed rakendusele.<\/p>\n

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

    <\/p>\n

    Tokenite t\u00fc\u00fcbid<\/em><\/h4>\n

    <\/p>\n

    Registritud IdentityServer4<\/code> klientidele lubatakse k\u00fcsida IdentityServer4<\/code> identity<\/code>-tokenit, access<\/code>-tokenit ja v\u00e4rskenda<\/code>-tokenit.<\/p>\n

    <\/p>\n