Udostępnij za pośrednictwem

OAuth 2.0 i OpenID Connect (OIDC) w Platforma tożsamości Microsoft

  • Artykuł

Znajomość protokołu OAuth lub OpenID Connect (OIDC) na poziomie protokołu nie jest wymagana do korzystania z Platforma tożsamości Microsoft. Jednak podczas używania platformy tożsamości do dodawania uwierzytelniania do aplikacji napotkasz terminy i pojęcia dotyczące protokołu. Podczas pracy z centrum administracyjnym firmy Microsoft Entra nasza dokumentacja i biblioteki uwierzytelniania, wiedza na temat niektórych podstaw może pomóc w integracji i ogólnym doświadczeniu.

Role w usłudze OAuth 2.0

Cztery strony są zwykle zaangażowane w uwierzytelnianie OAuth 2.0 i wymianę uwierzytelniania i autoryzacji OpenID Connect. Te wymiany są często nazywane przepływami uwierzytelniania lub przepływami uwierzytelniania.

Diagram przedstawiający role OAuth 2.0

  • Serwer autoryzacji — Platforma tożsamości Microsoft jest serwerem autoryzacji. Nazywany również dostawcą tożsamości lub dostawcą tożsamości, bezpiecznie obsługuje informacje użytkownika końcowego, ich dostęp i relacje zaufania między stronami w przepływie uwierzytelniania. Serwer autoryzacji wystawia tokeny zabezpieczające używane przez aplikacje i interfejsy API do udzielania, odmowy lub odwołwania dostępu do zasobów (autoryzacji) po zalogowaniu użytkownika (uwierzytelnieniu).

  • Klient — klient w ramach wymiany OAuth jest aplikacją żądającą dostępu do chronionego zasobu. Klientem może być aplikacja internetowa działająca na serwerze, jednostronicowa aplikacja internetowa uruchomiona w przeglądarce internetowej użytkownika lub internetowy interfejs API, który wywołuje inny internetowy interfejs API. Często klient jest określany jako aplikacja kliencka, aplikacja lub aplikacja.

  • Właściciel zasobu — właściciel zasobu w przepływie uwierzytelniania jest zazwyczaj użytkownikiem aplikacji lub użytkownikiem końcowym w terminologii OAuth. Użytkownik końcowy "jest właścicielem" chronionego zasobu (ich danych), do którego aplikacja uzyskuje dostęp w ich imieniu. Właściciele zasobów mogą udzielać aplikacji (klientowi) dostępu do zasobów, których są właścicielami, lub odmawiać dostępu do nich. Na przykład aplikacja może wywołać interfejs API systemu zewnętrznego, aby uzyskać adres e-mail użytkownika z profilu w tym systemie. Ich dane profilowe to zasób, który użytkownik końcowy jest właścicielem systemu zewnętrznego, a użytkownik końcowy może wyrazić zgodę na żądanie lub odmówić aplikacji dostępu do swoich danych.

  • Serwer zasobów — hosty serwera zasobów lub zapewniają dostęp do danych właściciela zasobu. Najczęściej serwer zasobów jest internetowym interfejsem API frontingu magazynu danych. Serwer zasobów opiera się na serwerze autoryzacji do przeprowadzania uwierzytelniania i używa informacji w tokenach elementu nośnego wystawionych przez serwer autoryzacji w celu udzielenia lub odmowy dostępu do zasobów.

Tokeny

Strony w przepływie uwierzytelniania używają tokenów elementu nośnego w celu zapewnienia, zweryfikowania i uwierzytelnienia podmiotu zabezpieczeń (użytkownika, hosta lub usługi) oraz udzielenia lub odmowy dostępu do chronionych zasobów (autoryzacja). Tokeny elementu nośnego w Platforma tożsamości Microsoft są formatowane jako tokeny sieci Web JSON (JWT).

Trzy typy tokenów elementu nośnego są używane przez platformę tożsamości jako tokeny zabezpieczające:

  • Tokeny dostępu — tokeny dostępu są wystawiane przez serwer autoryzacji do aplikacji klienckiej. Klient przekazuje tokeny dostępu do serwera zasobów. Tokeny dostępu zawierają uprawnienia przyznane przez klienta przez serwer autoryzacji.

  • Tokeny identyfikatorów — tokeny identyfikatorów są wystawiane przez serwer autoryzacji do aplikacji klienckiej. Klienci używają tokenów identyfikatorów podczas logowania użytkowników i uzyskiwania podstawowych informacji o nich.

  • Tokeny odświeżania — klient używa tokenu odświeżania lub RT do żądania nowych tokenów dostępu i identyfikatorów z serwera autoryzacji. Kod powinien traktować tokeny odświeżania i ich zawartość ciągu jako poufne dane, ponieważ są one przeznaczone tylko do użytku przez serwer autoryzacji.

