Omówienie tokenów i oświadczeń

  • Artykuł

Scentralizowany dostawca tożsamości jest szczególnie przydatny w przypadku aplikacji, które mają użytkowników na całym świecie, którzy niekoniecznie logują się z sieci przedsiębiorstwa. Platforma tożsamości Microsoft uwierzytelnia użytkowników i udostępnia tokeny zabezpieczające, takie jak tokeny dostępu, tokeny odświeżania i tokeny identyfikatorów. Tokeny zabezpieczające umożliwiają aplikacji klienckiej dostęp do chronionych zasobów na serwerze zasobów.

  • Token dostępu — token dostępu to token zabezpieczający wystawiony przez serwer autoryzacji w ramach przepływu OAuth 2.0. Zawiera on informacje o użytkowniku i zasobie, dla którego jest przeznaczony token. Te informacje mogą służyć do uzyskiwania dostępu do internetowych interfejsów API i innych chronionych zasobów. Zasoby weryfikują tokeny dostępu w celu udzielenia dostępu do aplikacji klienckiej. Aby uzyskać więcej informacji, zobacz Access tokens in the Platforma tożsamości Microsoft (Tokeny dostępu w Platforma tożsamości Microsoft).
  • Token odświeżania — ponieważ tokeny dostępu są ważne tylko przez krótki czas, serwery autoryzacji czasami wystawiają token odświeżania w tym samym czasie, w którym wystawiono token dostępu. Aplikacja kliencka może następnie w razie potrzeby wymienić ten token odświeżania dla nowego tokenu dostępu. Aby uzyskać więcej informacji, zobacz Odświeżanie tokenów w Platforma tożsamości Microsoft.
  • Token identyfikatora — tokeny identyfikatorów są wysyłane do aplikacji klienckiej w ramach przepływu Połączenie OpenID. Można je wysyłać razem lub zamiast tokenu dostępu. Tokeny identyfikatorów są używane przez klienta do uwierzytelniania użytkownika. Aby dowiedzieć się więcej o tym, jak Platforma tożsamości Microsoft wystawia tokeny identyfikatorów, zobacz Tokeny identyfikatorów w Platforma tożsamości Microsoft.

Wiele aplikacji dla przedsiębiorstw używa protokołu SAML do uwierzytelniania użytkowników. Aby uzyskać informacje na temat asercji SAML, zobacz Dokumentacja tokenów SAML.

Weryfikowanie tokenów

Jest to aplikacja, dla której wygenerowano token, aplikację internetową zalogowaną użytkownika lub wywoływany internetowy interfejs API w celu zweryfikowania tokenu. Serwer autoryzacji podpisuje token za pomocą klucza prywatnego. Serwer autoryzacji publikuje odpowiedni klucz publiczny. Aby zweryfikować token, aplikacja weryfikuje podpis przy użyciu klucza publicznego serwera autoryzacji, aby sprawdzić, czy podpis został utworzony przy użyciu klucza prywatnego. Aby uzyskać więcej informacji, zapoznaj się z artykułem Zabezpieczanie aplikacji i interfejsów API przez weryfikowanie oświadczeń.

Zalecamy korzystanie z obsługiwanych bibliotek uwierzytelniania firmy Microsoft (MSAL), jeśli jest to możliwe. Spowoduje to zaimplementowanie pozyskiwania, odświeżania i walidacji tokenów. Implementuje również zgodne ze standardami odnajdywanie ustawień dzierżawy i kluczy przy użyciu dobrze znanego dokumentu odnajdywania openID dzierżawy. Biblioteka MSAL obsługuje wiele różnych architektur aplikacji i platform, takich jak .NET, JavaScript, Java, Python, Android i iOS.

Tokeny są ważne tylko przez ograniczony czas, dlatego serwer autoryzacji często udostępnia parę tokenów. Udostępniany jest token dostępu, który uzyskuje dostęp do aplikacji lub chronionego zasobu. Podano token odświeżania, który jest używany do odświeżania tokenu dostępu, gdy token dostępu jest bliski wygaśnięcia.

Tokeny dostępu są przekazywane do internetowego interfejsu API jako token elementu nośnego w nagłówku Authorization . Aplikacja może podać token odświeżania na serwerze autoryzacji. Jeśli dostęp użytkownika do aplikacji nie został odwołany, otrzyma nowy token dostępu i nowy token odświeżania. Gdy serwer autoryzacji odbiera token odświeżania, wystawia inny token dostępu tylko wtedy, gdy użytkownik jest nadal autoryzowany.

Tokeny sieci Web JSON i oświadczenia

Platforma tożsamości Microsoft implementuje tokeny zabezpieczające jako tokeny internetowe JSON (JWTs), które zawierają oświadczenia. Ponieważ JWTs są używane jako tokeny zabezpieczające, ta forma uwierzytelniania jest czasami nazywana uwierzytelnianiem JWT.

