Udostępnij za pośrednictwem


Przepływ kodu autoryzacji OAuth 2.0 w usłudze Azure Active Directory B2C

Możesz użyć przyznawania kodu autoryzacji OAuth 2.0 w aplikacjach zainstalowanych na urządzeniu, aby uzyskać dostęp do chronionych zasobów, takich jak internetowe interfejsy API. Korzystając z implementacji protokołu OAuth 2.0 usługi Azure Active Directory B2C (Azure AD B2C), można dodawać zadania rejestracji, logowania i zarządzania tożsamościami do jednostronicowych, mobilnych i klasycznych aplikacji. Ten artykuł jest niezależny od języka. W tym artykule opisano sposób wysyłania i odbierania komunikatów HTTP bez używania bibliotek typu open source. Jeśli to możliwe, zalecamy użycie obsługiwanych bibliotek uwierzytelniania firmy Microsoft (MSAL). Przyjrzyj się przykładowym aplikacjom korzystającym z biblioteki MSAL.

Przepływ kodu autoryzacji OAuth 2.0 został opisany w sekcji 4.1 specyfikacji OAuth 2.0. Można jej używać do uwierzytelniania i autoryzacji w większości typów aplikacji, w tym aplikacji internetowych, aplikacji jednostronicowych i natywnie zainstalowanych aplikacji. Możesz użyć przepływu kodu autoryzacji OAuth 2.0, aby bezpiecznie uzyskać tokeny dostępu i tokeny odświeżania dla aplikacji, które mogą służyć do uzyskiwania dostępu do zasobów zabezpieczonych przez serwer autoryzacji. Token odświeżania umożliwia klientowi uzyskanie nowych tokenów dostępu (i odświeżanie) po wygaśnięciu tokenu dostępu, zazwyczaj po upływie jednej godziny.

Ten artykuł koncentruje się na przepływie kodu autoryzacji OAuth 2.0 dla klientów publicznych . Klient publiczny to każda aplikacja kliencka, której nie można ufać, aby bezpiecznie zachować integralność tajnego hasła. Dotyczy to aplikacji jednostronicowych, aplikacji mobilnych, aplikacji klasycznych i zasadniczo wszystkich aplikacji, które nie są uruchamiane na serwerze.

Uwaga

Aby dodać zarządzanie tożsamościami do aplikacji internetowej przy użyciu Azure AD B2C, użyj protokołu OpenID Connect zamiast protokołu OAuth 2.0.

Azure AD B2C rozszerza standardowe przepływy OAuth 2.0, aby wykonywać więcej niż proste uwierzytelnianie i autoryzację. Wprowadza on przepływ użytkownika. Za pomocą przepływów użytkowników możesz użyć protokołu OAuth 2.0, aby dodać środowiska użytkownika do aplikacji, takie jak rejestrowanie, logowanie i zarządzanie profilami. Dostawcy tożsamości korzystający z protokołu OAuth 2.0 to Amazon, Microsoft Entra ID, Facebook, GitHub, Google i LinkedIn.

Aby wypróbować żądania HTTP w tym artykule:

  1. Zastąp {tenant} ciąg nazwą dzierżawy usługi Azure AD B2C.
  2. Zastąp 90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 element identyfikatorem aplikacji, która została wcześniej zarejestrowana w dzierżawie usługi Azure AD B2C.
  3. Zastąp {policy} ciąg nazwą zasad utworzonych w dzierżawie, na przykład b2c_1_sign_in.

Konfiguracja identyfikatora URI przekierowania wymagana dla aplikacji jednostronicowych

Przepływ kodu autoryzacji dla aplikacji jednostronicowych wymaga dodatkowej konfiguracji. Postępuj zgodnie z instrukcjami dotyczącymi tworzenia aplikacji jednostronicowej , aby poprawnie oznaczyć identyfikator URI przekierowania jako włączony dla mechanizmu CORS. Aby zaktualizować istniejący identyfikator URI przekierowania w celu włączenia mechanizmu CORS, możesz kliknąć monit migracji w sekcji "Internet" na karcie Uwierzytelnianierejestracji aplikacji. Alternatywnie możesz otworzyć edytor manifestu Rejestracje aplikacji i ustawić type pole identyfikatora URI przekierowania na spa w replyUrlsWithType sekcji .

spa Typ przekierowania jest do tyłu zgodny z niejawnym przepływem. Aplikacje korzystające obecnie z niejawnego przepływu do uzyskiwania tokenów mogą przechodzić do spa typu identyfikatora URI przekierowania bez problemów i nadal korzystać z niejawnego przepływu.

