Omówienie tokenów w usłudze Azure Active Directory B2C

Artykuł
04/24/2023

Usługa Azure Active Directory B2C (Azure AD B2C) emituje różne typy tokenów zabezpieczających, ponieważ przetwarza każdy przepływ uwierzytelniania. W tym artykule opisano format, cechy zabezpieczeń i zawartość każdego typu tokenu.

Typy tokenów

Azure AD B2C obsługuje protokoły OAuth 2.0 i OpenID Connect, które używają tokenów do uwierzytelniania i bezpiecznego dostępu do zasobów. Wszystkie tokeny używane w usłudze Azure AD B2C to tokeny internetowe JSON (JWTs), które zawierają potwierdzenia informacji na temat elementu nośnego i temat tokenu.

Następujące tokeny są używane w komunikacji z Azure AD B2C:

Token identyfikatora — JWT zawierający oświadczenia, których można użyć do identyfikowania użytkowników w aplikacji. Ten token jest bezpiecznie wysyłany w żądaniach HTTP do komunikacji między dwoma składnikami tej samej aplikacji lub usługi. Oświadczenia można użyć w tokenie identyfikatora w miarę dopasowania. Są one często używane do wyświetlania informacji o koncie lub podejmowania decyzji dotyczących kontroli dostępu w aplikacji. Tokeny identyfikatorów wystawione przez usługę Azure AD B2C są podpisane, ale nie są szyfrowane. Gdy aplikacja lub interfejs API odbiera token identyfikatora, musi zweryfikować podpis, aby udowodnić, że token jest autentyczny. Aplikacja lub interfejs API muszą również zweryfikować kilka oświadczeń w tokenie, aby udowodnić, że jest ona prawidłowa. W zależności od wymagań scenariusza oświadczenia zweryfikowane przez aplikację mogą się różnić, ale w każdym scenariuszu aplikacja musi wykonać kilka typowych weryfikacji oświadczeń.
Token dostępu — JWT zawierający oświadczenia, których można użyć do identyfikowania przyznanych uprawnień do interfejsów API. Tokeny dostępu są podpisane, ale nie są szyfrowane. Tokeny dostępu służą do zapewniania dostępu do interfejsów API i serwerów zasobów. Gdy interfejs API otrzyma token dostępu, musi zweryfikować podpis, aby udowodnić, że token jest autentyczny. Interfejs API musi również zweryfikować kilka oświadczeń w tokenie, aby udowodnić, że jest ona prawidłowa. W zależności od wymagań scenariusza oświadczenia zweryfikowane przez aplikację mogą się różnić, ale w każdym scenariuszu aplikacja musi wykonać kilka typowych weryfikacji oświadczeń.
Token odświeżania — tokeny odświeżania są używane do uzyskiwania nowych tokenów identyfikatorów i tokenów dostępu w przepływie protokołu OAuth 2.0. Zapewniają one aplikacji długoterminowy dostęp do zasobów w imieniu użytkowników bez konieczności interakcji z tymi użytkownikami. Tokeny odświeżania są nieprzezroczyste dla aplikacji. Są one wydawane przez Azure AD B2C i mogą być sprawdzane i interpretowane tylko przez Azure AD B2C. Są one długotrwałe, ale aplikacja nie powinna być napisana z oczekiwaniami, że token odświeżania będzie trwać przez określony okres czasu. Tokeny odświeżania można unieważnić w dowolnym momencie z różnych powodów. Jedynym sposobem, aby aplikacja wiedziała, czy token odświeżania jest prawidłowy, jest próba jego zrealizowania, wysyłając żądanie tokenu do Azure AD B2C. Po zrealizowaniu tokenu odświeżania dla nowego tokenu otrzymasz nowy token odświeżania w odpowiedzi tokenu. Zapisz nowy token odświeżania. Zastępuje token odświeżania, który został wcześniej użyty w żądaniu. Ta akcja pomaga zagwarantować, że tokeny odświeżania pozostaną prawidłowe tak długo, jak to możliwe. Aplikacje jednostronicowe korzystające z przepływu kodu autoryzacji z kluczem PKCE zawsze mają okres istnienia tokenu odświeżania przez 24 godziny. Dowiedz się więcej na temat wpływu na zabezpieczenia tokenów odświeżania w przeglądarce.

Punkty końcowe

