Tokeny dostępu do platformy tożsamości firmy Microsoft — Microsoft Enter (2023)

Tokeny dostępu umożliwiają klientom wywoływanie bezpiecznie chronionych internetowych interfejsów API. Interfejsy API sieci Web korzystają z tokenów dostępu do przeprowadzania uwierzytelniania i autoryzacji.

Zgodnie ze specyfikacją OAuth tokeny dostępu to nieprzezroczyste ciągi znaków bez określonego formatu. Niektórzy IDP (dostawcy tożsamości) używają identyfikatorów GUID; inni używają zaszyfrowanych obiektów BLOB. Format tokena dostępu może zależeć od konfiguracji API, które go akceptuje.

Niestandardowe interfejsy API zarejestrowane przez programistów na platformie tożsamości firmy Microsoft mogą wybierać spośród dwóch różnych formatów JWT (tokenów internetowych JSON) zwanychwersja 1.0miwersja 2.0. Interfejsy API opracowane przez firmę Microsoft, takie jak Microsoft Graph lub interfejsy API na platformie Azure, mają inne zastrzeżone formaty tokenów. Te zastrzeżone formaty, których nie można sprawdzić, mogą być zaszyfrowanymi tokenami, tokenami JWT lub specjalnymi formatami podobnymi do JWT.

Treść tokenu jest przeznaczona wyłącznie dla interfejsu API, co oznacza, że ​​tokeny dostępu muszą być traktowane jako nieprzezroczyste ciągi znaków. Do celów sprawdzania poprawności i debugowania,Tylkoprogramiści mogą dekodować JWT za pomocą strony internetowej takiej jakjwt.ms. Tokeny odbierane przez interfejs API firmy Microsoft nie zawsze są tokenami JWT, które można zdekodować.

Klienci powinni skorzystać z danych odpowiedzi tokenu zwróconych wraz z tokenem dostępu, aby uzyskać szczegółowe informacje na temat jego zawartości. Gdy klient żąda tokenu dostępu, platforma tożsamości firmy Microsoft zwraca również pewne metadane dotyczące tokenu dostępu, z których może korzystać aplikacja. Informacje te obejmują datę wygaśnięcia tokena dostępu i zakresy, dla których jest on ważny. Dane te umożliwiają aplikacji inteligentne buforowanie tokenów dostępu bez konieczności analizowania samego tokenu dostępu.

Zapoznaj się z poniższymi sekcjami, aby dowiedzieć się, jak interfejs API może weryfikować i używać oświadczeń w tokenie dostępu.

Formaty tokenów

Na platformie Microsoft Identity Platform dostępne są dwie wersje tokenów dostępu: v1.0 i v2.0. Te wersje określają oświadczenia zawarte w tokenie i zapewniają, że internetowy interfejs API może kontrolować zawartość tokenu.

Interfejsy API sieci Web mają domyślnie wybraną podczas rejestracji jedną z następujących wersji:

