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

Tym postem chc\u0119 otworzy\u0107 seri\u0119 artyku\u0142\u00f3w po\u015bwi\u0119conych IdentityServer4. Zacznijmy od podstawowych poj\u0119\u0107.<\/p>\n

<\/p>\n

Najbardziej obiecuj\u0105cym obecnie protoko\u0142em uwierzytelniania jest OpenID Connect<\/a><\/noindex>, a protoko\u0142em autoryzacji (przyznawania dost\u0119pu) jest OAuth 2.0<\/a><\/noindex>. IdentityServer4<\/a><\/noindex> realizuje te dwa protoko\u0142y. Jest zoptymalizowany do rozwi\u0105zywania typowych problem\u00f3w.<\/strong> bezpiecze\u0144stwa.<\/p>\n

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

OpenID Connect<\/a><\/noindex> \u2014 to protok\u00f3\u0142 i standard uwierzytelniania, nie przyznaje dost\u0119pu do zasob\u00f3w (Web API), ale poniewa\u017c zosta\u0142 opracowany na bazie protoko\u0142u autoryzacji OAuth 2.0<\/a><\/noindex>, umo\u017cliwia uzyskanie parametr\u00f3w profilu u\u017cytkownika, tak jakby uzyskano dost\u0119p do zasobu. UserInfo<\/a><\/noindex>.<\/p>\n

JWT<\/a><\/noindex> (JSON Web Token) to standard internetowy, kt\u00f3ry okre\u015bla spos\u00f3b przesy\u0142ania danych o u\u017cytkowniku w formacie JSON w zaszyfrowanej formie.<\/p>\n

OAuth 2.0 (RFC 6749)<\/a><\/noindex> \u2014 to protok\u00f3\u0142 i standard autoryzacji. Umo\u017cliwia aplikacjom dost\u0119p do chronionych zasob\u00f3w, takich jak Web API.<\/p><\/blockquote>\n

Przyjrzyjmy si\u0119 diagramowi dost\u0119pu do chronionego zasobu i rozgry\u017amy podstawowe kroki oraz przyj\u0119t\u0105 terminologi\u0119:<\/p>\n

<\/p>\n

\"IdentityServer4.<\/p>\n

<\/p>\n

    \n
  1. \n

    Klient prosi u\u017cytkownika o zezwolenie na przeprowadzenie autoryzacji w jego imieniu. Klient<\/strong> \u2014 to aplikacja kliencka, kt\u00f3ra zwraca si\u0119 do chronionych zasob\u00f3w w imieniu w\u0142a\u015bciciela zasob\u00f3w. Zas\u00f3b<\/strong> \u2014 to wszystkie nasze chronione us\u0142ugi. Web API<\/a><\/noindex>.<\/p>\n

    \n<\/li>\n

  2. \n

    U\u017cytkownik zezwala aplikacji klienckiej na przeprowadzenie autoryzacji w swoim imieniu, na przyk\u0142ad wprowadzaj\u0105c login i has\u0142o. Login i has\u0142o b\u0119d\u0105 stanowi\u0107 grant autoryzacji dla aplikacji klienckiej. U\u017cytkownik (w\u0142a\u015bciciel zasobu)<\/strong> \u2014 program lub osoba, kt\u00f3ra mo\u017ce przyzna\u0107 dost\u0119p do chronionych zasob\u00f3w, na przyk\u0142ad poprzez wprowadzenie loginu (username) i has\u0142a (password);<\/p>\n

    \n<\/li>\n

  3. \n

    Aplikacja kliencka \u017c\u0105da tokenu dost\u0119pu u IdentityServer4<\/code> poprzez dostarczenie informacji o sobie (client_id<\/code>, client_secret<\/code>), dostarczenie zezwolenia na autoryzacj\u0119 od u\u017cytkownika (nazwa u\u017cytkownika<\/code>, has\u0142o<\/code>) oraz dostarczenie grant_type<\/code> i scope<\/code>. Nast\u0119pnie serwer autoryzacji weryfikuje to\u017csamo\u015b\u0107 klienta oraz dane w\u0142a\u015bciciela zasobu (login i has\u0142o). <\/p>\n

    <\/p>\n

    Protok\u00f3\u0142 OAuth 2.0 przeprowadza uwierzytelnienie nie tylko u\u017cytkownika, ale tak\u017ce aplikacji klienckiej, kt\u00f3ra uzyskuje dost\u0119p do zasob\u00f3w. W tym celu protok\u00f3\u0142 przewiduje takie parametry jak client_id<\/strong> i client_secret<\/strong>.
    \nclient_id<\/strong> \u2014 to identyfikator aplikacji klienckiej, u\u017cywany IdentityServer4<\/code> do wyszukiwania informacji o kliencie.
    \nclient_secret<\/strong> jest odpowiednikiem has\u0142a dla aplikacji klienckiej i s\u0142u\u017cy do autoryzacji aplikacji klienckiej. IdentityServer4<\/code>. Sekret klienta powinien by\u0107 znany tylko aplikacji i API<\/strong>. Na podstawie powy\u017cszego dochodzimy do wniosku, \u017ce IdentityServer4 musi zna\u0107 swoich klient\u00f3w<\/strong>.<\/p><\/blockquote>\n

    \n<\/li>\n

  4. \n

    Je\u015bli autentyczno\u015b\u0107 aplikacji jest potwierdzona, a uprawnienie do autoryzacji jest wa\u017cne, IdentiryServer4<\/code> tworzy token dost\u0119pu<\/code> (token dost\u0119pu) dla aplikacji i opcjonalny token od\u015bwie\u017cania (token od\u015bwie\u017cania<\/code>). Proces autoryzacji zako\u0144czony. Je\u015bli \u017c\u0105danie jest nieprawid\u0142owe lub nieautoryzowane, serwer autoryzacji zwraca kod z odpowiednim komunikatem o b\u0142\u0119dzie.<\/p>\n

    \n<\/li>\n

  5. \n

    Aplikacja kliencka zwraca si\u0119 o dane do chronionego Web API, dostarczaj\u0105c token dost\u0119pu do autoryzacji. Je\u015bli kod odpowiedzi serwera zasob\u00f3w 401<\/a><\/noindex>, 403<\/a><\/noindex> lub 498<\/a><\/noindex>, to token dost\u0119pu u\u017cywany do uwierzytelniania jest niewa\u017cny lub wygas\u0142.<\/p>\n

    \n<\/li>\n

  6. \n

    Je\u015bli token jest wa\u017cny, Web API<\/code> dane s\u0105 udost\u0119pniane aplikacji.<\/p>\n

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

    <\/p>\n

    Typy token\u00f3w<\/em><\/h4>\n

    <\/p>\n

    Zarejestrowanym w IdentityServer4<\/code> klientom zezwala si\u0119 na \u017c\u0105danie IdentityServer4<\/code> identity<\/code>-tokenu, access<\/code>-tokenu i Od\u015bwie\u017c obrazy<\/code>-tokenu.<\/p>\n

    <\/p>\n