Zarejestrowana aplikacja odbiera tokeny i komunikuje się z Azure AD B2C, wysyłając żądania do następujących punktów końcowych:

https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/authorize
https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/token

Tokeny zabezpieczające odbierane przez aplikację z Azure AD B2C mogą pochodzić z /authorize punktów końcowych lub/token. Gdy tokeny identyfikatorów są uzyskiwane z następujących elementów:

/authorize punkt końcowy jest wykonywany przy użyciu niejawnego przepływu, który jest często używany do logowania użytkowników do aplikacji internetowych opartych na języku JavaScript. Jeśli jednak aplikacja używa MSAL.js 2.0 lub nowszej, nie włączaj niejawnego udzielania przepływu w rejestracji aplikacji, ponieważ MSAL.js 2.0+ obsługuje przepływ kodu autoryzacji za pomocą protokołu PKCE.
/token punkt końcowy jest wykonywany przy użyciu przepływu kodu autoryzacji, który przechowuje token ukryty w przeglądarce.

Oświadczenia

W przypadku korzystania z usługi Azure AD B2C masz szczegółową kontrolę nad zawartością tokenów. Możesz skonfigurować przepływy użytkownika i zasady niestandardowe , aby wysyłać określone zestawy danych użytkownika w oświadczeniach, które są wymagane dla aplikacji. Te oświadczenia mogą zawierać standardowe właściwości, takie jak displayName i emailAddress. Aplikacje mogą używać tych oświadczeń do bezpiecznego uwierzytelniania użytkowników i żądań.

Oświadczenia w tokenach identyfikatorów nie są zwracane w żadnej określonej kolejności. Nowe oświadczenia można wprowadzać w tokenach identyfikatorów w dowolnym momencie. Aplikacja nie powinna przerywać pracy w miarę wprowadzania nowych oświadczeń. W oświadczeniach można również uwzględnić niestandardowe atrybuty użytkownika .

W poniższej tabeli wymieniono oświadczenia, których można oczekiwać w tokenach identyfikatorów i tokenach dostępu wystawionych przez usługę Azure AD B2C.