• wersja 1.0 dla aplikacji tylko do usługi Azure AD. Poniższy przykład przedstawia token v1.0 (klucze są zmieniane, a dane osobowe usuwane, co uniemożliwia weryfikację tokena):

  eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSIsImtpZCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSJ9.eyJhdWQiOiJlZ jFkYTlkNC1mZjc3LTRjM2UtYTAwNS04NDBjM2Y4MzA3NDUiLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC9mYTE1ZDY5Mi1lowM3LTQ0NjAtYTc0My0yowyyOTUyMjIyOS8iLCJpYXQiOjE1M zcyMzMxMDYsIm5iZiI6MTUzNzIzMzEwNiwiZXhwIjoxNTM3MjM3MDA2LCJhY3IiOiIxIiwiYWlvIjoiQVhRQWkvOElBQUFBRm0rRS9RVEcrZ0ZuVnhMaldkdzhLKzYxQUdyU091TU1GNmV iYU1qN1hPM0libUQzZkdtck95RCtOdlp5R24yVmFUL2tES1h3NE1JaHJnR1ZxNkJuOHdMWG9UMUxrSVorRnpRVmtKUFBMUU9WNEtjWHFTbENWUERTL0RpQ0RnRTIyMlRJbU12V05hRU1hVU9Uc0 lHdlRRPT0iLCJhbXIiOlsid2lhIl0sImFwcGlkIjoiNzVkYmU3N2YtMTBhMy00ZTU5LTg1ZmQtOGMxMjc1NDRmMTdjIiwiYXBwaWRhY3IiOiIwIiwiZW1haWwiOiJBYmVMaUBtaWNyb3NvZnQu Y29tIiwiZmFtaWx5X25hbWUiOiJMaW5jb2xuIiwiZ2l2ZW5fbmFtZSI6IkFiZSAoTVNGVCkiLCJpZHAiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83MmY5ODhiZi04NmYxLTQxYWYtoOTFhYi0 yZDdjZDAxMjIyNDcvIiwiaXBhZGRyIjoiMjIyLjIyMi4yMjIuMjIiLCJuYW1lIjoiYWJlbGkiLCJvaWQiOiIwMjIyM2I2Yi1hYTFkLTQyZDQtOWVjMC0xYjJiYjkxOTQ0MzgiLCJyaCI6Ikki LCJzY3AiOiJ1c2VyX2ltcGVyc29uYXRpb24iLCJzdWIiOiJsM19yb0lTUVUyMjJiVUxTOXlpMmswWHBxcE9pTXo1SDNaQUNvMUdlWEEiLCJ0aWQiOiJmYTE1ZDY5Mi1lowM3LTQ0NjAtYT c0My0yOWYyOTU2ZmQ0MjkiLCJ1bmlxdWVfbmFtZSI6ImFiZWxpQG1pY3Jvc29mdC5jb20iLCJ1dGkiOiJGVnNHeFlySTMwLVR1aWt1dVVvRkFBIiwidmVyIjoiMS4wIn0.D3H6pMUtQnoJAGq6AH d

• v2.0 dla aplikacji obsługujących konta konsumenckie. Poniższy przykład przedstawia token v2.0 (klucze są zmieniane, a dane osobowe usuwane, co uniemożliwia weryfikację tokena):

  See Also

  JWT (JSON Web Tokens): co to jest i jak wykorzystać w praktyce? | Spostrzeżenia, które pomogą Ci w karierze w branży technologicznejCo to jest token certyfikatu cyfrowego? Zrozumieć, do czego to służyToken: co to jest i jaka jest różnica między tokenem a kryptowalutą?Uwierzytelnianie oparte na tokenach w aplikacji REST

  eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSJ9.eyJhdWQiOiI2ZTc0MTcyYi1iZTU2LTQ4NDMtOWZmNC1lNjZhMzliYjEyZTMiLCJpc3MiOiJodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjQ3L3YyLjAiLCJpYXQiOjE1MzcyMzEwNDgsIm5iZiI6MTUzNzIzMTA0OCwiZXhwIjoxNTM3MjM0OTQ4LCJhaW8iOiJBWFFBaS84SUFBQUF0QWFaTG8zQ2hNaWY2S09udHRSQjdlQnE0L0RjY1F6amNKR3hQWXkvQzNqRGFOR3hYZDZ3TklJVkdSZ2hOUm53SjFsT2NBbk5aY2p2a295ckZ4Q3R0djMzMTQwUmlvT0ZKNGJDQ0dWdW9DYWcxdU9UVDIyMjIyZ0h3TFBZUS91Zjc5UVgrMEtJaWpkcm1wNjlSY3R6bVE9PSIsImF6cCI6IjZlNzQxNzJiLWJlNTYtNDg0My05ZmY0LWU2NmEzOWJiMTJlMyIsImF6cGFjciI6IjAiLCJuYW1lIjoiQWJlIExpbmNvbG4iLCJvaWQiOiI2OTAyMjJiZS1mZjFhLTRkNTYtYWJkMS03ZTRmN2QzOGU0NzQiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJhYmVsaUBtaWNyb3NvZnQuY29tIiwicmgiOiJJIiwic2NwIjoiYWNjZXNzX2FzX3VzZXIiLCJzdWIiOiJIS1pwZmFIeVdhZGVPb3VZbGl0anJJLUtmZlRtMjIyWDVyclYzeERxZktRIiwidGlkIjoiNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjQ3IiwidXRpIjoiZnFpQnFYTFBqMGVRYTgyUy1JWUZBQSIsInZlciI6IjIuMCJ9.pj4N-w_3Us9DrBLfpCt