1. Pobieranie kodu autoryzacji

Przepływ kodu autoryzacji rozpoczyna się od klienta kierującego użytkownika do punktu końcowego /authorize . Jest to interaktywna część przepływu, w której użytkownik podejmuje działania. W tym żądaniu klient wskazuje w parametrze scope uprawnienia, które musi uzyskać od użytkownika. W poniższych przykładach (z podziałami wierszy dla czytelności) pokazano, jak uzyskać kod autoryzacji. Jeśli testujesz to żądanie HTTP GET, użyj przeglądarki.

GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&response_type=code
&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob
&response_mode=query
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6%20offline_access%20https://{tenant-name}/{app-id-uri}/{scope}
&state=arbitrary_data_you_can_receive_in_the_response
&code_challenge=YTFjNjI1OWYzMzA3MTI4ZDY2Njg5M2RkNmVjNDE5YmEyZGRhOGYyM2IzNjdmZWFhMTQ1ODg3NDcxY2Nl
&code_challenge_method=S256
Parametr Wymagane? Opis
{tenant} Wymagane Nazwa dzierżawy usługi Azure AD B2C
{policy} Wymagane Przepływ użytkownika do uruchomienia. Określ nazwę przepływu użytkownika utworzonego w dzierżawie usługi Azure AD B2C. Na przykład: b2c_1_sign_in, b2c_1_sign_uplub b2c_1_edit_profile.
client_id Wymagane Identyfikator aplikacji przypisany do aplikacji w Azure Portal.
response_type Wymagane Typ odpowiedzi, który musi zawierać code przepływ kodu autoryzacji. Jeśli uwzględnisz go w typie odpowiedzi, takim jak code+id_token, możesz otrzymać token identyfikatora, a w tym przypadku zakres musi zawierać wartość openid.
redirect_uri Wymagane Identyfikator URI przekierowania aplikacji, w którym odpowiedzi uwierzytelniania są wysyłane i odbierane przez aplikację. Musi dokładnie odpowiadać jednemu z identyfikatorów URI przekierowania zarejestrowanych w portalu, z tą różnicą, że musi być zakodowana w adresie URL.
scope Wymagane Rozdzielona spacjami lista zakresów. Zakres openid wskazuje uprawnienia do logowania użytkownika i pobierania danych o użytkowniku w postaci tokenów identyfikatorów. Zakres offline_access jest opcjonalny dla aplikacji internetowych. Wskazuje, że aplikacja będzie potrzebować tokenu odświeżania w celu uzyskania rozszerzonego dostępu do zasobów. Identyfikator klienta wskazuje, że wystawiony token jest przeznaczony do użycia przez Azure AD zarejestrowanego klienta B2C. Element https://{tenant-name}/{app-id-uri}/{scope} wskazuje uprawnienia do chronionych zasobów, takich jak internetowy interfejs API. Aby uzyskać więcej informacji, zobacz Żądanie tokenu dostępu.
response_mode Zalecane Metoda używana do wysyłania wynikowego kodu autoryzacji z powrotem do aplikacji. Może to być query, form_postlub fragment.
stan Zalecane Wartość uwzględniona w żądaniu, która może być ciągiem dowolnej zawartości, której chcesz użyć. Zazwyczaj jest używana losowo wygenerowana unikatowa wartość, aby zapobiec atakom fałszowania żądań między witrynami. Stan jest również używany do kodowania informacji o stanie użytkownika w aplikacji przed wystąpieniem żądania uwierzytelnienia. Na przykład strona, na którą znajdował się użytkownik, lub przepływ użytkownika, który był wykonywany.
Wierszu Opcjonalne Wymagany typ interakcji użytkownika. Obecnie jedyną prawidłową wartością jest login, która wymusza na użytkowniku wprowadzenie poświadczeń w ramach tego żądania. Logowanie jednokrotne nie zacznie obowiązywać.
code_challenge zalecane/wymagane Służy do zabezpieczania udzielania kodu autoryzacji za pośrednictwem klucza dowodowego dla wymiany kodu (PKCE). Wymagane, jeśli code_challenge_method jest uwzględniona. Aby wygenerować elementy code_verifier i , code_challengenależy dodać logikę w aplikacji. Jest code_challenge to skrót SHA256 zakodowany w formacie Base64 w formacie URL .code_verifier Przechowujesz element code_verifier w aplikacji do późniejszego użycia i wysyłasz code_challenge element wraz z żądaniem autoryzacji. Aby uzyskać więcej informacji, zobacz dokument RFC PKCE. Jest to teraz zalecane dla wszystkich typów aplikacji — natywnych aplikacji, spA i poufnych klientów, takich jak aplikacje internetowe.
code_challenge_method zalecane/wymagane Metoda używana do kodowania code_verifier parametru code_challenge . Powinna to być S256wartość , ale specyfikację można używaćplain, jeśli z jakiegoś powodu klient nie może obsługiwać algorytmu SHA256.