Nazwa	Claim	Przykładowa wartość	Opis
Grupy odbiorców	`aud`	`90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6`	Identyfikuje zamierzonego adresata tokenu. W przypadku Azure AD B2C odbiorcy to identyfikator aplikacji. Aplikacja powinna zweryfikować tę wartość i odrzucić token, jeśli nie jest ona zgodna. Odbiorcy są synonimem zasobu.
Wystawca	`iss`	`https://<tenant-name>.b2clogin.com/775527ff-9a37-4307-8b3d-cc311f58d925/v2.0/`	Identyfikuje usługę tokenu zabezpieczającego (STS), która tworzy i zwraca token. Identyfikuje również katalog, w którym użytkownik został uwierzytelniony. Aplikacja powinna zweryfikować oświadczenie wystawcy, aby upewnić się, że token pochodzi z odpowiedniego punktu końcowego.
Wystawiony pod adresem	`iat`	`1438535543`	Czas wystawienia tokenu, reprezentowany w czasie epoki.
Czas wygaśnięcia	`exp`	`1438539443`	Czas, w którym token staje się nieprawidłowy, reprezentowany w czasie epoki. Aplikacja powinna użyć tego oświadczenia, aby zweryfikować ważność okresu istnienia tokenu.
Nie wcześniej	`nbf`	`1438535543`	Czas, w którym token staje się prawidłowy, reprezentowany w czasie epoki. Ten czas jest zwykle taki sam jak czas wystawienia tokenu. Aplikacja powinna użyć tego oświadczenia, aby zweryfikować ważność okresu istnienia tokenu.
Wersja	`ver`	`1.0`	Wersja tokenu identyfikatora zdefiniowana przez usługę Azure AD B2C.
Skrót kodu	`c_hash`	`SGCPtt01wxwfgnYZy2VJtQ`	Skrót kodu zawarty w tokenie identyfikatora tylko wtedy, gdy token jest wystawiony razem z kodem autoryzacji OAuth 2.0. Skrót kodu może służyć do weryfikowania autentyczności kodu autoryzacji. Aby uzyskać więcej informacji na temat przeprowadzania tej weryfikacji, zobacz specyfikację OpenID Connect.
Skrót tokenu dostępu	`at_hash`	`SGCPtt01wxwfgnYZy2VJtQ`	Skrót tokenu dostępu uwzględniony w tokenie identyfikatora tylko wtedy, gdy token jest wystawiony razem z tokenem dostępu OAuth 2.0. Skrót tokenu dostępu może służyć do weryfikowania autentyczności tokenu dostępu. Aby uzyskać więcej informacji o sposobie przeprowadzania tej weryfikacji, zobacz specyfikację OpenID Connect
Nonce	`nonce`	`12345`	Nonce to strategia służąca do eliminowania ataków powtarzania tokenu. Aplikacja może określić wartość nietypową w żądaniu autoryzacji przy użyciu parametru `nonce` zapytania. Wartość, którą podajesz w żądaniu, jest emitowana niezmodyfikowana tylko w `nonce` oświadczeniu tokenu identyfikatora. To oświadczenie umożliwia aplikacji zweryfikowanie wartości względem wartości określonej w żądaniu. Aplikacja powinna przeprowadzić tę walidację podczas procesu weryfikacji tokenu identyfikatora.
Temat	`sub`	`884408e1-2918-4cz0-b12d-3aa027d7563b`	Podmiot zabezpieczeń, o którym token potwierdza informacje, takie jak użytkownik aplikacji. Ta wartość jest niezmienna i nie można jej ponownie przypisać ani ponownie użyć. Może służyć do bezpiecznego przeprowadzania kontroli autoryzacji, na przykład gdy token jest używany do uzyskiwania dostępu do zasobu. Domyślnie oświadczenie podmiotu jest wypełniane identyfikatorem obiektu użytkownika w katalogu.
Dokumentacja klasy kontekstu uwierzytelniania	`acr`	Nie dotyczy	Używane tylko w przypadku starszych zasad.
Zasady struktury zaufania	`tfp`	`b2c_1_signupsignin1`	Nazwa zasad, które zostały użyte do uzyskania tokenu identyfikatora.
Czas uwierzytelniania	`auth_time`	`1438535543`	Czas ostatniego wprowadzenia poświadczeń przez użytkownika, reprezentowany w czasie epoki. Nie ma dyskryminacji między tym uwierzytelnianiem jest nowym logowaniem, sesją logowania jednokrotnego lub innym typem logowania. Jest `auth_time` to ostatni raz, gdy aplikacja (lub użytkownik) zainicjowała próbę uwierzytelnienia przeciwko Azure AD B2C. Metoda używana do uwierzytelniania nie jest rozróżniana.
Zakres	`scp`	`Read`	Uprawnienia przyznane zasobowi dla tokenu dostępu. Wiele udzielonych uprawnień jest oddzielonych spacją.
Autoryzowana strona	`azp`	`975251ed-e4f5-4efd-abcb-5f1a8f566ab7`	Identyfikator aplikacji klienckiej, która zainicjowała żądanie.

Konfigurowanie

Następujące właściwości służą do zarządzania okresami istnienia tokenów zabezpieczających emitowanych przez usługę Azure AD B2C:

Dostęp & Okresy istnienia tokenu identyfikatora (w minutach) — okres istnienia tokenu elementu nośnego OAuth 2.0 używanego do uzyskiwania dostępu do chronionego zasobu. Wartość domyślna to 60 minut. Minimalna (włącznie) wynosi 5 minut. Maksymalna (włącznie) wynosi 1440 minut.
Okres istnienia tokenu odświeżania (dni) — maksymalny okres, przed którym token odświeżania może służyć do uzyskania nowego tokenu dostępu lub tokenu identyfikatora. Okres obejmuje również uzyskanie nowego tokenu odświeżania, jeśli aplikacja otrzymała offline_access zakres. Wartość domyślna to 14 dni. Minimalna (włącznie) to jeden dzień. Maksymalna (włącznie) wynosi 90 dni.
Okres istnienia okna przesuwania tokenu odświeżania (dni) — po upływie tego okresu użytkownik zostanie zmuszony do ponownego uwierzytelnienia, niezależnie od okresu ważności ostatniego tokenu odświeżania uzyskanego przez aplikację. Można go podać tylko wtedy, gdy przełącznik jest ustawiony na Wartość Powiązana. Musi być większa lub równa wartości Okresu istnienia tokenu odświeżania (dni). Jeśli przełącznik ma wartość Brak wygaśnięcia, nie możesz podać określonej wartości. Wartość domyślna to 90 dni. Minimalna (włącznie) to jeden dzień. Maksymalna (włącznie) wynosi 365 dni.