Ustaw wersję aplikacji podając odpowiednią wartość do konfiguracjiaccessTokenAcceptedVersionNIEmanifest aplikacji. Wartościzeromi1wynikiem będą tokeny wersji 1.0 i wartość2skutkuje tokenami v2.0.

Własność tokena

Żądanie tokenu dostępu obejmuje dwie strony: klienta, który żąda tokenu, oraz zasób (Web API), który akceptuje token. Zasób, dla którego przeznaczony jest token (jegodocelowa publiczność) jest zdefiniowany w deklaracjidźwiękw tokenie. Klienci korzystają z tokena, ale nie powinni go rozumieć ani próbować go analizować. Zasoby akceptują token.

Platforma tożsamości firmy Microsoft obsługuje wydawanie dowolnej wersji tokenu z dowolnego punktu końcowego wersji. Na przykład, gdy wartośćaccessTokenAcceptedVersionTo jest2, klient wywołujący punkt końcowy w wersji 1.0 w celu uzyskania tokenu dla tego zasobu otrzymuje token dostępu w wersji 2.0.

Zasoby są zawsze tokenizowane przy użyciu deklaracjidźwięki są jedynymi aplikacjami, które mogą zmieniać szczegóły tokena.

Żywotność tokenu

Domyślny czas życia tokena dostępu jest zmienny. Po wydaniu platforma tożsamości firmy Microsoft przypisuje losową wartość z zakresu od 60 do 90 minut (średnio 75 minut) jako domyślny okres istnienia tokenu dostępu. Zmiana zwiększa odporność usługi, rozkładając zapotrzebowanie na token dostępu w pewnym okresie, co zapobiega godzinnym skokom ruchu do usługi Azure AD.

Dzierżawcy, którzy nie korzystają z dostępu warunkowego, mają domyślny okres istnienia tokenu dostępu wynoszący dwie godziny dla klientów takich jak Microsoft Teams i Microsoft 365.

Dostosuj czas życia tokena dostępu, aby kontrolować, jak często aplikacja kliencka przekracza limit czasu sesji aplikacji i jak często wymaga ponownego uwierzytelnienia użytkownika (cichego lub interaktywnego). Aby zastąpić domyślną zmianę czasu życia tokena dostępu, użyjKonfigurowalny czas życia tokenu (CTL).

Zastosuj domyślny zakres okresu istnienia tokenu do organizacji, które mają włączoną ciągłą ocenę dostępu (CAE). Wymuś domyślną zmianę czasu życia tokena, nawet jeśli organizacje korzystają z zasad CTL. Standardowe okresy istnienia tokenów w przypadku długotrwałych okresów istnienia tokenów wahają się od 20 do 28 godzin. Po wygaśnięciu tokenu dostępu klient musi użyć tokenu odświeżania, aby w trybie cichym uzyskać nowy token odświeżania i token dostępu.

Organizacje korzystające zDostęp warunkowy SIF (częstotliwość wejściowa)w celu wymuszenia częstotliwości wpisów nie można zastąpić domyślnego zakresu czasu życia tokenu dostępu. Gdy organizacje korzystają z protokołu SIF, czas między żądaniami poświadczeń dla klienta to czas życia tokena wynoszący od 60 do 90 minut plus zakres częstotliwości wejściowej.

Oto przykład działania standardowej zmiany czasu życia tokenu przy częstotliwości wejściowej. Załóżmy, że organizacja ustawia częstotliwość przychodzącą co godzinę. Jeśli okres istnienia tokena wynosi od 60 do 90 minut ze względu na jego zmienność, rzeczywisty interwał wprowadzania wynosi od 1 godziny do 2,5 godziny.

