Udostępnij za pośrednictwem

Żądanie tokenu dostępu w usłudze Azure Active Directory B2C

Ważne

Od 1 maja 2025 r. usługa Azure AD B2C nie będzie już dostępna do zakupu dla nowych klientów. Dowiedz się więcej w naszych często zadawanych pytaniach.

Token dostępu zawiera oświadczenia, których można użyć w usłudze Azure Active Directory B2C (Azure AD B2C), aby zidentyfikować przyznane uprawnienia do interfejsów API. Aby wywołać serwer zasobów, żądanie HTTP musi zawierać token dostępu. Token dostępu jest oznaczony jako access_token w odpowiedziach z usługi Azure AD B2C.

W tym artykule pokazano, jak zażądać tokenu dostępu dla aplikacji internetowej i internetowego interfejsu API. Aby uzyskać więcej informacji na temat tokenów w usłudze Azure AD B2C, zobacz omówienie tokenów w usłudze Azure Active Directory B2C.

Uwaga / Notatka

Łańcuchy interfejsów API (on-Behalf-Of) nie są obsługiwane przez Azure AD B2C — wiele architektur obejmuje interfejs API, który musi wywołać inny podrzędny interfejs API, oba zabezpieczone przez Azure AD B2C. Typowy scenariusz w przypadku klientów, którzy mają backend API, który wywołuje inną usługę. Ten scenariusz łańcuchowego web API może być obsługiwany przy użyciu mechanizmu nadania poświadczeń JWT Bearer OAuth 2.0, znanego również jako przepływ On-Behalf-Of. Jednak przepływ On-Behalf-Of nie jest implementowany obecnie w usłudze Azure AD B2C. Mimo żeBehalf-Of funkcjonuje w przypadku aplikacji zarejestrowanych w usłudze Microsoft Entra ID, nie funkcjonuje w przypadku aplikacji zarejestrowanych w usłudze Azure AD B2C, niezależnie od dzierżawcy (Microsoft Entra ID lub Azure AD B2C), który wystawia tokeny.

Wymagania wstępne

Zakresy

Zakresy umożliwiają zarządzanie uprawnieniami do chronionych zasobów. Po zażądaniu tokenu dostępu aplikacja kliencka musi określić żądane uprawnienia w parametrze zakresu żądania. Aby na przykład określić wartość zakresuread dla interfejsu API, który ma Identyfikator aplikacji URIhttps://contoso.onmicrosoft.com/api, zakres to https://contoso.onmicrosoft.com/api/read.

Zakresy są używane w internetowym interfejsie API do realizacji kontroli dostępu opartej na zakresie. Na przykład użytkownicy internetowego interfejsu API mogą mieć zarówno dostęp do odczytu, jak i zapisu, lub użytkownicy internetowego interfejsu API mogą mieć tylko dostęp do odczytu. Aby uzyskać wiele uprawnień w tym samym żądaniu, możesz dodać wiele wpisów w pojedynczym parametrze zakresu żądania, oddzielonych spacjami.

W poniższym przykładzie przedstawiono zakresy dekodowane w adresie URL:

scope=https://contoso.onmicrosoft.com/api/read openid offline_access

W poniższym przykładzie pokazano zakresy zakodowane w adresie URL:

scope=https%3A%2F%2Fcontoso.onmicrosoft.com%2Fapi%2Fread%20openid%20offline_access

Jeśli żądasz szerszego zakresu niż przyznany dla aplikacji klienckiej, wywołanie powiedzie się, jeśli zostanie przyznane co najmniej jedno uprawnienie. Klamra scp w wynikowym tokenie dostępu jest wypełniana wyłącznie uprawnieniami, które zostały pomyślnie przyznane.

Zakresy OpenID Connect

Standard OpenID Connect określa kilka specjalnych wartości zakresu. Następujące zakresy reprezentują uprawnienie dostępu do profilu użytkownika:

  • openid — żąda tokenu identyfikatora.
  • offline_access — żąda tokenu odświeżania przy użyciu przepływów kodu uwierzytelniania.
  • 00000000-0000-0000-0000-0000000000000 — użyj identyfikatora klienta, ponieważ zakres wskazuje, że aplikacja potrzebuje tokenu dostępu, który może być używany względem własnej usługi lub internetowego interfejsu API reprezentowanego przez ten sam identyfikator klienta.