Jeśli wykluczysz element code_challenge_method, ale nadal zawiera code_challengewartość , przyjmuje się, code_challenge że jest to zwykły tekst. Platforma tożsamości Microsoft obsługuje zarówno elementy , jak plain i S256. Aby uzyskać więcej informacji, zobacz dokument RFC PKCE. Jest to wymagane w przypadku aplikacji jednostronicowych korzystających z przepływu kodu autoryzacji.
login_hint Nie Może służyć do wstępnego wypełniania pola nazwy logowania na stronie logowania. Aby uzyskać więcej informacji, zobacz Wstępne wypełnianie nazwy logowania.
domain_hint Nie Zawiera wskazówkę dotyczącą Azure AD B2C o dostawcy tożsamości społecznościowych, który powinien być używany do logowania. Jeśli zostanie dołączona prawidłowa wartość, użytkownik przejdzie bezpośrednio do strony logowania dostawcy tożsamości. Aby uzyskać więcej informacji, zobacz Przekierowywanie logowania do dostawcy społecznościowego.
Parametry niestandardowe Nie Parametry niestandardowe, których można używać z zasadami niestandardowymi. Na przykład dynamiczne identyfikatory URI zawartości niestandardowej strony lub rozpoznawanie oświadczeń klucz-wartość.

Na tym etapie użytkownik jest proszony o ukończenie przepływu pracy przepływu użytkownika. Może to obejmować wprowadzenie nazwy użytkownika i hasła, zalogowanie się przy użyciu tożsamości społecznościowej, zarejestrowanie się w katalogu lub dowolną inną liczbę kroków. Akcje użytkownika zależą od sposobu definiowania przepływu użytkownika.

Po zakończeniu przepływu użytkownika Microsoft Entra identyfikator zwraca odpowiedź do aplikacji z wartością użytą dla redirect_urielementu . Używa metody określonej w parametrze response_mode . Odpowiedź jest dokładnie taka sama dla każdego scenariusza akcji użytkownika niezależnie od wykonanego przepływu użytkownika.

Pomyślna odpowiedź, która używa response_mode=query , wygląda następująco:

GET urn:ietf:wg:oauth:2.0:oob?
code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...        // the authorization_code, truncated
&state=arbitrary_data_you_can_receive_in_the_response                // the value provided in the request
Parametr Opis
kod Kod autoryzacji żądany przez aplikację. Aplikacja może użyć kodu autoryzacji, aby zażądać tokenu dostępu dla zasobu docelowego. Kody autoryzacji są bardzo krótkotrwałe. Zazwyczaj wygasają po około 10 minutach.
stan Zobacz pełny opis w tabeli w poprzedniej sekcji. state Jeśli parametr jest uwzględniony w żądaniu, ta sama wartość powinna pojawić się w odpowiedzi. Aplikacja powinna sprawdzić, czy state wartości w żądaniu i odpowiedzi są identyczne.

Odpowiedzi na błędy można również wysłać do identyfikatora URI przekierowania, aby aplikacja mogła je odpowiednio obsłużyć:

GET urn:ietf:wg:oauth:2.0:oob?
error=access_denied
&error_description=The+user+has+cancelled+entering+self-asserted+information
&state=arbitrary_data_you_can_receive_in_the_response
Parametr Opis
error Ciąg kodu błędu, którego można użyć do klasyfikowania typów błędów, które występują. Możesz również użyć ciągu, aby reagować na błędy.
error_description Określony komunikat o błędzie, który może pomóc zidentyfikować główną przyczynę błędu uwierzytelniania.
stan Zobacz pełny opis w poprzedniej tabeli. state Jeśli parametr jest uwzględniony w żądaniu, ta sama wartość powinna pojawić się w odpowiedzi. Aplikacja powinna sprawdzić, czy state wartości w żądaniu i odpowiedzi są identyczne.

