Share via

Przerzucanie klucza podpisywania w Platforma tożsamości Microsoft

  • Artykuł

W tym artykule omówiono, co należy wiedzieć o kluczach publicznych używanych przez Platforma tożsamości Microsoft do podpisywania tokenów zabezpieczających. Należy pamiętać, że te klucze są przerzucane okresowo i w nagłych wypadkach mogą zostać natychmiast przerzucone. Wszystkie aplikacje korzystające z Platforma tożsamości Microsoft powinny być w stanie programowo obsługiwać proces przerzucania kluczy. Dowiesz się, jak działają klucze, jak ocenić wpływ przerzucania do aplikacji oraz jak zaktualizować aplikację lub ustanowić okresowy proces ręcznego przerzucania w celu obsługi przerzucania klucza w razie potrzeby.

Omówienie kluczy podpisywania w Platforma tożsamości Microsoft

Platforma tożsamości Microsoft używa kryptografii klucza publicznego opartej na standardach branżowych w celu ustanowienia zaufania między samymi aplikacjami a aplikacjami, które go używają. W praktyce działa to w następujący sposób: Platforma tożsamości Microsoft używa klucza podpisywania, który składa się z pary kluczy publicznych i prywatnych. Gdy użytkownik loguje się do aplikacji korzystającej z Platforma tożsamości Microsoft do uwierzytelniania, Platforma tożsamości Microsoft tworzy token zabezpieczający zawierający informacje o użytkowniku. Ten token jest podpisany przez Platforma tożsamości Microsoft przy użyciu jego klucza prywatnego przed odesłaniem do aplikacji. Aby sprawdzić, czy token jest prawidłowy i pochodzi z Platforma tożsamości Microsoft, aplikacja musi zweryfikować podpis tokenu przy użyciu kluczy publicznych uwidocznionych przez Platforma tożsamości Microsoft, które znajdują się w dokumencie odnajdywania Połączenie openID dzierżawy lub SAML/WS-Fed dokument metadanych federacji.

W celach bezpieczeństwa klucz podpisywania Platforma tożsamości Microsoft jest rzutowany okresowo i, w przypadku sytuacji awaryjnej, może zostać natychmiast przerzucony. Nie ma ustawionego ani gwarantowanego czasu między tymi rzutami kluczy — każda aplikacja zintegrowana z Platforma tożsamości Microsoft powinna być przygotowana do obsługi zdarzenia przerzucania klucza niezależnie od tego, jak często może wystąpić. Jeśli aplikacja nie obsługuje nagłych odświeżeń i próbuje użyć wygasłego klucza w celu zweryfikowania podpisu tokenu, aplikacja niepoprawnie odrzuca token. Sprawdzanie co 24 godziny pod kątem aktualizacji jest najlepszym rozwiązaniem z ograniczeniem (co pięć minut) natychmiastowych odświeżeń dokumentu klucza, jeśli token nie zostanie zweryfikowany przy użyciu kluczy w pamięci podręcznej aplikacji.

W dokumencie odnajdywania Połączenie openID jest zawsze dostępnych więcej niż jeden prawidłowy klucz oraz dokument metadanych federacji. Aplikacja powinna być przygotowana do użycia dowolnego i wszystkich kluczy określonych w dokumencie, ponieważ jeden klucz może zostać wkrótce wyrzucony, inny może być jego zastąpieniem itd. Liczba obecnych kluczy może ulec zmianie w miarę upływu czasu na podstawie wewnętrznej architektury Platforma tożsamości Microsoft, ponieważ obsługujemy nowe platformy, nowe chmury lub nowe protokoły uwierzytelniania. Ani kolejność kluczy w odpowiedzi JSON, ani kolejność, w jakiej zostały ujawnione, nie powinna być uznawana za zrozumiałą dla Twojej aplikacji.

