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

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, charakterystykę zabezpieczeń i zawartość każdego typu tokenu.

Typy tokenów

Usługa 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 tematu tokenu.

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

• Token ID — JWT, który zawiera informacje, których można użyć do identyfikacji 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. Możesz używać oświadczeń w tokenie identyfikatora, jak uznasz za stosowne. 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 uwierzytelniony. Aplikacja lub interfejs API musi również zweryfikować kilka oświadczeń w tokenie, aby udowodnić, że jest on prawidłowy. 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 — zestaw JWT zawierający oświadczenia, których można użyć do identyfikowania udzielonych uprawnień do interfejsów API. Tokeny dostępu są podpisane, ale nie są szyfrowane. Tokeny dostępu są używane do zapewniania dostępu do interfejsów API i serwerów zasobów. Gdy interfejs API odbiera token dostępu, musi zweryfikować podpis, aby udowodnić, że token jest uwierzytelniony. Interfejs API musi również zweryfikować kilka oświadczeń w tokenie, aby udowodnić, że jest on prawidłowy. 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ą niewidoczne dla Twojej aplikacji. Są one wydawane przez usługę Azure AD B2C i mogą być sprawdzane i interpretowane tylko przez usługę Azure AD B2C. Są one długotrwałe, ale aplikacja nie powinna być zapisywana z oczekiwaniami, że token odświeżania będzie trwać przez określony czas. Tokeny odświeżania mogą być unieważniane w dowolnym momencie z różnych powodów. Jedynym sposobem, aby aplikacja wiedziała, czy token odświeżania jest prawidłowy, to próba jego realizacji przez złożenie żądania tokenu do usługi 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 był wcześniej używany 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 autoryzacyjnego z PKCE zawsze mają długość życia tokenu odświeżania wynoszącą 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 usługą Azure AD B2C, wysyłając żądania do tych 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 usługi Azure AD B2C mogą pochodzić z /authorize punktów końcowych lub /token . Kiedy tokeny tożsamości są uzyskiwane z:

• /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 udzielenia implicit flow w rejestracji aplikacji, ponieważ MSAL.js 2.0+ obsługuje przepływ autoryzacji z kodem za pomocą PKCE.
• /token punkt końcowy odbywa się przy użyciu przepływu kodu autoryzacji, który utrzymuje token ukryty przed przeglądarką.

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 Twojej 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 ID nie są zwracane w żadnej określonej kolejności. Nowe roszczenia można wprowadzać w tokenach ID w dowolnym momencie. Aplikacja nie powinna przerywać pracy w miarę wprowadzania nowych żądań. Możesz również uwzględnić niestandardowe atrybuty użytkownika w oświadczeniach.

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.

Konfiguracja

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:

• Okresy istnienia tokenu dostępu i 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. Minimum (włącznie) wynosi 5 minut. Maksymalna wartość (włącznie) wynosi 1440 minut.

• Okres istnienia tokenu odświeżania (dni) — maksymalny okres, przed którym można użyć tokenu odświeżania do uzyskania nowego tokenu dostępu lub tokenu identyfikatora. Okres obejmuje również uzyskanie nowego tokenu odświeżania, jeśli aplikacja uzyskała offline_access zakres. Wartość domyślna to 14 dni. Minimum (włącznie) to jeden dzień. Maksymalna wartość (włącznie) wynosi 90 dni.