2. Uzyskiwanie tokenu dostępu

Teraz, po uzyskaniu kodu autoryzacji, możesz wymienić code token na zamierzony zasób, wysyłając żądanie POST do punktu końcowego /token . W Azure AD B2C można żądać tokenów dostępu dla innych interfejsów API w zwykły sposób, określając ich zakresy w żądaniu.

Możesz również zażądać tokenu dostępu dla własnego internetowego interfejsu API zaplecza aplikacji zgodnie z konwencją użycia identyfikatora klienta aplikacji jako żądanego zakresu (co spowoduje token dostępu z tym identyfikatorem klienta jako "odbiorcy"):

POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1

Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
&code_verifier=ThisIsntRandomButItNeedsToBe43CharactersLong 
Parametr Wymagane? Opis
{tenant} Wymagane Nazwa dzierżawy usługi Azure AD B2C
{policy} Wymagane Przepływ użytkownika, który został użyty do uzyskania kodu autoryzacji. W tym żądaniu nie można użyć innego przepływu użytkownika.
client_id Wymagane Identyfikator aplikacji przypisany do aplikacji w Azure Portal.
client_secret Tak, w Web Apps Wpis tajny aplikacji wygenerowany w Azure Portal. Wpisy tajne klienta są używane w tym przepływie w scenariuszach aplikacji internetowej, w których klient może bezpiecznie przechowywać klucz tajny klienta. W przypadku scenariuszy aplikacji natywnej (klienta publicznego) wpisy tajne klienta nie mogą być bezpiecznie przechowywane i dlatego nie są używane w tym wywołaniu. Jeśli używasz klucza tajnego klienta, zmień go okresowo.
grant_type Wymagane Typ udzielenia. W przypadku przepływu kodu autoryzacji typ udzielenia musi mieć wartość authorization_code.
scope Zalecane Rozdzielona spacjami lista zakresów. Pojedyncza wartość zakresu wskazuje Microsoft Entra identyfikatora obu żądanych uprawnień. Użycie identyfikatora klienta jako zakresu 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. Zakres offline_access wskazuje, że aplikacja potrzebuje tokenu odświeżania na potrzeby długotrwałego dostępu do zasobów. Możesz również użyć openid zakresu, aby zażądać tokenu identyfikatora z Azure AD B2C.
kod Wymagane Kod autoryzacji uzyskany z punktu końcowego /authorize .
redirect_uri Wymagane Identyfikator URI przekierowania aplikacji, w której odebrano kod autoryzacji.
code_verifier zalecane To samo code_verifier , które zostało użyte do uzyskania kodu autoryzacji. Wymagane, jeśli klucz PKCE został użyty w żądaniu udzielenia kodu autoryzacji. Aby uzyskać więcej informacji, zobacz dokument RFC PKCE.

Jeśli testujesz 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:

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
    "expires_in": "3600",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}
Parametr Opis
not_before Czas, w którym token jest uznawany za prawidłowy, w czasie epoki.
token_type Wartość typu tokenu. Jedynym typem obsługującym identyfikator Microsoft Entra jest Bearer.
access_token Podpisany token internetowy JSON (JWT), którego zażądano.
scope Zakresy, dla których token jest prawidłowy. Można również użyć zakresów do buforowania tokenów do późniejszego użycia.
expires_in Czas ważności tokenu (w sekundach).
refresh_token Token odświeżania OAuth 2.0. Aplikacja może użyć tego tokenu do uzyskania dodatkowych tokenów po wygaśnięciu bieżącego tokenu. Tokeny odświeżania są długotrwałe. Można ich użyć do zachowania dostępu do zasobów przez dłuższy czas. Aby uzyskać więcej informacji, zobacz dokumentację tokenu usługi Azure AD B2C.

Odpowiedzi na błędy wyglądają następująco:

{
    "error": "access_denied",
    "error_description": "The user revoked access to the app.",
}
Parametr Opis
error Ciąg kodu błędu, którego można użyć do klasyfikowania typów błędów, które występują. Możesz również użyć ciągu, aby reagować na błędy.
error_description Określony komunikat o błędzie, który może pomóc zidentyfikować główną przyczynę błędu uwierzytelniania.

3. Użyj tokenu

Po pomyślnym uzyskaniu tokenu dostępu możesz użyć tokenu w żądaniach do internetowych interfejsów API zaplecza, dołączając go do nagłówka Authorization :

GET /tasks
Host: mytaskwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...

4. Odśwież token

