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

  • Artykuł

Token dostępu zawiera oświadczenia, których można używać w usłudze Azure Active Directory B2C (Azure AD B2C) do identyfikowania uprawnień przyznanych interfejsom API. Aby wywołać serwer zasobów, żądanie HTTP musi zawierać token dostępu. Token dostępu jest oznaczany 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

Sieci Web API (On-Behalf-Of) nie są obsługiwane przez Azure AD B2C — wiele architektur obejmuje internetowy interfejs API, który musi wywoływać inny podrzędny internetowy interfejs API, zarówno zabezpieczony przez Azure AD B2C. Ten scenariusz jest typowy w przypadku klientów mających zaplecze w postaci internetowego interfejsu API, które z kolei wywołuje inną usługę. Ten scenariusz obejmujący łańcuch internetowych interfejsów API może być obsługiwany przy użyciu przyznania poświadczeń elementu nośnego OAuth 2.0 JWT, określanego również jako przepływ On-Behalf-Of. Jednak przepływ On-Behalf-Of nie jest obecnie zaimplementowany w usłudze Azure AD B2C. Mimo że funkcja On-Behalf-Of działa dla aplikacji zarejestrowanych w identyfikatorze Microsoft Entra, nie działa w przypadku aplikacji zarejestrowanych w usłudze Azure AD B2C, niezależnie od dzierżawy (identyfikator Microsoft Entra lub Azure AD B2C), które 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 scope żądania. Aby na przykład określić Wartość zakresuread dla interfejsu API, który ma Identyfikator URI identyfikatora aplikacjihttps://contoso.onmicrosoft.com/api, zakres to https://contoso.onmicrosoft.com/api/read.

Zakresy są używane przez internetowy interfejs API w celu implementowania kontroli dostępu opartej na zakresach. Na przykład użytkownicy internetowego interfejsu API mogą mieć dostęp zarówno do odczytu, jak i zapisu lub tylko dostęp do odczytu. Aby uzyskać wiele uprawnień w tym samym żądaniu, możesz dodać wiele rozdzielonych spacjami wpisów w pojedynczym parametrze scope żądania.

Poniższy przykład przedstawia zakresy zdekodowane w adresie URL:

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

Poniższy przykład przedstawia zakresy zakodowane w adresie URL:

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

Jeśli zażądasz więcej zakresów niż przyznano aplikacji klienckiej, wywołanie zakończy się powodzeniem w przypadku przyznania co najmniej jednego uprawnienia. Oświadczenie scp w wynikowym tokenie dostępu zostanie wypełnione tylko uprawnieniami, które zostały pomyślnie przyznane.

Zakresy openID Connect

Standard OpenID Connect określa kilka specjalnych wartości zakresów. 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-000000000000 — 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 element token, parametr scope musi zawierać co najmniej jeden zakres zasobów inny niż openid i offline_access, który zostanie przyznany. W przeciwnym razie żądanie /authorize zakończy się niepowodzeniem.

Żądanie tokenu

Aby zażądać tokenu dostępu, musisz mieć kod autoryzacji. Poniżej przedstawiono przykład żądania do punktu końcowego /authorize 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 dzierżawy usługi Azure AD B2C. Jeśli używasz domeny niestandardowej, zastąp ciąg tenant-name.b2clogin.com domeną, na przykład contoso.com.
  • <policy-name> — nazwa zasad niestandardowych lub przepływu użytkownika.
  • <application-ID> — identyfikator aplikacji internetowej, która została zarejestrowana w celu obsługi przepływu użytkownika.
  • <application-ID-URI> — Identyfikator URI identyfikatora aplikacji ustawiony w obszarze Uwidacznij blok interfejsu API aplikacji klienckiej.
  • <scope-name> — Nazwa zakresu, który został dodany w obszarze Uwidacznij blok interfejsu 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. Zostanie wyświetlony monit o ukończenie przepływu pracy 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 następującego 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 lub Postman.

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..."
}

Po zbadaniu zwróconego tokenu dostępu w witrynie https://jwt.ms powinny zostać wyświetlone dane podobne do następującego 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]

Następne kroki