Następujące przypadki użycia są włączone przy użyciu następujących właściwości:

Zezwalaj użytkownikowi na pozostanie zalogowanym do aplikacji mobilnej na czas nieokreślony, o ile użytkownik jest stale aktywny w aplikacji. Możesz ustawić okres istnienia okna przesuwania tokenu odświeżania (dni) na Brak wygaśnięcia w przepływie użytkownika logowania.
Spełnij wymagania dotyczące zabezpieczeń i zgodności w branży, ustawiając odpowiednie okresy istnienia tokenu dostępu.

Te ustawienia nie są dostępne dla przepływów użytkownika resetowania haseł.

Zgodność

Następujące właściwości służą do zarządzania zgodnością tokenów:

Oświadczenie wystawcy (iss) — ta właściwość identyfikuje dzierżawę usługi Azure AD B2C, która wystawiła token. Wartość domyślna to https://<domain>/{B2C tenant GUID}/v2.0/. Wartość zawiera https://<domain>/tfp/{B2C tenant GUID}/{Policy ID}/v2.0/ identyfikatory zarówno dla dzierżawy Azure AD B2C, jak i przepływu użytkownika, który został użyty w żądaniu tokenu. Jeśli aplikacja lub biblioteka wymaga Azure AD B2C, aby być zgodne ze specyfikacją OpenID Connect Discovery 1.0, użyj tej wartości.
Oświadczenie podmiotu (sub) — ta właściwość identyfikuje jednostkę, dla której token potwierdza informacje. Wartość domyślna to ObjectID, która wypełnia sub oświadczenie w tokenie identyfikatorem obiektu użytkownika. Wartość Nieobsługiwana jest dostępna tylko w przypadku zgodności z poprzednimi wersjami. Zaleca się przełączenie do identyfikatora ObjectID natychmiast po jego przejściu.
Oświadczenie reprezentujące identyfikator zasad — ta właściwość identyfikuje typ oświadczenia, w którym jest wypełniana nazwa zasad używana w żądaniu tokenu. Wartość domyślna to tfp. Wartość parametru acr jest podawana tylko w celu zapewnienia zgodności z poprzednimi wersjami.

Przekazywanie

Po rozpoczęciu podróży użytkownika Azure AD B2C otrzymuje token dostępu od dostawcy tożsamości. Azure AD B2C używa tego tokenu do pobierania informacji o użytkowniku. Możesz włączyć oświadczenie w przepływie użytkownika, aby przekazać token do aplikacji zarejestrowanych w usłudze Azure AD B2C. Aplikacja musi używać zalecanego przepływu użytkownika , aby móc korzystać z przekazywania tokenu jako oświadczenia.

Azure AD B2C obecnie obsługuje tylko przekazywanie tokenu dostępu dostawców tożsamości OAuth 2.0, w tym Facebook i Google. Dla wszystkich innych dostawców tożsamości oświadczenie jest zwracane puste.

Walidacja

Aby zweryfikować token, aplikacja powinna sprawdzić zarówno podpis, jak i oświadczenia tokenu. Wiele bibliotek typu open source jest dostępnych do sprawdzania poprawności zestawów JWTs w zależności od preferowanego języka. Zaleca się zapoznanie się z tymi opcjami zamiast implementować własną logikę walidacji.

Weryfikowanie podpisu

Zestaw JWT zawiera trzy segmenty, nagłówek, treść i podpis. Segment podpisu może służyć do weryfikowania autentyczności tokenu, aby mógł być zaufany przez aplikację. Azure AD tokeny B2C są podpisane przy użyciu standardowych w branży algorytmów szyfrowania asymetrycznego, takich jak RSA 256.

Nagłówek tokenu zawiera informacje o kluczu i metodzie szyfrowania używanej do podpisania tokenu:

{
        "typ": "JWT",
        "alg": "RS256",
        "kid": "GvnPApfWMdLRi8PDmisFn7bprKg"
}