Tokeny dostępu i tokeny identyfikatorów są krótkotrwałe. Po wygaśnięciu należy je odświeżyć, aby nadal uzyskiwać dostęp do zasobów. Podczas odświeżania tokenu dostępu Azure AD B2C zwraca nowy token. Odświeżony token dostępu zostanie zaktualizowany nbf (nie wcześniej), iat (wystawiony pod adresem) i exp (wygaśnięcie) wartości oświadczeń. Wszystkie inne wartości oświadczeń będą takie same jak pierwotnie wystawiony token dostępu.

Aby odświeżyć token, prześlij kolejne żądanie POST do punktu końcowego /token . Tym razem podaj wartość refresh_token zamiast parametru code:

POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1

Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
Parametr Wymagane? Opis
{tenant} Wymagane Nazwa dzierżawy usługi Azure AD B2C
{policy} Wymagane Przepływ użytkownika, który został użyty do uzyskania oryginalnego tokenu odświeżania. W tym żądaniu nie można użyć innego przepływu użytkownika.
client_id Wymagane Identyfikator aplikacji przypisany do aplikacji w Azure Portal.
client_secret Tak, w Web Apps Wpis tajny aplikacji wygenerowany w Azure Portal. Wpisy tajne klienta są używane w tym przepływie w scenariuszach aplikacji internetowej, w których klient może bezpiecznie przechowywać klucz tajny klienta. W przypadku scenariuszy aplikacji natywnej (klienta publicznego) wpisy tajne klienta nie mogą być bezpiecznie przechowywane i dlatego nie są używane w tym wywołaniu. Jeśli używasz klucza tajnego klienta, zmień go okresowo.
grant_type Wymagane Typ udzielenia. W przypadku tego etapu przepływu kodu autoryzacji typ udzielenia musi mieć wartość refresh_token.
scope Zalecane Rozdzielona spacjami lista zakresów. Pojedyncza wartość zakresu wskazuje Microsoft Entra identyfikatora obu żądanych uprawnień. Użycie identyfikatora klienta jako zakresu 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. Zakres offline_access wskazuje, że aplikacja będzie potrzebować tokenu odświeżania na potrzeby długotrwałego dostępu do zasobów. Możesz również użyć openid zakresu, aby zażądać tokenu identyfikatora z Azure AD B2C.
redirect_uri Opcjonalne Identyfikator URI przekierowania aplikacji, w której odebrano kod autoryzacji.
refresh_token Wymagane Oryginalny token odświeżania uzyskany w drugim etapie przepływu.

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

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
    "expires_in": "3600",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}
Parametr Opis
not_before Czas, w którym token jest uznawany za prawidłowy, w czasie epoki.
token_type Wartość typu tokenu. Jedynym typem obsługującym identyfikator Microsoft Entra jest Bearer.
access_token Podpisany zestaw JWT, którego zażądano.
scope Zakresy, dla których token jest prawidłowy. Można również użyć zakresów do buforowania tokenów do późniejszego użycia.
expires_in Czas ważności tokenu (w sekundach).
refresh_token Token odświeżania OAuth 2.0. Aplikacja może użyć tego tokenu do uzyskania dodatkowych tokenów po wygaśnięciu bieżącego tokenu. Tokeny odświeżania są długotrwałe i mogą służyć do zachowania dostępu do zasobów przez dłuższy czas. Aby uzyskać więcej informacji, zobacz dokumentację tokenu usługi Azure AD B2C.

Odpowiedzi na błędy wyglądają następująco:

{
    "error": "access_denied",
    "error_description": "The user revoked access to the app.",
}
Parametr Opis
error Ciąg kodu błędu, którego można użyć do klasyfikowania typów błędów, które występują. Możesz również użyć ciągu, aby reagować na błędy.
error_description Określony komunikat o błędzie, który może pomóc zidentyfikować główną przyczynę błędu uwierzytelniania.

Korzystanie z własnego katalogu Azure AD B2C

Aby samodzielnie wypróbować te żądania, wykonaj następujące kroki. Zastąp przykładowe wartości użyte w tym artykule własnymi wartościami.

  1. Utwórz katalog Azure AD B2C. Użyj nazwy katalogu w żądaniach.
  2. Utwórz aplikację w celu uzyskania identyfikatora aplikacji i identyfikatora URI przekierowania. Uwzględnij klienta natywnego w aplikacji.
  3. Utwórz przepływy użytkownika , aby uzyskać nazwy przepływów użytkownika.