Tym postem chcę otworzyć serię artykułów poświęconych IdentityServer4. Zacznijmy od podstawowych pojęć.
Najbardziej obiecującym obecnie protokołem uwierzytelniania jest , a protokołem autoryzacji (przyznawania dostępu) jest . realizuje te dwa protokoły. Jest zoptymalizowany do rozwiązywania typowych problemów. bezpieczeństwa.
— to protokół i standard uwierzytelniania, nie przyznaje dostępu do zasobów (Web API), ale ponieważ został opracowany na bazie protokołu autoryzacji , umożliwia uzyskanie parametrów profilu użytkownika, tak jakby uzyskano dostęp do zasobu. .
(JSON Web Token) to standard internetowy, który określa sposób przesyłania danych o użytkowniku w formacie JSON w zaszyfrowanej formie.
— to protokół i standard autoryzacji. Umożliwia aplikacjom dostęp do chronionych zasobów, takich jak Web API.
Przyjrzyjmy się diagramowi dostępu do chronionego zasobu i rozgryźmy podstawowe kroki oraz przyjętą terminologię:
Klient prosi użytkownika o zezwolenie na przeprowadzenie autoryzacji w jego imieniu. Klient — to aplikacja kliencka, która zwraca się do chronionych zasobów w imieniu właściciela zasobów. Zasób — to wszystkie nasze chronione usługi. .
Użytkownik zezwala aplikacji klienckiej na przeprowadzenie autoryzacji w swoim imieniu, na przykład wprowadzając login i hasło. Login i hasło będą stanowić grant autoryzacji dla aplikacji klienckiej. Użytkownik (właściciel zasobu) — program lub osoba, która może przyznać dostęp do chronionych zasobów, na przykład poprzez wprowadzenie loginu (username) i hasła (password);
Aplikacja kliencka żąda tokenu dostępu u
IdentityServer4poprzez dostarczenie informacji o sobie (client_id,client_secret), dostarczenie zezwolenia na autoryzację od użytkownika (nazwa użytkownika,hasło) oraz dostarczeniegrant_typeiscope. Następnie serwer autoryzacji weryfikuje tożsamość klienta oraz dane właściciela zasobu (login i hasło).Protokół OAuth 2.0 przeprowadza uwierzytelnienie nie tylko użytkownika, ale także aplikacji klienckiej, która uzyskuje dostęp do zasobów. W tym celu protokół przewiduje takie parametry jak client_id i client_secret.
client_id — to identyfikator aplikacji klienckiej, używanyIdentityServer4do wyszukiwania informacji o kliencie.
client_secret jest odpowiednikiem hasła dla aplikacji klienckiej i służy do autoryzacji aplikacji klienckiej.IdentityServer4. Sekret klienta powinien być znany tylko aplikacji i API. Na podstawie powyższego dochodzimy do wniosku, że IdentityServer4 musi znać swoich klientów.Jeśli autentyczność aplikacji jest potwierdzona, a uprawnienie do autoryzacji jest ważne,
IdentiryServer4tworzytoken dostępu(token dostępu) dla aplikacji i opcjonalny token odświeżania (token odświeżania). Proces autoryzacji zakończony. Jeśli żądanie jest nieprawidłowe lub nieautoryzowane, serwer autoryzacji zwraca kod z odpowiednim komunikatem o błędzie.Aplikacja kliencka zwraca się o dane do chronionego Web API, dostarczając token dostępu do autoryzacji. Jeśli kod odpowiedzi serwera zasobów , lub , to token dostępu używany do uwierzytelniania jest nieważny lub wygasł.
Jeśli token jest ważny,
Web APIdane są udostępniane aplikacji.
Typy tokenów
Zarejestrowanym w IdentityServer4 klientom zezwala się na żądanie IdentityServer4 identity-tokenu, access-tokenu i Odśwież obrazy-tokenu.
- token identyfikacji (identity token) — wynik procesu uwierzytelniania. Zawiera identyfikator użytkownika oraz informacje o tym, w jaki sposób i kiedy użytkownik jest uwierzytelniany. Można rozszerzyć własnymi danymi.
- token dostępu (access token) — jest przekazywany do chronionego API i używany przez nie do autoryzacji (zezwolenia na dostęp) do swoich danych.
- token odświeżania (refresh token) — opcjonalny parametr, który serwer autoryzacji może zwrócić w odpowiedzi na żądanie tokena dostępu.
Wprowadź jeszcze dwa pojęcia:
URL serwera uwierzytelniającego — punkt końcowy do uzyskania tokena dostępu. Wszystkie żądania dotyczące wydawania i przedłużania tokenów dostępu będziemy kierować na ten adres URL.
URL zasobu — adres URL chronionego zasobu, na który należy się zwrócić, aby uzyskać do niego dostęp, przekazując mu token dostępu w nagłówku autoryzacji.
Żądanie tokena dostępu
Aby zażądać tokena dostępu, klient wykonuje POST żądanie do punktu końcowego IdentityServer4 z następującym nagłówkiem
'Content-Type': 'application/x-www-form-urlencoded',
'Accept': 'application/json',
'Expect': '100-continue'i przekazując następujące parametry:
'grant_type' : 'password',
'username' : login,
'password' : password,
'scope' : 'scope',
'client_id' : 'client_id',
'client_secret' : '{client_secret}'nazwa użytkownika, hasło, client_id i client_secret były omawiane powyżej. Przyjrzyjmy się pozostałym parametrom:
grant_type — typ grantów lub typ uprawnienia do autoryzacji. Typ uprawnienia do autoryzacji zależy od metody żądania autoryzacji stosowanej przez aplikację, a także od typów uprawnień obsługiwanych przez API. W naszym przypadku będzie to mieć wartość hasło, zgodnie ze specyfikacją OAuth 2.0 odpowiadającą grantowi poświadczeń dostępu właściciela zasobów (autoryzacja przy użyciu loginu i hasła).
Protokół OAuth 2.0 określa następujące typy grantów, które wymagają obowiązkowej interakcji z użytkownikami:
- kod autoryzacji (authorization code). Jest to jeden z najczęściej stosowanych typów uprawnień do autoryzacji, ponieważ doskonale nadaje się do aplikacji po stronie serwera (server-side applications), gdzie kod źródłowy aplikacji i sekret klienta nie są dostępne dla osób trzecich;
- pośredni (implicit). Typ pośredni uprawnienia do autoryzacji jest wykorzystywany przez aplikacje mobilne i webowe, gdzie poufność sekretu klienta nie może być zagwarantowana;
A typy grantów, które mogą być realizowane bez interaktywnej interakcji z użytkownikami:
- poświadczenia właściciela zasobu (resource owner). Tego typu uprawnienia należy używać tylko w przypadku, gdy aplikacja kliencka cieszy się zaufaniem użytkownika i użytkownik jest na tyle spokojny, by wprowadzić swój login i hasło. Tego typu uprawnienia powinny być stosowane tylko wtedy, gdy inne opcje nie są dostępne. Tego rodzaju uprawnienia są wygodne dla klientów korporacyjnych, którzy w ramach swojego systemu już wykorzystali dane użytkownika i chcą przejść na
OAuth 2.0. - dane klienta. Używane przy dostępie aplikacji do API. Może to być przydatne, na przykład, gdy aplikacja chce zaktualizować swoje dane rejestracyjne w usłudze lub URI przekierowania, lub uzyskać dostęp do innych informacji przechowywanych w koncie aplikacji w usłudze poprzez API usługi.
scope — to jest opcjonalny parametr. Określa zakres widoczności. Token dostępu zwrócony przez serwer zapewni dostęp tylko do tych usług, które mieszczą się w tym zakresie. Innymi słowy, możemy połączyć kilka usług pod jednym zakresem, a jeśli klient otrzyma klucz dostępu do tego zakresu, zyskuje dostęp do wszystkich tych usług. Zakres może być również wykorzystywany do ograniczenia praw autoryzacji (na przykład dostęp do odczytu lub zapisu)
Źródło: habr.com