Jeśli użytkownik z godzinnym okresem istnienia tokenu zaloguje się interaktywnie po 59 minutach, nie zostanie wyświetlony monit o podanie danych, ponieważ logowanie jest poniżej progu SIF. Jeśli okres ważności nowego tokena wynosi 90 minut, użytkownik nie zobaczy monitu o podanie danych przez kolejne półtorej godziny. Podczas cichej próby odnowienia usługa Microsoft Azure AD wymaga monitu o poświadczenie, ponieważ całkowity czas trwania sesji przekroczył ustawienie częstotliwości logowania wynoszące 1 godzinę. W tym przykładzie różnica czasu między żądaniami poświadczeń wynikająca z interwału SIF i zmiany czasu życia tokenu wyniesie 2,5 godziny.

Zweryfikuj tokeny

Nie wszystkie aplikacje muszą weryfikować tokeny. Tylko w określonych scenariuszach aplikacje powinny weryfikować token:

• Interfejsy API sieci Web muszą weryfikować tokeny dostępu otrzymane od klienta. Jako żądanie powinni akceptować tylko tokeny zawierające jeden z identyfikatorów URI AppIddźwięk.
• Aplikacje internetowe muszą weryfikować tokeny identyfikacyjne otrzymane z przeglądarki użytkownika w przepływie hybrydowym przed zezwoleniem na dostęp do danych użytkownika lub ustanowieniem sesji.

Jeżeli nie ma zastosowania żaden z wcześniej opisanych scenariuszy, nie ma potrzeby walidacji tokena. Klienci publiczni, tacy jak aplikacje natywne, desktopowe lub jednostronicowe, nie korzystają z weryfikacji tokenu identyfikacyjnego, ponieważ aplikacja komunikuje się bezpośrednio z dostawcą tożsamości, gdzie ochrona SSL zapewnia ważność tokenów identyfikacyjnych. Nie powinny sprawdzać tokenów dostępu, ponieważ powinny być sprawdzane przez internetowy interfejs API, a nie klienta.

Interfejsy API i aplikacje internetowe powinny weryfikować tylko tokeny, które mają roszczeniedźwiękpasujący do aplikacji. Inne zasoby mogą mieć niestandardowe reguły sprawdzania poprawności tokenu. Na przykład nie można zweryfikować tokenów dla programu Microsoft Graph zgodnie z tymi regułami ze względu na zastrzeżony format. Przykładem jest sprawdzanie i akceptowanie tokenów przeznaczonych dla innego zasobuzdezorientowany zastępca.

Jeśli Twoja aplikacja musi zweryfikować token identyfikatora lub token dostępu, musi najpierw zweryfikować podpis tokena i wystawcę tokena względem wartości w dokumencie wykrywania OpenID.

Oprogramowanie pośredniczące usługi Azure AD ma wbudowane możliwości sprawdzania tokenów dostępu, zobacz sekcjępróbkiznaleźć taki w odpowiednim języku. Istnieje również kilka bibliotek open source innych firm dostępnych do sprawdzania poprawności JWT. Aby uzyskać więcej informacji na temat bibliotek uwierzytelniania i przykładów kodu usługi Azure AD, zobaczBiblioteki uwierzytelniające. Jeśli Twoja aplikacja internetowa lub internetowy interfejs API znajduje się w ASP.NET lub ASP.NET Core, użyj Microsoft.Identity.Web, który obsługuje weryfikację.

Tokeny v1.0 i v2.0