Aplikacje, które obsługują tylko pojedynczy klucz podpisywania lub te, które wymagają ręcznej aktualizacji kluczy podpisywania, są z natury mniej bezpieczne i mniej niezawodne. Należy je zaktualizować w celu używania bibliotek standardowych w celu zapewnienia, że zawsze używają aktualnych kluczy podpisywania, między innymi najlepszych rozwiązań.

Jak ocenić, czy aplikacja będzie miała wpływ na aplikację i co z tym zrobić

Sposób obsługi przerzucania kluczy przez aplikację zależy od zmiennych, takich jak typ aplikacji lub używany protokół tożsamości i biblioteka. W poniższych sekcjach ocenisz, czy na najbardziej typowe typy aplikacji ma wpływ przerzucanie klucza, i podano wskazówki dotyczące sposobu aktualizowania aplikacji w celu obsługi automatycznego przerzucania lub ręcznego aktualizowania klucza.

Te wskazówki nie mają zastosowania do:

  • Aplikacje dodane z galerii aplikacji Entra firmy Microsoft (w tym niestandardowej) mają oddzielne wskazówki dotyczące kluczy podpisywania. Więcej informacji.
  • Aplikacje lokalne opublikowane za pośrednictwem serwera proxy aplikacji nie muszą martwić się o klucze podpisywania.

Natywne aplikacje klienckie, które uzyskują dostęp do zasobów

Aplikacje uzyskujące dostęp tylko do zasobów (na przykład Microsoft Graph, KeyVault, Outlook API i inne interfejsy API firmy Microsoft) uzyskują token i przekazują go do właściciela zasobu. Ze względu na to, że nie chronią żadnych zasobów, nie sprawdzają tokenu i dlatego nie muszą upewnić się, że jest on prawidłowo podpisany.

Natywne aplikacje klienckie, zarówno klasyczne, jak i mobilne, należą do tej kategorii i w związku z tym nie mają wpływu na przerzucanie.

Aplikacje internetowe/interfejsy API, które uzyskują dostęp do zasobów

Aplikacje uzyskujące dostęp tylko do zasobów (takich jak Microsoft Graph, KeyVault, Outlook API i inne interfejsy API firmy Microsoft) uzyskują token i przekazują go do właściciela zasobu. Ze względu na to, że nie chronią żadnych zasobów, nie sprawdzają tokenu i dlatego nie muszą upewnić się, że jest on prawidłowo podpisany.

Aplikacje internetowe i internetowe interfejsy API korzystające z przepływu tylko do aplikacji (poświadczenia klienta/ certyfikat klienta) do żądania tokenów należą do tej kategorii i w związku z tym nie mają wpływu na przerzucanie.

Aplikacje internetowe/interfejsy API chroniące zasoby i tworzone przy użyciu usług aplikacja systemu Azure

funkcja uwierzytelniania/autoryzacji usług aplikacja systemu Azure Services (EasyAuth) ma już niezbędną logikę do automatycznego obsługi przerzucania kluczy.

Aplikacje internetowe/interfejsy API chroniące zasoby przy użyciu ASP.NET OWIN OpenID Połączenie, WS-Fed lub WindowsAzureActiveDirectoryBearerAuthentication oprogramowania pośredniczącego

Jeśli aplikacja korzysta z ASP.NET OWIN OpenID Połączenie, WS-Fed lub WindowsAzureActiveDirectoryBearerAuthentication oprogramowania pośredniczącego, ma już niezbędną logikę do automatycznego obsługi przerzucania kluczy.

Możesz potwierdzić, że aplikacja korzysta z dowolnego z tych elementów, wyszukując dowolne z poniższych fragmentów kodu w plikach Startup.cs lub Startup.Auth.cs aplikacji.

app.UseOpenIdConnectAuthentication(
    new OpenIdConnectAuthenticationOptions
    {
        // ...
    });

app.UseWsFederationAuthentication(
    new WsFederationAuthenticationOptions
    {
        // ...
    });

app.UseWindowsAzureActiveDirectoryBearerAuthentication(
    new WindowsAzureActiveDirectoryBearerAuthenticationOptions
    {
        // ...
    });

