{"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. P\u00f5him\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 p\u00f5him\u00f5istetest.<\/p>\n

<\/p>\n

Praegu on k\u00f5ige lootustandvam autentimise protokoll OpenID Connect<\/a><\/noindex>, samas kui volituste (juurdep\u00e4\u00e4su) protokoll on OAuth 2.0<\/a><\/noindex>. IdentityServer4<\/a><\/noindex> rakendab neid kahte protokolli. See on optimeeritud lahendama t\u00fc\u00fcpilisi probleeme<\/strong> turvalisuse.<\/p>\n

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

OpenID Connect<\/a><\/noindex> \u2014 see on autentimise protokoll ja standard, mis ei anna juurdep\u00e4\u00e4su ressurssidele (Web API), kuid kuna see on v\u00e4lja t\u00f6\u00f6tatud volituste protokolli peale, OAuth 2.0<\/a><\/noindex>kuid see v\u00f5imaldab saada kasutaja profiiliv\u00e4\u00e4rtusi just nagu oleksite saanud juurdep\u00e4\u00e4su ressurssidele UserInfo<\/a><\/noindex>.<\/p>\n

JWT<\/a><\/noindex> (JSON Web Token) on veebistandard, mis m\u00e4\u00e4ratleb viisi, kuidas edastada kasutajaandmeid JSON-formaadis kr\u00fcpteeritud kujul.<\/p>\n

OAuth 2.0 (RFC 6749)<\/a><\/noindex> \u2014 see on volituste protokoll ja standard. See v\u00f5imaldab rakendustel p\u00e4\u00e4seda ligi kaitstud ressurssidele, n\u00e4iteks Web API-le.<\/p><\/blockquote>\n

Vaadakem diagrammi kaitstud ressursi juurde p\u00e4\u00e4semisest ja uurime p\u00f5hietappe ja kasutatavat terminoloogiat:<\/p>\n

<\/p>\n

\"IdentityServer4.<\/p>\n

<\/p>\n

    \n
  1. \n

    Kliendi n\u00f5uab kasutajalt luba autoriseerimiseks tema nimel. Klient<\/strong> \u2014 on kliendi rakendus, mis p\u00f6\u00f6rdub turvalistele ressurssidele nende omaniku nimel. Ressurss<\/strong> \u2014 need on k\u00f5ik meie kaitstud teenused Web API<\/a><\/noindex>.<\/p>\n

    \n<\/li>\n

  2. \n

    Kasutaja lubab kliendi rakendusel autoriseerida end tema nimel, n\u00e4iteks sisestades kasutajanime ja parooli. Need, kasutajanimi ja parool, toimivad kliendi rakenduse autoriseerimise volitusena. Kasutaja (ressursi omanik)<\/strong> \u2014 programm v\u00f5i inimene, kes saab anda juurdep\u00e4\u00e4su kaitstud ressurssidele, n\u00e4iteks kasutajanime (username) ja parooli (password) sisestamise kaudu;<\/p>\n

    \n<\/li>\n

  3. \n

    Kliendi rakendus k\u00fcsib juurdep\u00e4\u00e4sut\u00fckki IdentityServer4<\/code> enne, kui esitavad teavet enda kohta (client_id<\/code>, client_secret<\/code>), andes kasutaja autoriseerimiseks loa (username<\/code>, password<\/code>) ning esitades grant_type<\/code> ja scope<\/code>. Seej\u00e4rel kontrollib autoriseerimiserver kliendi ja ressursi omaniku (kasutajanime ja parooli) autentimise. <\/p>\n

    <\/p>\n

    OAuth 2.0 protokoll autentib mitte ainult kasutajat, vaid ka kliendi rakendust, mis p\u00e4\u00e4seb ressurssidele juurde. Selleks sisaldab protokoll selliseid parameetreid nagu client_id<\/strong> ja client_secret<\/strong>.
    \nclient_id<\/strong> \u2014 see on kliendi rakenduse identifikaator, mida kasutatakse IdentityServer4<\/code> kliendi teabe otsimiseks.
    \nclient_secret<\/strong> on simuleerib kliendi rakenduse parooli ja seda kasutatakse kliendi rakenduse autentimiseks IdentityServer4<\/code>. Kliendi saladus peaks olema tuntud ainult rakendusele ja API-le<\/strong>. Seega j\u00e4reldame, et IdentityServer4 peab teadma oma kliente<\/strong>.<\/p><\/blockquote>\n

    \n<\/li>\n

  4. \n

    Kui rakenduse autentsus on kinnitatud ja autoriseerimise luba on kehtiv, IdentityServer4<\/code> loomise access-tokeni<\/code> (juurdep\u00e4\u00e4sutoken) rakenduse jaoks ja valikulise v\u00e4rskenduse v\u00f5tme (refresh-token<\/code>). Autoriseerimisprotsess on l\u00f5petatud. Kui p\u00e4ring on eba\u00f5iglane v\u00f5i volitamata, tagastab autoriseerimisteenuse server vastava veakoodi.<\/p>\n

    \n<\/li>\n

  5. \n

    Kliendi rakendus v\u00f5tab kaitstud veeb API-lt andmeid, esitades samal ajal juurdep\u00e4\u00e4sutokeni autoriseerimiseks. Kui serveri ressursi vastuse kood 401<\/a><\/noindex>, 403<\/a><\/noindex> v\u00f5i 498<\/a><\/noindex>, siis on autentimiseks kasutatav juurdep\u00e4\u00e4sutoken kehtetu v\u00f5i aegunud.<\/p>\n

    \n<\/li>\n

  6. \n

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

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

    <\/p>\n

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

    <\/p>\n

    registreeritud IdentityServer4<\/code> klientidele on lubatud k\u00fcsida IdentityServer4<\/code> identity<\/code>-token, access<\/code>-token ja refresh<\/code>-token.<\/p>\n

    <\/p>\n