Wartość oświadczenia alg to algorytm, który został użyty do podpisania tokenu. Wartość oświadczenia dla dzieci jest kluczem publicznym, który został użyty do podpisania tokenu. W dowolnym momencie Azure AD B2C może podpisać token przy użyciu dowolnego zestawu par kluczy publicznych i prywatnych. Azure AD B2C okresowo obraca możliwy zestaw kluczy. Aplikacja powinna być zapisywana w celu automatycznego obsługi tych kluczowych zmian. Rozsądna częstotliwość sprawdzania dostępności aktualizacji kluczy publicznych używanych przez usługę Azure AD B2C jest co 24 godziny. Aby obsłużyć nieoczekiwane zmiany klucza, aplikacja powinna zostać zapisana w celu ponownego pobrania kluczy publicznych, jeśli otrzyma nieoczekiwaną wartość dziecka .

Azure AD B2C ma punkt końcowy metadanych OpenID Connect. Przy użyciu tego punktu końcowego aplikacje mogą żądać informacji o Azure AD B2C w czasie wykonywania. Te informacje obejmują punkty końcowe, zawartość tokenu i klucze podpisywania tokenu. Dzierżawa usługi Azure AD B2C zawiera dokument metadanych JSON dla poszczególnych zasad. Dokument metadanych to obiekt JSON zawierający kilka przydatnych informacji. Metadane zawierają jwks_uri, które zapewniają lokalizację zestawu kluczy publicznych używanych do podpisywania tokenów. Ta lokalizacja jest dostępna w tym miejscu, ale najlepiej jest dynamicznie pobrać lokalizację przy użyciu dokumentu metadanych i analizowania jwks_uri:

https://contoso.b2clogin.com/contoso.onmicrosoft.com/b2c_1_signupsignin1/discovery/v2.0/keys

Dokument JSON znajdujący się pod tym adresem URL zawiera wszystkie informacje o kluczu publicznym używane w określonym momencie. Aplikacja może użyć kid oświadczenia w nagłówku JWT, aby wybrać klucz publiczny w dokumencie JSON używanym do podpisywania określonego tokenu. Następnie może przeprowadzić walidację podpisu przy użyciu poprawnego klucza publicznego i wskazanego algorytmu.

Dokument metadanych zasad B2C_1_signupsignin1 w dzierżawie contoso.onmicrosoft.com znajduje się pod adresem:

https://contoso.b2clogin.com/contoso.onmicrosoft.com/b2c_1_signupsignin1/v2.0/.well-known/openid-configuration

Aby określić, które zasady zostały użyte do podpisania tokenu (i gdzie należy przejść do żądania metadanych), masz dwie opcje. Najpierw nazwa zasad jest dołączona do tfp (domyślnego) lub acr oświadczenia (zgodnie z konfiguracją) w tokenie. Oświadczenia można analizować z treści JWT przez dekodowanie treści base-64 dekodując treść i deserializacji ciągu JSON, który daje wyniki. Oświadczenie tfp lub acr to nazwa zasad, które zostały użyte do wystawienia tokenu. Drugą opcją jest kodowanie zasad w wartości parametru state podczas wystawiania żądania, a następnie dekodowanie go w celu określenia, które zasady zostały użyte. Każda z metod jest prawidłowa.

Azure AD B2C używa algorytmu RS256, który jest oparty na specyfikacji RFC 3447. Klucz publiczny składa się z dwóch składników: modulu RSA (n) i publicznego wykładnika RSA (e). Można programowo konwertować n wartości i e na format certyfikatu na potrzeby walidacji tokenu.

Opis sposobu przeprowadzania walidacji podpisu wykracza poza zakres tego dokumentu. Dostępnych jest wiele bibliotek typu open source, które ułatwiają weryfikację tokenu.

Weryfikowanie oświadczeń

Gdy aplikacje lub interfejs API odbierają token identyfikatora, należy również wykonać kilka kontroli względem oświadczeń w tokenie identyfikatora. Należy sprawdzić następujące oświadczenia:

audience — sprawdza, czy token identyfikatora miał zostać przekazany aplikacji.
nie przed upływem czasu wygaśnięcia — sprawdza, czy token identyfikatora nie wygasł.
issuer — sprawdza, czy token został wystawiony dla aplikacji przez Azure AD B2C.
nonce — strategia ograniczania ataków replay tokenu.

Aby uzyskać pełną listę weryfikacji, które aplikacja powinna wykonać, zapoznaj się ze specyfikacją OpenID Connect.

Następne kroki

Dowiedz się więcej o sposobie używania tokenów dostępu.

Udostępnij za pośrednictwem