Aplikacje internetowe/interfejsy API chroniące zasoby przy użyciu biblioteki OpenID platformy .NET Core Połączenie lub oprogramowania pośredniczącego JwtBearerAuthentication

Jeśli aplikacja korzysta z ASP.NET OWIN OpenID Połączenie lub JwtBearerAuthentication oprogramowania pośredniczącego, ma już niezbędną logikę do automatycznego obsługi przerzucania kluczy.

Możesz potwierdzić, że aplikacja korzysta z dowolnego z tych elementów, wyszukując dowolne z poniższych fragmentów kodu w Startup.cs aplikacji lub Startup.Auth.cs

app.UseOpenIdConnectAuthentication(
     new OpenIdConnectAuthenticationOptions
     {
         // ...
     });

app.UseJwtBearerAuthentication(
    new JwtBearerAuthenticationOptions
    {
     // ...
     });

Aplikacje internetowe/interfejsy API chroniące zasoby przy użyciu modułu Node.js passport-azure-ad

Jeśli aplikacja korzysta z modułu Node.js passport-ad, ma już niezbędną logikę do automatycznego przerzucania kluczy.

Możesz potwierdzić, że twoja aplikacja passport-ad jest wyszukiwana w poniższym fragmencie kodu w app.js aplikacji

var OIDCStrategy = require('passport-azure-ad').OIDCStrategy;