Rejestracja aplikacji

Aplikacja kliencka wymaga sposobu zaufania tokenom zabezpieczającym wystawionym przez Platforma tożsamości Microsoft. Pierwszym krokiem w ustanowieniu zaufania jest zarejestrowanie aplikacji. Podczas rejestrowania aplikacji platforma tożsamości automatycznie przypisuje mu niektóre wartości, podczas gdy inne są konfigurowane na podstawie typu aplikacji.

Dwa z najczęściej używanych ustawień rejestracji aplikacji to:

  • Identyfikator aplikacji (klienta) — nazywany również identyfikatorem aplikacji i identyfikatorem klienta, ta wartość jest przypisywana do aplikacji przez platformę tożsamości. Identyfikator klienta jednoznacznie identyfikuje aplikację na platformie tożsamości i jest uwzględniony w tokenach zabezpieczających, które występują podczas problemów z platformą.
  • Identyfikator URI przekierowania — serwer autoryzacji używa identyfikatora URI przekierowania w celu przekierowania agenta użytkownika właściciela zasobu (przeglądarki internetowej, aplikacji mobilnej) do innego miejsca docelowego po zakończeniu interakcji. Na przykład po uwierzytelnieniu użytkownika końcowego na serwerze autoryzacji. Nie wszystkie typy klientów używają identyfikatorów URI przekierowania.

Rejestracja aplikacji zawiera również informacje o punktach końcowych uwierzytelniania i autoryzacji, których użyjesz w kodzie, aby uzyskać identyfikator i tokeny dostępu.

Punkty końcowe

Platforma tożsamości Microsoft oferuje usługi uwierzytelniania i autoryzacji przy użyciu zgodnych ze standardami implementacji protokołu OAuth 2.0 i OpenID Connect (OIDC) 1.0. Serwery autoryzacji zgodne ze standardami, takie jak platforma tożsamości, zapewniają zestaw punktów końcowych HTTP do użycia przez strony w przepływie uwierzytelniania w celu wykonania przepływu.

Identyfikatory URI punktu końcowego aplikacji są generowane automatycznie podczas rejestrowania lub konfigurowania aplikacji. Punkty końcowe używane w kodzie aplikacji zależą od typu aplikacji i tożsamości (typów kont), które powinny być obsługiwane.

Dwa często używane punkty końcowe to punkt końcowy autoryzacji i punkt końcowy tokenu. Oto przykłady authorize punktów końcowych i :token

# Authorization endpoint - used by client to obtain authorization from the resource owner.
https://login.microsoftonline.com/<issuer>/oauth2/v2.0/authorize
# Token endpoint - used by client to exchange an authorization grant or refresh token for an access token.
https://login.microsoftonline.com/<issuer>/oauth2/v2.0/token

# NOTE: These are examples. Endpoint URI format may vary based on application type,
#       sign-in audience, and Azure cloud instance (global or national cloud).

#       The {issuer} value in the path of the request can be used to control who can sign into the application. 
#       The allowed values are **common** for both Microsoft accounts and work or school accounts, 
#       **organizations** for work or school accounts only, **consumers** for Microsoft accounts only, 
#       and **tenant identifiers** such as the tenant ID or domain name.

Aby znaleźć punkty końcowe dla zarejestrowanej aplikacji, w centrum administracyjnym firmy Microsoft Entra przejdź do:

Identity>Applications> Rejestracje aplikacji<> YOUR-APPLICATION>>Endpoints

Następne kroki

Następnie zapoznaj się z przepływami uwierzytelniania OAuth 2.0 używanymi przez każdy typ aplikacji i bibliotekami, których można używać w aplikacjach do ich wykonywania:

Zdecydowanie zalecamy tworzenie własnej biblioteki lub nieprzetworzonych wywołań HTTP w celu wykonywania przepływów uwierzytelniania. Biblioteka uwierzytelniania firmy Microsoft jest bezpieczniejsza i łatwiejsza. Jeśli jednak twój scenariusz uniemożliwia korzystanie z naszych bibliotek lub chcesz dowiedzieć się więcej o implementacji Platforma tożsamości Microsoft, mamy informacje o protokole:

  • Przepływ udzielania kodu autoryzacji — aplikacje jednostronicowe (SPA), aplikacje mobilne, aplikacje natywne (klasyczne)
  • Przepływ poświadczeń klienta — procesy po stronie serwera, skrypty, demony
  • Przepływ on-behalf-of (OBO) — internetowe interfejsy API wywołujące inny internetowy interfejs API w imieniu użytkownika
  • OpenID Connect — logowanie użytkownika, wylogowywanie i logowanie jednokrotne (SSO)