Jeśli parametr response_type w żądaniu /authorize zawiera token, parametr scope musi zawierać co najmniej jeden zakres zasobów inny niż openid i offline_access, który zostanie udzielony. W przeciwnym razie, żądanie /authorize kończy się niepowodzeniem.

Żądanie tokenu

Aby zażądać tokenu dostępu, potrzebny jest kod autoryzacji. Poniżej przedstawiono przykład żądania do /authorize punktu końcowego dla kodu autoryzacji:

GET https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/authorize?
client_id=<application-ID>
&nonce=anyRandomValue
&redirect_uri=https://jwt.ms
&scope=<application-ID-URI>/<scope-name>
&response_type=code

Zastąp wartości w ciągu zapytania w następujący sposób:

  • <tenant-name> — nazwa Twojego tenantu Azure AD B2C. Jeśli używasz domeny niestandardowej, zastąp ciąg tenant-name.b2clogin.com domeną, taką jak contoso.com.
  • <policy-name> — Nazwa niestandardowych zasad lub przepływu użytkownika.
  • <application-ID> — identyfikator aplikacji internetowej zarejestrowanej w celu obsługi przepływu użytkownika.
  • <application-ID-URI> — Identyfikator URI aplikacji ustawiony w panelu Ujawnij interfejs API aplikacji klienckiej.
  • <scope-name> — Nazwa zakresu dodanego w sekcji Udostępnij interfejs API aplikacji klienckiej.
  • <redirect-uri> — Identyfikator URI przekierowania wprowadzony podczas rejestrowania aplikacji klienckiej.

Aby dowiedzieć się, jak działa żądanie, wklej żądanie w przeglądarce i uruchom je.

Jest to interaktywna część przepływu, w której podejmujesz działania. Poproszono Cię o ukończenie procesu przepływu użytkownika. Może to obejmować wprowadzenie nazwy użytkownika i hasła w formularzu logowania lub dowolnej innej liczbie kroków. Ukończone kroki zależą od sposobu definiowania przepływu użytkownika.

Odpowiedź z kodem autoryzacji powinna być podobna do tego przykładu:

https://jwt.ms/?code=eyJraWQiOiJjcGltY29yZV8wOTI1MjAxNSIsInZlciI6IjEuMC...

Po pomyślnym otrzymaniu kodu autoryzacji można go użyć do żądania tokenu dostępu. Parametry znajdują się w treści żądania HTTP POST:

POST <tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/token HTTP/1.1
Host: <tenant-name>.b2clogin.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&client_id=<application-ID>
&scope=<application-ID-URI>/<scope-name>
&code=eyJraWQiOiJjcGltY29yZV8wOTI1MjAxNSIsInZlciI6IjEuMC...
&redirect_uri=https://jwt.ms
&client_secret=2hMG2-_:y12n10vwH...

Jeśli chcesz przetestować to żądanie HTTP POST, możesz użyć dowolnego klienta HTTP, takiego jak Microsoft PowerShell.

Pomyślna odpowiedź tokenu wygląda następująco:

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ilg1ZVhrN...",
    "token_type": "Bearer",
    "not_before": 1549647431,
    "expires_in": 3600,
    "expires_on": 1549651031,
    "resource": "f2a76e08-93f2-4350-833c-965c02483b11",
    "profile_info": "eyJ2ZXIiOiIxLjAiLCJ0aWQiOiJjNjRhNGY3ZC0zMDkxLTRjNzMtYTcyMi1hM2YwNjk0Z..."
}

Jeśli używasz https://jwt.ms metody do zbadania zwróconego tokenu dostępu, powinien zostać wyświetlony komunikat podobny do poniższego przykładu:

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "X5eXk4xyojNFum1kl2Ytv8dl..."
}.{
  "iss": "https://contoso0926tenant.b2clogin.com/c64a4f7d-3091-4c73-a7.../v2.0/",
  "exp": 1549651031,
  "nbf": 1549647431,
  "aud": "f2a76e08-93f2-4350-833c-965...",
  "oid": "1558f87f-452b-4757-bcd1-883...",
  "sub": "1558f87f-452b-4757-bcd1-883...",
  "name": "David",
  "tfp": "B2C_1_signupsignin1",
  "nonce": "anyRandomValue",
  "scp": "read",
  "azp": "38307aee-303c-4fff-8087-d8d2...",
  "ver": "1.0",
  "iat": 1549647431
}.[Signature]

Dalsze kroki