passport.use(new OIDCStrategy({
    //...
));

Aplikacje internetowe/interfejsy API chroniące zasoby i tworzone za pomocą programu Visual Studio 2015 lub nowszego

Jeśli aplikacja została utworzona przy użyciu szablonu aplikacji internetowej w programie Visual Studio 2015 lub nowszym, a z menu Zmień uwierzytelnianie wybrano opcję Kontasłużbowe, ma już niezbędną logikę do automatycznego obsługi przerzucania kluczy. Ta logika osadzona w bibliotece OWIN OpenID Połączenie oprogramowania pośredniczącego, pobiera i buforuje klucze z dokumentu odnajdywania openID Połączenie i okresowo je odświeża.

W przypadku ręcznego dodania uwierzytelniania do rozwiązania aplikacja może nie mieć niezbędnej logiki przerzucania kluczy. Możesz napisać go samodzielnie lub wykonać kroki opisane w temacie Aplikacje internetowe/interfejsy API przy użyciu innych bibliotek lub ręcznie zaimplementować dowolny z obsługiwanych protokołów.

Aplikacje internetowe chroniące zasoby i tworzone za pomocą programu Visual Studio 2013

Jeśli aplikacja została utworzona przy użyciu szablonu aplikacji internetowej w programie Visual Studio 2013 i wybrano pozycję Konta organizacyjne z menu Zmiana uwierzytelniania , ma już niezbędną logikę do automatycznego obsługi przerzucania kluczy. Ta logika przechowuje unikatowy identyfikator organizacji i informacje o kluczu podpisywania w dwóch tabelach bazy danych skojarzonych z projektem. Parametry połączenia bazy danych można znaleźć w pliku Web.config projektu.

W przypadku ręcznego dodania uwierzytelniania do rozwiązania aplikacja może nie mieć niezbędnej logiki przerzucania kluczy. Musisz napisać go samodzielnie lub wykonać kroki opisane w temacie Aplikacje internetowe/interfejsy API przy użyciu innych bibliotek lub ręcznie zaimplementować dowolny z obsługiwanych protokołów.

Poniższe kroki ułatwiają sprawdzenie, czy logika działa prawidłowo w aplikacji.

  1. W programie Visual Studio 2013 otwórz rozwiązanie, a następnie wybierz na karcie Eksplorator serwera w prawym oknie.
  2. Rozwiń węzeł Połączenie ions danych, Wartość domyślna Połączenie ion, a następnie Tabele. Znajdź tabelę IssuingAuthorityKeys , kliknij ją prawym przyciskiem myszy, a następnie wybierz polecenie Pokaż dane tabeli.
  3. W tabeli IssuingAuthorityKeys będzie co najmniej jeden wiersz odpowiadający wartości odcisku palca klucza. Usuń wszystkie wiersze w tabeli.
  4. Kliknij prawym przyciskiem myszy tabelę Dzierżawy , a następnie wybierz polecenie Pokaż dane tabeli.
  5. W tabeli Tenants (Dzierżawy) będzie istnieć co najmniej jeden wiersz, który odpowiada unikatowego identyfikatora dzierżawy katalogu. Usuń wszystkie wiersze w tabeli. Jeśli nie usuniesz wierszy zarówno w tabeli Tenants, jak i w tabeli IssuingAuthorityKeys, wystąpi błąd w czasie wykonywania.
  6. Skompiluj i uruchom aplikację. Po zalogowaniu się na koncie możesz zatrzymać aplikację.
  7. Wróć do Eksploratora serwera i przyjrzyj się wartościom w tabeli IssuingAuthorityKeys i Tenants. Zauważysz, że zostały one automatycznie ponownie wypełnione odpowiednimi informacjami z dokumentu metadanych federacji.

Internetowe interfejsy API chroniące zasoby i tworzone za pomocą programu Visual Studio 2013

Jeśli aplikacja internetowego interfejsu API została utworzona w programie Visual Studio 2013 przy użyciu szablonu internetowego interfejsu API, a następnie wybrano pozycję Konta organizacyjne z menu Zmień uwierzytelnianie, masz już niezbędną logikę w aplikacji.

Jeśli uwierzytelnianie zostało skonfigurowane ręcznie, postępuj zgodnie z poniższymi instrukcjami, aby dowiedzieć się, jak skonfigurować internetowy interfejs API w celu automatycznego aktualizowania jego kluczowych informacji.

Poniższy fragment kodu pokazuje, jak pobrać najnowsze klucze z dokumentu metadanych federacji, a następnie używa programu obsługi tokenów JWT do sprawdzania poprawności tokenu. W fragmencie kodu założono, że użyjesz własnego mechanizmu buforowania do utrwalania klucza w celu zweryfikowania przyszłych tokenów z Platforma tożsamości Microsoft, niezależnie od tego, czy znajduje się w bazie danych, pliku konfiguracji, czy w innym miejscu.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.IdentityModel.Tokens;
using System.Configuration;
using System.Security.Cryptography.X509Certificates;
using System.Xml;
using System.IdentityModel.Metadata;
using System.ServiceModel.Security;
using System.Threading;

namespace JWTValidation
{
    public class JWTValidator
    {
        private string MetadataAddress = "[Your Federation Metadata document address goes here]";

        // Validates the JWT Token that's part of the Authorization header in an HTTP request.
        public void ValidateJwtToken(string token)
        {
            JwtSecurityTokenHandler tokenHandler = new JwtSecurityTokenHandler()
            {
                // Do not disable for production code
                CertificateValidator = X509CertificateValidator.None
            };

            TokenValidationParameters validationParams = new TokenValidationParameters()
            {
                AllowedAudience = "[Your App ID URI goes here]",
                ValidIssuer = "[The issuer for the token goes here, such as https://sts.windows.net/aaaabbbb-0000-cccc-1111-dddd2222eeee/]",
                SigningTokens = GetSigningCertificates(MetadataAddress)

                // Cache the signing tokens by your desired mechanism
            };

            Thread.CurrentPrincipal = tokenHandler.ValidateToken(token, validationParams);
        }

        // Returns a list of certificates from the specified metadata document.
        public List<X509SecurityToken> GetSigningCertificates(string metadataAddress)
        {
            List<X509SecurityToken> tokens = new List<X509SecurityToken>();

            if (metadataAddress == null)
            {
                throw new ArgumentNullException(metadataAddress);
            }

            using (XmlReader metadataReader = XmlReader.Create(metadataAddress))
            {
                MetadataSerializer serializer = new MetadataSerializer()
                {
                    // Do not disable for production code
                    CertificateValidationMode = X509CertificateValidationMode.None
                };

                EntityDescriptor metadata = serializer.ReadMetadata(metadataReader) as EntityDescriptor;

                if (metadata != null)
                {
                    SecurityTokenServiceDescriptor stsd = metadata.RoleDescriptors.OfType<SecurityTokenServiceDescriptor>().First();

                    if (stsd != null)
                    {
                        IEnumerable<X509RawDataKeyIdentifierClause> x509DataClauses = stsd.Keys.Where(key => key.KeyInfo != null && (key.Use == KeyType.Signing || key.Use == KeyType.Unspecified)).
                                                             Select(key => key.KeyInfo.OfType<X509RawDataKeyIdentifierClause>().First());

                        tokens.AddRange(x509DataClauses.Select(token => new X509SecurityToken(new X509Certificate2(token.GetX509RawData()))));
                    }
                    else
                    {
                        throw new InvalidOperationException("There is no RoleDescriptor of type SecurityTokenServiceType in the metadata");
                    }
                }
                else
                {
                    throw new Exception("Invalid Federation Metadata document");
                }
            }
            return tokens;
        }
    }
}

Aplikacje internetowe chroniące zasoby i tworzone za pomocą programu Visual Studio 2012

Jeśli aplikacja została skompilowana w programie Visual Studio 2012, prawdopodobnie użyto narzędzia Identity and Access w celu skonfigurowania aplikacji. Prawdopodobnie używasz również rejestru walidującego nazwy wystawcy (VINR). VinR jest odpowiedzialny za utrzymywanie informacji o zaufanych dostawcach tożsamości (Platforma tożsamości Microsoft) i kluczach używanych do weryfikowania tokenów wystawionych przez nich. VinR ułatwia również automatyczne aktualizowanie informacji o kluczu przechowywanych w pliku Web.config przez pobranie najnowszego dokumentu metadanych federacji skojarzonego z katalogiem, sprawdzenie, czy konfiguracja jest nieaktualna z najnowszym dokumentem, i zaktualizowanie aplikacji w celu użycia nowego klucza w razie potrzeby.

Jeśli aplikacja została utworzona przy użyciu dowolnego z przykładów kodu lub dokumentacji przewodnika dostarczonej przez firmę Microsoft, logika przerzucania kluczy jest już zawarta w projekcie. Zauważysz, że poniższy kod już istnieje w projekcie. Jeśli aplikacja nie ma jeszcze tej logiki, wykonaj poniższe kroki, aby dodać ją i sprawdzić, czy działa poprawnie.

  1. W Eksplorator rozwiązań dodaj odwołanie do zestawu System.IdentityModel dla odpowiedniego projektu.
  2. Otwórz plik Global.asax.cs i dodaj następujące dyrektywy using:
    using System.Configuration;
using System.IdentityModel.Tokens;
  3. Dodaj następującą metodę do pliku Global.asax.cs : 
    protected void RefreshValidationSettings()
{
 string configPath = AppDomain.CurrentDomain.BaseDirectory + "\\" + "Web.config";
 string metadataAddress =
               ConfigurationManager.AppSettings["ida:FederationMetadataLocation"];
 ValidatingIssuerNameRegistry.WriteToConfig(metadataAddress, configPath);
}
  4. Wywołaj metodę RefreshValidation Ustawienia() w metodzie Application_Start() w Global.asax.cs, jak pokazano poniżej:
    protected void Application_Start()
{
 AreaRegistration.RegisterAllAreas();
 ...
 RefreshValidationSettings();
}

Po zakończeniu tych kroków konfiguracja aplikacji Web.config zostanie zaktualizowana o najnowsze informacje z dokumentu metadanych federacji, w tym najnowsze klucze. Ta aktualizacja będzie występować za każdym razem, gdy pula aplikacji będzie odzyskiwana w usługach IIS; domyślnie usługi IIS są ustawiane na odtwarzanie aplikacji co 29 godzin.

Wykonaj poniższe kroki, aby sprawdzić, czy logika przerzucania klucza działa.

  1. Po sprawdzeniu, że aplikacja używa powyższego kodu, otwórz plik Web.config i przejdź do< bloku issuerNameRegistry>, w szczególności szukając następujących kilku wierszy:
    <issuerNameRegistry type="System.IdentityModel.Tokens.ValidatingIssuerNameRegistry, System.IdentityModel.Tokens.ValidatingIssuerNameRegistry">
     <authority name="https://sts.windows.net/aaaabbbb-0000-cccc-1111-dddd2222eeee/">
       <keys>
         <add thumbprint="AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00" />
       </keys>
  2. W ustawieniu <add thumbprint=""> zmień wartość odcisku palca, zastępując dowolny znak innym znakiem. Zapisz plik Web.config.
  3. Skompiluj aplikację, a następnie uruchom ją. Jeśli możesz ukończyć proces logowania, aplikacja pomyślnie aktualizuje klucz, pobierając wymagane informacje z dokumentu metadanych federacji katalogu. Jeśli masz problemy z logowaniem, upewnij się, że zmiany w aplikacji są poprawne, czytając artykuł Dodawanie logowania do aplikacji internetowej przy użyciu Platforma tożsamości Microsoft lub pobieranie i sprawdzanie następującego przykładu kodu: Aplikacja w chmurze wielodostępnej dla firmy Microsoft Entra ID.

Aplikacje internetowe/interfejsy API chroniące zasoby przy użyciu innych bibliotek lub ręcznie implementowanie dowolnego z obsługiwanych protokołów

Jeśli używasz innej biblioteki lub ręcznie zaimplementowano dowolny z obsługiwanych protokołów, należy przejrzeć bibliotekę lub implementację, aby upewnić się, że klucz jest pobierany z dokumentu odnajdywania openID Połączenie lub dokumentu metadanych federacji. Jednym ze sposobów sprawdzenia tego jest przeprowadzenie wyszukiwania w kodzie lub w kodzie biblioteki pod kątem wywołań dokumentu odnajdywania OpenID lub dokumentu metadanych federacji.

Jeśli klucz jest przechowywany gdzieś lub zakodowany w aplikacji, możesz ręcznie pobrać klucz i odpowiednio go zaktualizować, wykonując ręczne przerzucanie zgodnie z instrukcjami na końcu tego dokumentu ze wskazówkami. Zdecydowanie zachęcamy do ulepszenia aplikacji w celu obsługi automatycznego przerzucania przy użyciu dowolnego z metod opisanych w tym artykule, aby uniknąć przyszłych zakłóceń i narzutów, jeśli Platforma tożsamości Microsoft zwiększy jego cykl przerzucania lub ma awaryjne przerzucanie poza pasmem.

Jak przetestować aplikację, aby określić, czy będzie to miało wpływ

Możesz sprawdzić, czy aplikacja obsługuje automatyczne przerzucanie kluczy, korzystając z poniższych skryptów programu PowerShell.

Aby sprawdzić i zaktualizować klucze podpisywania przy użyciu programu PowerShell, potrzebny jest moduł MSIdentityTools programu PowerShell.

  1. Zainstaluj moduł MSIdentityTools programu PowerShell:

    Install-Module -Name MSIdentityTools

  2. Zaloguj się przy użyciu polecenia Połączenie-MgGraph z kontem administratora, aby wyrazić zgodę na wymagane zakresy:

     Connect-MgGraph -Scope "Application.ReadWrite.All"

  3. Pobierz listę dostępnych odcisków palca klucza podpisywania:

    Get-MsIdSigningKeyThumbprint

  4. Wybierz dowolne odciski palca klucza i skonfiguruj identyfikator entra firmy Microsoft do używania tego klucza z aplikacją (pobierz identyfikator aplikacji z centrum administracyjnego firmy Microsoft Entra):

    Update-MsIdApplicationSigningKeyThumbprint -ApplicationId <ApplicationId> -KeyThumbprint <Thumbprint>

  5. Przetestuj aplikację internetową, logując się, aby uzyskać nowy token. Zmiana aktualizacji klucza jest natychmiastowa, ale upewnij się, że używasz nowej sesji przeglądarki (na przykład w przeglądarce Internet Explorer "InPrivate", "Incognito" przeglądarki Chrome lub "Prywatnego" przeglądarki Firefox), aby upewnić się, że otrzymujesz nowy token.

  6. Dla każdego z zwróconych odcisków palca klucza podpisywania uruchom polecenie cmdlet i przetestuj Update-MsIdApplicationSigningKeyThumbprint proces logowania aplikacji internetowej.

  7. Jeśli aplikacja internetowa prawidłowo się zaloguje, obsługuje automatyczne przerzucanie. Jeśli tak nie jest, zmodyfikuj aplikację, aby obsługiwała ręczne przerzucanie. Aby uzyskać więcej informacji, zobacz Ustanawianie ręcznego procesu przerzucania.

  8. Uruchom następujący skrypt, aby przywrócić normalne zachowanie:

    Update-MsIdApplicationSigningKeyThumbprint -ApplicationId <ApplicationId> -Default

Jak wykonać ręczne przerzucanie, jeśli aplikacja nie obsługuje automatycznego przerzucania

Jeśli aplikacja nie obsługuje automatycznego przerzucania, należy ustanowić proces, który okresowo monitoruje klucze podpisywania Platforma tożsamości Microsoft i odpowiednio wykonuje ręczne przerzucanie.

Aby sprawdzić i zaktualizować klucze podpisywania za pomocą programu PowerShell, potrzebny MSIdentityTools jest moduł programu PowerShell.

  1. MSIdentityTools Zainstaluj moduł programu PowerShell:

    Install-Module -Name MSIdentityTools

  2. Pobierz najnowszy klucz podpisywania (pobierz identyfikator dzierżawy z centrum administracyjnego firmy Microsoft Entra):

    Get-MsIdSigningKeyThumbprint -Tenant <tenandId> -Latest

  3. Porównaj ten klucz z kluczem, który aplikacja jest obecnie zakodowana lub skonfigurowana do użycia.

  4. Jeśli najnowszy klucz różni się od klucza używanego przez aplikację, pobierz najnowszy klucz podpisywania:

    Get-MsIdSigningKeyThumbprint -Latest -DownloadPath <DownloadFolderPath>

  5. Zaktualizuj kod lub konfigurację aplikacji, aby użyć nowego klucza.

  6. Skonfiguruj identyfikator entra firmy Microsoft, aby używać tego najnowszego klucza w aplikacji (pobierz identyfikator aplikacji z centrum administracyjnego firmy Microsoft Entra):

    Get-MsIdSigningKeyThumbprint -Latest | Update-MsIdApplicationSigningKeyThumbprint -ApplicationId <ApplicationId>

  7. Przetestuj aplikację internetową, logując się, aby uzyskać nowy token. Zmiana aktualizacji klucza jest natychmiastowa, ale upewnij się, że używasz nowej sesji przeglądarki (na przykład w przeglądarce Internet Explorer "InPrivate", "Incognito" przeglądarki Chrome lub "Prywatnego" przeglądarki Firefox), aby upewnić się, że otrzymujesz nowy token.

  8. Jeśli wystąpią jakiekolwiek problemy, wróć do poprzedniego klucza, którego używasz, i skontaktuj się z pomoc techniczna platformy Azure:

    Update-MsIdApplicationSigningKeyThumbprint -ApplicationId <ApplicationId> -KeyThumbprint <PreviousKeyThumbprint>

  9. Po zaktualizowaniu aplikacji w celu obsługi ręcznego przerzucania przywróć normalne zachowanie:

    Update-MsIdApplicationSigningKeyThumbprint -ApplicationId <ApplicationId> -Default