• Okres istnienia okna przewijania tokenu odświeżania (dni) — po upływie tego czasu 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 Ograniczony. 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żna podać określonej wartości. Wartość domyślna to 90 dni. Minimum (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 logowanie do aplikacji mobilnej przez czas nieokreślony, o ile użytkownik jest stale aktywny w aplikacji. Okres działania okna przesuwnego tokenu odświeżania (dni) można ustawić na Bez 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 związanych z resetowaniem hasła.

Zgodność

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

• Oświadczenie wystawcy (iss) — ta właściwość identyfikuje dzierżawcę usługi Azure AD B2C, który wystawił token. Wartość domyślna to https://<domain>/{B2C tenant GUID}/v2.0/. Wartość https://<domain>/tfp/{B2C tenant GUID}/{Policy ID}/v2.0/ zawiera 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, aby usługa Azure AD B2C mogła być zgodna 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 zapewniana tylko w celu zapewnienia zgodności z poprzednimi wersjami. Zaleca się przełączenie na ObjectID tak szybko, jak to możliwe.

• Oświadczenie reprezentujące identyfikator zasad — ta właściwość identyfikuje typ oświadczenia, do którego jest wypełniana nazwa zasad używana w żądaniu tokenu. Wartość domyślna to tfp. Wartość parametru acr jest udostępniana tylko w celu zapewnienia zgodności z poprzednimi wersjami.

Przekazywanie

Po rozpoczęciu podróży użytkownika usługa Azure AD B2C odbiera token dostępu od dostawcy tożsamości. Usługa 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. Aby móc korzystać z możliwości przesyłania tokenu jako roszczenia, aplikacja musi używać zalecanego przepływu użytkownika.

Usługa Azure AD B2C obecnie obsługuje tylko przekazywanie tokenu dostępu dostawców tożsamości OAuth 2.0, w tym Facebook i Google. W przypadku 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, dzięki czemu aplikacja może mu ufać. Tokeny usługi Azure AD B2C są podpisane przy użyciu standardowych algorytmów szyfrowania asymetrycznego, takich jak RSA 256.

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

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

Wartość oświadczenia alg to algorytm, który został użyty do podpisania tokenu. Wartość oświadczenia kid jest kluczem publicznym, który został użyty do podpisania tokenu. W dowolnym momencie usługa Azure AD B2C może podpisać token przy użyciu dowolnego zestawu par kluczy publiczny-prywatny. Usługa Azure AD B2C okresowo obraca możliwy zestaw kluczy. Twoja aplikacja powinna być napisana w celu automatycznego obsługiwania 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 być napisana tak, aby ponownie pobierała klucze publiczne, jeśli otrzyma nieoczekiwaną wartość kid.

Usługa Azure AD B2C ma punkt końcowy metadanych OpenID Connect. Korzystając z tego punktu końcowego, aplikacje mogą żądać informacji o usłudze Azure AD B2C w czasie wykonywania. Te informacje obejmują punkty końcowe, zawartość tokenu i klucze podpisywania tokenu. Instancja usługi Azure AD B2C zawiera dokument metadanych JSON dla każdej reguły. Dokument metadanych jest obiektem JSON zawierającym kilka przydatnych informacji. Metadane zawierają jwks_uri, co daje lokalizację zestawu kluczy publicznych używanych do podpisywania tokenów. Ta lokalizacja jest dostępna tutaj, ale najlepiej dynamicznie pobierać 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. Twoja aplikacja może użyć oświadczenia kid w nagłówku JWT, aby wybrać klucz publiczny z dokumentu JSON, który jest używany do podpisywania danego tokenu. Następnie może przeprowadzić walidację podpisu przy użyciu poprawnego klucza publicznego i wskazanego algorytmu.

Dokument metadanych dla polityki 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 zawarta w tfp (domyślnym) lub acr oświadczeniu (zgodnie z konfiguracją) w tokenie. Oświadczenia można analizować z treści JWT przez dekodowanie treści w formacie base-64 i deserializację ciągu JSON, który z tego wynika. Oświadczenie tfp or 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.

Usługa 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żesz programowo przekonwertować wartości n i e na format certyfikatu w celu walidacji tokenu.

Opis sposobu przeprowadzania weryfikacji podpisu znajduje się poza zakresem tego dokumentu. Dostępnych jest wiele bibliotek typu open source, które ułatwiają weryfikację tokenu.

Weryfikowanie oświadczeń

Gdy aplikacje lub interfejs API otrzymują token identyfikatora, powinny również przeprowadzić kilka kontroli w odniesieniu do oświadczeń w tym tokenie. Należy sprawdzić następujące oświadczenia:

• audience — sprawdza, czy token identyfikatora miał być przeznaczony dla Twojej aplikacji.
• nie przed upływem czasu wygaśnięcia — sprawdza, czy token identyfikatora nie wygasł.
• issuer — sprawdza, czy token został wystawiony dla aplikacji przez usługę Azure AD B2C.
• nonce — strategia zapobiegania atakom typu odtwarzania tokenu.

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

Powiązana zawartość

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