• Kiedy Twoja aplikacja internetowa/API sprawdza token wersji 1.0 (claimwer="1.0"), musi odczytać dokument metadanych OpenID Connect z punktu końcowego v1.0 (https://login.microsoftonline.com/{example-tenant-id}/.well-known/openid-configuration), nawet jeśli urząd skonfigurowany dla interfejsu API sieci Web to urząd w wersji 2.0.
• Kiedy Twoja aplikacja internetowa/API sprawdza poprawność tokena v2.0 (claimwer="2.0"), musi odczytać dokument metadanych OpenID Connect z punktu końcowego v2.0 (https://login.microsoftonline.com/{example-tenant-id}/v2.0/.well-known/openid-configuration), nawet jeśli urząd skonfigurowany dla interfejsu API sieci Web to urząd w wersji 1.0.

W poniższych przykładach założono, że aplikacja weryfikuje token dostępu w wersji 2.0 (i dlatego odwołuje się do wersji 2.0 dokumentów OIDC i kluczy metadanych). Po prostu usuń „/v2.0” z adresu URL, jeśli sprawdzasz tokeny wersji 1.0.

zatwierdź podpis

JWT zawiera trzy segmenty oddzielone znakiem.. Pierwszy segment tonagłówek, drugie tociałoa trzeci topodpis. Użyj segmentu podpisu, aby ocenić autentyczność tokena.

Usługa Azure AD wystawia tokeny podpisane przy użyciu standardowych algorytmów szyfrowania asymetrycznego, takich jak RS256. Nagłówek JWT zawiera informację o sposobie szyfrowania i kluczu użytym do podpisania tokena:

{ "typ": "JWT", "alg": "RS256", "x5t": "iBjL1Rcqzhiy4fpxIxdZqohM2Yk", "kid": "iBjL1Rcqzhiy4fpxIxdZqohM2Yk"}

Deklaracjaalgwskazuje algorytm użyty do podpisania tokena, natomiast deklaracjadzieckowskazuje konkretny klucz publiczny używany do sprawdzania poprawności tokena.

W dowolnym momencie usługa Azure AD może podpisać token identyfikatora przy użyciu dowolnego zestawu par kluczy publiczno-prywatnych z danej puli. Usługa Azure AD okresowo obraca możliwy zestaw kluczy, dlatego napisz aplikację, aby automatycznie obsługiwała te kluczowe zmiany. Rozsądną częstotliwością sprawdzania aktualizacji kluczy publicznych używanych przez usługę Azure AD jest co 24 godziny.

Zdobądź dane klucza subskrypcji wymagane do sprawdzenia subskrypcji za pomocąDokument metadanych OpenID Connectpołożony w:

https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration

Poniższe informacje opisują dokument metadanych:

• Jest to obiekt JSON zawierający różne przydatne informacje, takie jak lokalizacja różnych punktów końcowych wymaganych do przeprowadzenia uwierzytelnienia OpenID Connect.
• Zawiera:jwks, który zapewnia lokalizację zestawu kluczy publicznych odpowiadających kluczom prywatnym używanym do podpisywania tokenów. JWK (klucz sieciowy JSON) znajdujący się w plikujwkszawiera wszystkie informacje o kluczu publicznym używane w tym konkretnym czasie. ORFC 7517opisuje format JWK. Aplikacja może korzystać z instrukcjidzieckow nagłówku JWT, aby wybrać klucz publiczny w tym dokumencie, który odpowiada kluczowi prywatnemu używanemu do podpisania konkretnego tokena. Dzięki temu może przeprowadzić walidację podpisu przy użyciu prawidłowego klucza publicznego i wskazanego algorytmu.

Przeprowadzanie weryfikacji podpisu wykracza poza zakres tego dokumentu. Dostępnych jest wiele bibliotek open source, które w razie potrzeby pomagają w weryfikacji podpisu. Jednak platforma tożsamości firmy Microsoft ma rozszerzenie podpisywania tokenu do ustawień domyślnych, którymi są niestandardowe klucze podpisywania.

Jeśli aplikacja ma niestandardowe klucze subskrypcji w wyniku użycia tej funkcjimapowanie roszczeń, dodaj parametr zapytaniaaplikacjazawierający identyfikator aplikacji. Aby sprawdzić poprawność, użyjjwksco wskazuje na informacje o kluczu podpisującym aplikację. Na przykład:https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration?appid=6731de76-14a6-49ae-97bc-6eba6914391ezawierajwkszhttps://login.microsoftonline.com/{tenant}/discovery/keys?appid=6731de76-14a6-49ae-97bc-6eba6914391e.

Zweryfikuj wystawcę

Aplikacje internetowe weryfikujące tokeny identyfikacyjne i interfejsy API sieciowe weryfikujące tokeny dostępu muszą zweryfikować wystawcę tokena (deklaracjajest) o:

1. wystawca dostępny w dokumencie metadanych OpenID Connect powiązany z konfiguracją aplikacji (uprawnieniem). Dokument metadanych do weryfikacji zależy od:
   • wersja tokenowa
   • konta obsługiwane przez Twoją aplikację.
2. Identyfikator najemcy (deklaracjaczas) zrób token,
3. wystawca klucza uwierzytelniającego.

Aplikacje dla jednego najemcy

Rdzeń połączenia OpenIDmówi: „Identyfikator emitenta [...] MUSI dokładnie odpowiadać kwocie deklaracjijest(wystawca)”. W przypadku aplikacji korzystających z punktu końcowego metadanych specyficznego dla dzierżawy, takiego jakhttps://login.microsoftonline.com/{example-tenant-id}/v2.0/.well-known/openid-configurationLubhttps://login.microsoftonline.com/contoso.onmicrosoft.com/v2.0/.well-known/openid-configuration.

Aplikacje z jedną dzierżawą to aplikacje, które obsługują:

• Konta w katalogu organizacyjnym (tylkoprzykładowy identyfikator najemcy):https://login.microsoftonline.com/{example-tenant-id}
• Tylko konta osobiste Microsoft:https://login.microsoftonline.com/consumers(konsumencibędący pseudonimem najemcy 9188040d-6c67-4c5b-b112-36a304b66dad)

Aplikacje dla wielu dzierżawców

Usługa Azure AD obsługuje także aplikacje wielodostępne. Te aplikacje są kompatybilne z:

• Konta w dowolnym katalogu organizacyjnym (dowolnym katalogu usługi Azure AD):https://login.microsoftonline.com/organizations
• Konta w dowolnym katalogu organizacyjnym (dowolnym katalogu Azure AD) i osobiste konta Microsoft (np. Skype, Xbox):https://login.microsoftonline.com/common

W przypadku tych aplikacji usługa Azure AD udostępnia niezależne od dzierżawy wersje dokumentu OIDChttps://login.microsoftonline.com/common/v2.0/.well-known/openid-configurationmihttps://login.microsoftonline.com/organizations/v2.0/.well-known/openid-configurationodpowiednio. Te punkty końcowe zwracają wartość emitera, która jest szablonem sparametryzowanym przeznajemca:https://login.microsoftonline.com/{tenantid}/v2.0. Aplikacje mogą używać tych niezależnych od dzierżawców punktów końcowych do sprawdzania poprawności tokenów od każdego dzierżawcy z następującymi zastrzeżeniami:

• Zweryfikuj wystawcę klucza uwierzytelniającego
• Zamiast czekać, aż żądanie wystawcy w tokenie będzie dokładnie odpowiadać wartości wystawcy w metadanych, aplikacja musi zastąpić tę wartość{identyfikator najemcy}w metadanych nadawcy po identyfikatorze najemcy będącego miejscem docelowym bieżącego żądania, a następnie zweryfikuj dokładne dopasowanie (deklaracjaczaszrób token).
• Potwierdź tę deklaracjęczasjest identyfikatorem GUID i jeśli deklaracjajestma formathttps://login.microsoftonline.com/{tid}/v2.0, w którym{czas}to dokładne stwierdzenieczas. Ta weryfikacja łączy dzierżawcę z wystawcą i zakresem klucza podpisującego, tworząc łańcuch zaufania.
• Użyj stwierdzeniaczasgdy zlokalizują dane związane z przedmiotem oświadczenia. Innymi słowy oświadczenieczasmusi być częścią klucza używanego do dostępu do danych użytkownika.

Zweryfikuj wystawcę klucza uwierzytelniającego

Aplikacje korzystające z metadanych w wersji 2.0 niezależnych od dzierżawy muszą zweryfikować wystawcę klucza uwierzytelniania.

Wystawca dokumentu klucza i klucza uwierzytelniającego

Jak omówiono w dokumencie OpenID Connect, Twoja aplikacja uzyskuje dostęp do kluczy używanych do uwierzytelniania tokenów. Uzyskuje odpowiedni kluczowy dokument, uzyskując dostęp do adresu URL ujawnionego we właściwościjwkswykonaj dokument OpenIdConnect.

"jwks_uri": "https://login.microsoftonline.com/{example-tenant-id}/discovery/v2.0/keys",

Wartość{przykładowy identyfikator najemcy}można zastąpić identyfikatorem GUID, nazwą domeny lubwspólny,organizacjemikonsumenci

Dokumenty „kluczowe” udostępniane przez usługę Azure AD w wersji 2.0 zawierają dla każdego klucza wystawcę korzystającego z tego klucza uwierzytelniania. Sprawdź na przykład punkt końcowyhttps://login.microsoftonline.com/common/discovery/v2.0/keys„wspólny” i niezależny od dzierżawcy klucz zwraca dokument taki jak:

{ "keys": [ {"kty":"RSA","use":"sig","kid":"jS1Xo1OWDj_52vbwGNgvQO2VzMc","x5t":"jS1Xo1OWDj_52vbwGNgvQO2VzMc","n":"spv...", „e”: „AQAB”, „x5c”: [„MIID…”], „issuer”: „https://login.microsoftonline.com/{tenantid}/v2.0”}, {„kty” :"RSA","use":"sig","kid":"2ZQpJ3UpbjAYXYGaXEJl8lV0TOI","x5t":"2ZQpJ3UpbjAYXYGaXEJl8lV0TOI","n":"wEM...","e":"AQAB","x5c ":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"}, {"kty":"RSA","use":" sig","kid":"yreX2PsLi-qkbR8QDOmB_ySxp8Q","x5t":"yreX2PsLi-qkbR8QDOmB_ySxp8Q","n":"rv0...","e":"AQAB","x5c":["MIID. .."],"issuer":"https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0"} ]}

Weryfikacja wydawcy klucza uwierzytelniającego

Aplikacja musi korzystać z właściwościemitentdokumentu kluczy, powiązanego z kluczem służącym do uwierzytelnienia tokena, w celu ograniczenia zakresu kluczy:

• Klucze, które mają wartość wystawcy z identyfikatorem GUID, nphttps://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0należy używać tylko w przypadku deklaracjijestw tokenie dokładnie odpowiada wartości.
• Klucze, które mają wartość wystawcy modelowaną jakohttps://login.microsoftonline.com/{tenantid}/v2.0należy używać tylko w przypadku deklaracjijestw tokenie dopasuj tę wartość po zastąpieniu deklaracjiczasw tokenie symbolu zastępczego{identyfikator najemcy}.

Korzystanie z metadanych niezależnych od dzierżawców jest bardziej wydajne w przypadku aplikacji, które akceptują tokeny od wielu dzierżawców.

Podsumowanie

Oto pseudokod podsumowujący sposób sprawdzania wystawcy i wystawcy klucza uwierzytelniającego:

1. Pobierz klucze ze skonfigurowanego adresu URL metadanych
2. Zweryfikuj token, jeśli został uwierzytelniony za pomocą jednego z opublikowanych kluczy, w przeciwnym razie zakończy się niepowodzeniem
3. Zidentyfikuj klucz w metadanych na podstawie dodatkowego nagłówka. Sprawdź właściwość „wystawca” dołączoną do klucza w dokumencie metadanych:

   var wystawca = metadane["kid"].issuer;if (issuer.contains("{tenantId}", CaseInvariant)) wystawca = wystawca.Replace("{tenantid}", token["tid"], CaseInvariant);if (wystawca != token["iss"]) rzut validationException;if (configuration.allowedIssuer != "*" && konfiguracja.allowedIssuer != wystawca) rzut validationException;var issUri = nowy Uri(token["iss"]);if (issUri.Segments.Count < 1) rzut wyjątek validationException;if (issUri.Segments[1] != token["tid"]) rzut wyjątek validationException;

Sprawdź także

• Informacje o oświadczeniach tokenu dostępu
• Zabezpiecz aplikacje i interfejsy API, weryfikując oświadczenia

Następne kroki

• Dowiedz się więcej otokeny zabezpieczające używane w Microsoft Azure AD.