Oświadczenie zapewnia asercji dotyczące jednej jednostki, takiej jak aplikacja kliencka lub właściciel zasobu, do innej jednostki, takiej jak serwer zasobów. Oświadczenie może być również określane jako oświadczenie JWT lub oświadczenie tokenu internetowego JSON.

Oświadczenia to pary nazw lub wartości, które przekazują fakty dotyczące podmiotu tokenu. Na przykład oświadczenie może zawierać fakty dotyczące podmiotu zabezpieczeń uwierzytelnionego przez serwer autoryzacji. Oświadczenia obecne w określonym tokenie zależą od wielu elementów, takich jak typ tokenu, typ poświadczeń używany do uwierzytelniania podmiotu i konfiguracja aplikacji.

Aplikacje mogą używać oświadczeń do wykonywania następujących różnych zadań:

  • Sprawdzanie poprawności tokenu
  • Identyfikowanie dzierżawy podmiotu tokenu
  • Wyświetlanie informacji o użytkowniku
  • Określanie autoryzacji podmiotu

Oświadczenie składa się z par klucz-wartość, które zapewniają następujące typy informacji:

  • Serwer tokenu zabezpieczającego, który wygenerował token
  • Data wygenerowania tokenu
  • Temat (taki jak użytkownik, ale nie demony)
  • Odbiorcy, czyli aplikacja, dla której wygenerowano token
  • Aplikacja (klient), która poprosiła o token

Punkty końcowe tokenu i wystawcy

Identyfikator Entra firmy Microsoft obsługuje dwie konfiguracje dzierżawy: konfiguracja pracowników przeznaczona do użytku wewnętrznego i zarządza pracownikami i gośćmi biznesowymi oraz konfiguracja klienta zoptymalizowana pod kątem izolowania klientów i partnerów w ograniczonym katalogu zewnętrznym. Chociaż podstawowa usługa tożsamości jest identyczna dla obu konfiguracji dzierżawy, domeny logowania i urząd wystawiający tokeny dla dzierżaw zewnętrznych różnią się. Dzięki temu aplikacje mogą w razie potrzeby oddzielić przepływy pracy pracowników i identyfikatorów zewnętrznych.

Dzierżawy pracowników firmy Microsoft Entra uwierzytelniają się w login.microsoftonline.com przy użyciu tokenów wystawionych przez sts.windows.net. Tokeny dzierżawy pracowników są zazwyczaj wymienne między dzierżawami i aplikacjami wielodostępnymi, o ile relacje zaufania bazowego zezwalają na tę współdziałanie. Dzierżawy zewnętrzne firmy Microsoft używają dzierżawców w postaci {tenantname}.ciamlogin.com. Aplikacje zarejestrowane w dzierżawach zewnętrznych muszą mieć świadomość tego oddzielenia, aby prawidłowo odbierać i weryfikować tokeny.

Każda dzierżawa firmy Microsoft Entra publikuje dobrze znane metadane zgodne ze standardami. Ten dokument zawiera informacje o nazwie wystawcy, punktach końcowych uwierzytelniania i autoryzacji, obsługiwanych zakresach i oświadczeniach. W przypadku dzierżaw zewnętrznych dokument jest publicznie dostępny pod adresem: https://{tenantname}.ciamlogin.com/{tenantid}/v2.0/.well-known/openid-configuration. Ten punkt końcowy zwraca wartość wystawcy https://{tenantid}.ciamlogin.com/{tenantid}/v2.0.

Przepływy autoryzacji i kody uwierzytelniania

W zależności od sposobu tworzenia klienta może on używać jednego lub kilku przepływów uwierzytelniania obsługiwanych przez Platforma tożsamości Microsoft. Obsługiwane przepływy mogą tworzyć różne tokeny i kody autoryzacji oraz wymagać różnych tokenów, aby działały. Poniższa tabela zawiera omówienie.

Flow Wymaga Token identyfikatora Token dostępu Odświeżanie tokenu Kod autoryzacji
Przepływ kodu autoryzacji x x x x
Niejawny przepływ x x
Przepływ hybrydowego identyfikatora OIDC x x
Odświeżanie realizacji tokenu Odświeżanie tokenu x x x
Przepływ „w imieniu” Token dostępu x x x
Poświadczenia klienta x (tylko aplikacja)

Tokeny wystawione przy użyciu przepływu niejawnego mają ograniczenie długości, ponieważ są przekazywane z powrotem do przeglądarki przy użyciu adresu URL, gdzie response_mode to query lub fragment. Niektóre przeglądarki mają limit rozmiaru adresu URL, który można umieścić na pasku przeglądarki i zakończyć się niepowodzeniem, gdy jest za długi. W związku z tym te tokeny nie mają groups ani wids oświadczeń.

Zobacz też

Następne kroki