Udostępnij za pośrednictwem

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 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 tokeny dostępu w platformie tożsamości Microsoft.
  • Refresh token — ponieważ tokeny dostępu są ważne tylko przez krótki czas, serwery autoryzacji czasami wystawiają równocześnie token odświeżania i token dostępu. Aplikacja kliencka może następnie wymienić ten token odświeżania na nowy token dostępu, kiedy będzie to potrzebne. Aby uzyskać więcej informacji, zobacz Odświeżanie tokenów w Platforma tożsamości Microsoft.
  • Token ID — tokeny ID są wysyłane do aplikacji klienckiej w ramach przepływu OpenID Connect. 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 odwołanie do tokenów SAML.

Weryfikowanie tokenów

To zależy od aplikacji, dla której wygenerowano token, aplikacji internetowej, która zalogowała użytkownika, lub internetowego interfejsu API, do którego się odwołano, aby zweryfikować token. 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. To wdraża pozyskiwanie, odświeżanie i walidację tokenów dla Ciebie. Implementuje również zgodne ze standardami odkrywanie ustawień dzierżawy i kluczy, korzystając z dobrze znanego dokumentu odkrywania OpenID dla 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 przedstawia twierdzenia dotyczące jednego podmiotu, takiego jak aplikacja kliencka lub właściciel zasobu, innemu podmiotowi, takiemu 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żawcy podmiotu tokenu
  • Wyświetlanie informacji o użytkowniku
  • Określ autoryzację podmiotu

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

  • Serwer tokenu zabezpieczającego, który wygenerował token
  • Data wygenerowania tokenu
  • Podmiot (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

Microsoft Entra ID obsługuje dwie konfiguracje dzierżawy: konfigurację dla pracowników przeznaczoną do użytku wewnętrznego, zarządzającą pracownikami i gośćmi biznesowymi, oraz konfigurację dla klientów, zoptymalizowaną 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.

Użytkownicy Microsoft Entra uwierzytelniają się w login.microsoftonline.com za pomocą tokenów wystawionych przez sts.windows.net. Tokeny najemcy zasobów ludzkich są wymienne między najemcami i aplikacjami wielotenantowymi, o ile podstawowe relacje zaufania zezwalają na taką współdziałanie. Zewnętrzni najemcy firmy Microsoft Entra używają punktów końcowych 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 Microsoft Entra publikuje 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ść https://{tenantid}.ciamlogin.com/{tenantid}/v2.0 wystawcy.

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 Identyfikator tokenu Token dostępu Odświeżanie tokenu Kod autoryzacji
Przepływ kodu autoryzacji x x x x
Niejawny przepływ x x
Przepływ hybrydowy OIDC x x
Odświeżanie realizacji tokenu Odświeżanie tokenu x x x
Przepływ w imieniu innych Token dostępu x x x
Poświadczenia klienta x (tylko aplikacja)

Powiązana zawartość