Tym postem chcę otworzyć wątek artykułów poświęconych IdentityServer4. Zaczniemy od podstawowych pojęć.
Najbardziej obiecującym protokołem uwierzytelniania w tej chwili jest i protokół autoryzacji (zapewniający dostęp) to . implementuje te dwa protokoły. Jest zoptymalizowany do rozwiązania typowe problemy bezpieczeństwo.
— jest protokołem i standardem uwierzytelniania, nie zapewnia dostępu do zasobów (internetowego interfejsu API), ale ponieważ jest rozwijany na bazie protokołu autoryzacji , pozwala na uzyskanie parametrów profilu użytkownika tak, jakbyś miał dostęp do zasobu .
(JSON Web Token) to standard internetowy definiujący sposób przesyłania danych użytkownika w zaszyfrowanym formacie JSON.
— jest protokołem autoryzacji i standardem. Umożliwia aplikacjom dostęp do chronionych zasobów, takich jak interfejsy API sieci Web.
Przyjrzyjmy się schematowi dostępu do chronionego zasobu i poznajmy główne kroki oraz przyjętą terminologię:
Klient prosi użytkownika o pozwolenie na zalogowanie się w jego imieniu. Klient — jest aplikacją kliencką, która uzyskuje dostęp do chronionych zasobów w imieniu właściciela zasobu. zasób — oto wszystkie nasze bezpieczne usługi .
Użytkownik zezwala aplikacji klienckiej na autoryzację w jego imieniu, na przykład poprzez wprowadzenie loginu i hasła. Login i hasło będą stanowić przyznanie autoryzacji dla aplikacji klienckiej. Użytkownik (właściciel zasobu) — program lub osoba mogąca udzielić dostępu do zasobów chronionych, np. poprzez podanie loginu (nazwy użytkownika) i hasła (password);
Aplikacja kliencka żąda od użytkownika tokena dostępu
IdentityServer4podając informacje o sobie (client_id,client_secret), udzielając użytkownikowi zezwolenia na autoryzację (username,password) i zaopatrzeniegrant_typeиscopeNastępnie serwer autoryzacyjny weryfikuje autentyczność klienta i dane właściciela zasobu (login i hasło).Protokół OAuth 2.0 uwierzytelnia nie tylko użytkownika, ale także aplikację kliencką uzyskującą dostęp do zasobów. W tym celu protokół dostarcza takie parametry, jak: ID_klienta и klient_sekret.
identyfikator_klienta — jest używanym identyfikatorem aplikacji klienckiejIdentityServer4aby wyszukać informacje o kliencie.
klient_sekret jest odpowiednikiem hasła dla aplikacji klienckiej i służy do uwierzytelniania aplikacji klienckiej naIdentityServer4. Tajemnica klienta powinna być znana wyłącznie aplikacji i API.Na podstawie powyższego wnioskujemy, że IdentityServer4 musi wiedzieć o swoich klientach.Jeżeli aplikacja jest uwierzytelniona i uprawnienie autoryzacyjne jest ważne,
IdentiryServer4tworzyaccess-токен(token dostępu) dla aplikacji i opcjonalny klucz odświeżania (refresh-токен). Proces autoryzacji jest ukończony. Jeśli żądanie jest nieprawidłowe lub nieautoryzowane, serwer autoryzacji zwraca kod z odpowiednim komunikatem o błędzie.Aplikacja kliencka uzyskuje dostęp do chronionego interfejsu API sieci Web w celu uzyskania danych, zapewniając token dostępu do autoryzacji. Jeśli kod odpowiedzi serwera zasobów , lub , oznacza to, że token dostępu użyty do uwierzytelnienia jest nieprawidłowy lub wygasł.
Jeśli token jest ważny,
Web APIdostarcza dane do aplikacji.
Rodzaje tokenów
Zarejestrowany w IdentityServer4 klienci mogą żądać od IdentityServer4 identity-znak, access-żeton i refresh-znak.
- token tożsamości (token identyfikacyjny) — wynik procesu uwierzytelniania. Zawiera identyfikator użytkownika i informacje o tym, jak i kiedy użytkownik się uwierzytelnia. Można rozszerzyć o własne dane.
- token dostępu (token dostępu) — jest przekazywany do chronionego interfejsu API i wykorzystywany przez niego do autoryzacji (umożliwiania dostępu) do jego danych.
- odśwież token — opcjonalny parametr, który serwer autoryzacji może zwrócić w odpowiedzi na żądanie tokena dostępu.
Wprowadźmy jeszcze dwa pojęcia:
Adres URL serwera uwierzytelniania — punkt końcowy do uzyskania klucza dostępu. Wszystkie żądania dotyczące dostarczenia i odnowienia kluczy dostępu będą wysyłane na ten adres URL.
Adres URL zasobu — Adres URL chronionego zasobu, do którego należy uzyskać dostęp, przekazując mu klucz dostępu w nagłówku autoryzacyjnym.
Poproś o klucz dostępu
Aby poprosić o klucz dostępu, klient musi: POST żądanie punktu końcowego IdentityServer4 z następującym tytułem
'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}'username, password, client_id и client_secret zostały omówione powyżej. Przyjrzyjmy się pozostałym parametrom:
typ_dotacji — typ przyznania lub typ uprawnienia autoryzacji. Typ uprawnienia autoryzacji zależy od metody żądania autoryzacji używanej przez aplikację, a także od tego, jakie typy uprawnień są obsługiwane przez API. W naszym przypadku będzie to wartość password, który zgodnie ze specyfikacją OAuth 2.0 odpowiada udzieleniu danych dostępowych właścicielowi zasobu (autoryzacja poprzez login i hasło).
Protokół OAuth 2.0 definiuje następujące rodzaje dotacji wymagających obowiązkowa interakcja z użytkownikami:
- kod autoryzacyjny. Jest to jeden z najczęstszych typów uprawnień autoryzacyjnych, ponieważ dobrze nadaje się do aplikacji po stronie serwera, w których kod źródłowy aplikacji i tajny klucz klienta nie są dostępne dla osób z zewnątrz;
- domniemanyTyp uprawnienia autoryzacji niejawnej jest używany w aplikacjach mobilnych i internetowych, w których nie można zagwarantować poufności tajnych informacji klienta;
I rodzaje dotacji, które można wykonać bez interaktywnej interakcji z użytkownikami:
- szczegóły właściciela zasobu. Ten typ uprawnień powinien być używany tylko wtedy, gdy aplikacja kliencka jest zaufana przez użytkownika i użytkownik czuje się komfortowo, wpisując swój login i hasło. Ten typ uprawnień powinien być używany tylko wtedy, gdy nie ma innych dostępnych opcji. Ten typ uprawnień jest przydatny dla klientów korporacyjnych, którzy już użyli danych uwierzytelniających użytkownika w swoim systemie i chcą przejść na
OAuth 2.0. - Dane uwierzytelniające klienta. Używane, gdy aplikacja uzyskuje dostęp do API. Może to być przydatne, na przykład, gdy aplikacja chce zaktualizować własne informacje rejestracyjne w usłudze lub przekierowanym URI, lub uzyskać dostęp do innych informacji przechowywanych na koncie aplikacji w usłudze za pośrednictwem API usługi.
zakres — jest opcjonalnym parametrem. Definiuje zakres. Token dostępu zwrócony przez serwer zapewni dostęp tylko do tych usług, które są zawarte w tym zakresie. Oznacza to, że możemy połączyć kilka usług w jednym zakresie i jeśli klient otrzyma klucz dostępu do tego zakresu, uzyska dostęp do wszystkich tych usług. Zakres może być również używany do ograniczania uprawnień autoryzacyjnych (na przykład dostępu do odczytu lub zapisu)
Źródło: www.habr.com
