Bagikan melalui


Alur kode otorisasi OAuth 2.0 di Azure Active Directory B2C

Penting

Berlaku mulai 1 Mei 2025, Azure AD B2C tidak akan lagi tersedia untuk dibeli untuk pelanggan baru. Pelajari lebih lanjut di FAQ kami.

Anda dapat menggunakan pemberian kode otorisasi OAuth 2.0 di aplikasi yang diinstal pada perangkat untuk mendapatkan akses ke sumber daya yang dilindungi, seperti API web. Dengan menggunakan implementasi Azure Active Directory B2C (Azure AD B2C) dari OAuth 2.0, Anda dapat menambahkan tugas pendaftaran, masuk, dan manajemen identitas lainnya ke aplikasi satu halaman, seluler, dan desktop Anda. Dalam artikel ini, kami menjelaskan cara mengirim dan menerima pesan HTTP tanpa menggunakan pustaka sumber terbuka apa pun. Artikel ini tidak bergantung pada bahasa. Jika memungkinkan, kami sarankan Anda menggunakan Microsoft Authentication Libraries (MSAL) yang didukung. Lihat contoh aplikasi yang menggunakan MSAL.

Alur kode otorisasi OAuth 2.0 dijelaskan dalam bagian 4.1 dari spesifikasi OAuth 2.0. Anda dapat menggunakannya untuk autentikasi dan otorisasi di sebagian besar jenis aplikasi, termasuk aplikasi web, aplikasi satu halaman, dan aplikasi yang diinstal secara asli. Anda dapat menggunakan alur kode otorisasi OAuth 2.0 untuk memperoleh token akses dan token refresh untuk aplikasi Anda dengan aman, yang dapat digunakan untuk mengakses sumber daya yang diamankan oleh server otorisasi. Token refresh memungkinkan klien untuk memperoleh token akses baru (dan refresh) setelah token akses kedaluwarsa, biasanya setelah satu jam.

Artikel ini berfokus pada alur kode otorisasi OAuth 2.0 klien publik . Klien publik adalah aplikasi klien apa pun yang tidak dapat dipercaya untuk mempertahankan integritas kata sandi rahasia dengan aman. Ini termasuk aplikasi satu halaman, aplikasi seluler, aplikasi desktop, dan pada dasarnya aplikasi apa pun yang tidak berjalan di server.

Nota

Untuk menambahkan manajemen identitas ke aplikasi web dengan menggunakan Azure AD B2C, gunakan OpenID Connect alih-alih OAuth 2.0.

Azure AD B2C memperluas alur OAuth 2.0 standar untuk melakukan lebih dari autentikasi dan otorisasi sederhana. Ini memperkenalkan alur pengguna. Dengan alur pengguna, Anda dapat menggunakan OAuth 2.0 untuk menambahkan pengalaman pengguna ke aplikasi Anda, seperti pendaftaran, masuk, dan manajemen profil. Penyedia identitas yang menggunakan protokol OAuth 2.0 termasuk Amazon, ID Microsoft Entra, Facebook, GitHub, Google, dan LinkedIn.

Untuk mencoba permintaan HTTP dalam artikel ini:

  1. Ganti {tenant} dengan nama penyewa Azure AD B2C Anda.
  2. Ganti 00001111-aaaa-2222-bbbb-3333cccc4444 dengan ID aplikasi aplikasi yang sebelumnya telah Anda daftarkan di penyewa Azure AD B2C Anda.
  3. Ganti {policy} dengan nama kebijakan yang telah Anda buat di penyewa Anda, misalnya b2c_1_sign_in.

Penyiapan URI Pengalihan diperlukan untuk aplikasi halaman tunggal

Alur kode otorisasi untuk aplikasi halaman tunggal memerlukan beberapa penyiapan tambahan. Ikuti petunjuk untuk membangun aplikasi satu halaman Anda agar URI pengalihan Anda diaktifkan dengan benar untuk CORS. Untuk memperbarui URI pengalihan yang ada untuk mengaktifkan CORS, Anda dapat mengklik perintah migrasi di bagian "Web" pada tab Autentikasipendaftaran aplikasi. Atau, Anda dapat membuka editor manifes Pendaftaran aplikasi dan mengatur type bidang untuk URI pengalihan Anda ke spa di bagian .replyUrlsWithType

Jenis pengalihan spa kompatibel ke belakang dengan alur implisit. Aplikasi yang saat ini menggunakan alur implisit untuk mendapatkan token dapat berpindah ke jenis URI pengalihan spa tanpa masalah dan terus menggunakan alur implisit.

1. Dapatkan kode otorisasi

Alur kode otorisasi dimulai dengan klien mengarahkan pengguna ke titik akhir /authorize. Ini adalah bagian interaktif dari alur, di mana pengguna mengambil tindakan. Dalam permintaan ini, klien menunjukkan dalam scope parameter izin yang perlu diperoleh dari pengguna. Contoh berikut (dengan hentian baris untuk keterbacaan) menunjukkan cara memperoleh kode otorisasi. Jika Anda menguji permintaan HTTP GET ini, gunakan browser Anda.

GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=code
&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob
&response_mode=query
&scope=00001111-aaaa-2222-bbbb-3333cccc4444%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
Pengaturan Diperlukan? Deskripsi
{penyewa} Diperlukan Nama penyewa Azure AD B2C Anda
{kebijakan} Diperlukan Alur pengguna yang akan dijalankan. Tentukan nama alur pengguna yang telah Anda buat di penyewa Azure AD B2C Anda. Misalnya: b2c_1_sign_in, b2c_1_sign_up, atau b2c_1_edit_profile.
ID klien Diperlukan ID aplikasi yang ditetapkan ke aplikasi Anda di portal Microsoft Azure.
jenis_respons Diperlukan Jenis respons, yang harus disertakan code untuk alur kode otorisasi. Anda dapat menerima token ID jika Anda menyertakannya dalam jenis respons, seperti code+id_token, dan dalam hal ini, cakupan perlu menyertakan openid.
alamat_pengalihan Diperlukan URI pengalihan aplikasi Anda, tempat respons autentikasi dikirim dan diterima oleh aplikasi Anda. Ini harus sama persis dengan salah satu URI pengalihan yang Anda daftarkan di portal, kecuali bahwa itu harus dikodekan URL.
ruang lingkup Diperlukan Daftar cakupan yang dipisahkan oleh spasi. cakupan openid menunjukkan izin untuk masuk ke pengguna dan mendapatkan data tentang pengguna dalam bentuk token ID. Cakupan offline_access bersifat opsional untuk aplikasi web. Ini menunjukkan bahwa aplikasi Anda memerlukan token refresh untuk akses yang diperluas ke sumber daya. Id klien menunjukkan token yang dikeluarkan ditujukan untuk digunakan oleh klien terdaftar Azure AD B2C. https://{tenant-name}/{app-id-uri}/{scope} menunjukkan izin ke sumber daya yang dilindungi, seperti API web. Untuk informasi selengkapnya, lihat Meminta token akses.
modus_respons Direkomendasikan Metode yang Anda gunakan untuk mengirim kode otorisasi yang dihasilkan kembali ke aplikasi Anda. Ini bisa , query, form_postatau fragment.
negara bagian Direkomendasikan Nilai yang disertakan dalam permintaan ini dapat berupa string dengan konten apa pun yang ingin Anda gunakan. Biasanya, nilai unik yang dihasilkan secara acak digunakan, untuk mencegah serangan pemalsuan permintaan lintas situs. Status ini juga digunakan untuk mengodekan informasi tentang status pengguna di aplikasi sebelum permintaan autentikasi terjadi. Misalnya, halaman tempat pengguna berada, atau alur pengguna yang sedang dijalankan.
isyarat Fakultatif Jenis interaksi pengguna yang diperlukan. Saat ini, satu-satunya nilai yang valid adalah login, yang memaksa pengguna untuk memasukkan kredensial mereka pada permintaan tersebut. Single sign-on tidak akan berfungsi.
tantangan_kode disarankan/diperlukan Digunakan untuk mengamankan pemberian kode otorisasi melalui Proof Key for Code Exchange (PKCE). Diperlukan jika code_challenge_method disertakan. Anda perlu menambahkan logika di aplikasi Anda untuk menghasilkan code_verifier dan code_challenge. code_challenge adalah hash SHA256 yang dikodekan URL Base64 dari code_verifier. Anda menyimpan code_verifier di aplikasi Anda untuk digunakan nanti, dan mengirim code_challenge bersama dengan permintaan otorisasi. Untuk informasi selengkapnya, lihat PKCE RFC. Ini sekarang direkomendasikan untuk semua jenis aplikasi - aplikasi asli, SPAs, dan klien rahasia seperti aplikasi web.
code_challenge_method disarankan/diperlukan Metode yang digunakan untuk mengodekan code_verifier untuk parameter code_challenge. Ini HARUSS256, tetapi spesifikasi memungkinkan penggunaan plain jika karena alasan tertentu klien tidak dapat mendukung SHA256.

Jika Anda mengecualikan code_challenge_method, tetapi masih menyertakan code_challenge, maka code_challenge diasumsikan sebagai teks biasa. Platform identitas Microsoft mendukung plain dan S256. Untuk informasi selengkapnya, lihat PKCE RFC. Ini diperlukan untuk aplikasi satu halaman menggunakan alur kode otorisasi.
petunjuk_masuk Tidak. Dapat digunakan untuk mengisi otomatis bidang nama masuk di halaman masuk. Untuk informasi selengkapnya, lihat Pra-isikan nama pengguna.
domain_hint Tidak. Memberikan petunjuk kepada Azure AD B2C tentang penyedia identitas sosial yang harus digunakan untuk masuk. Jika nilai yang valid disertakan, pengguna akan langsung diarahkan ke halaman masuk penyedia identitas. Untuk informasi selengkapnya, lihat Mengalihkan pendaftaran masuk ke penyedia sosial.
Parameter kustom Tidak. Parameter kustom yang dapat digunakan dengan kebijakan kustom . Misalnya, URI konten halaman kustom dinamis, atau pemecah masalah klaim kunci-nilai.

Pada titik ini, pengguna diminta untuk menyelesaikan alur kerja pengguna. Ini mungkin melibatkan pengguna yang memasukkan nama pengguna dan kata sandi mereka, masuk dengan identitas sosial, mendaftar ke direktori, atau sejumlah langkah lainnya. Tindakan pengguna bergantung pada bagaimana alur pengguna ditentukan.

Setelah pengguna menyelesaikan alur pengguna, MICROSOFT Entra ID mengembalikan respons ke aplikasi Anda dengan nilai yang Anda gunakan untuk redirect_uri. Ini menggunakan metode yang ditentukan dalam response_mode parameter . Responsnya sama persis untuk setiap skenario tindakan pengguna, terlepas dari alur pengguna yang dijalankan.

Respons yang berhasil yang menggunakan response_mode=query terlihat seperti ini:

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
Pengaturan Deskripsi
kode Kode otorisasi yang diminta aplikasi. Aplikasi ini dapat menggunakan kode otorisasi untuk meminta token akses untuk sumber daya target. Kode otorisasi berumur pendek. Biasanya, kedaluwarsa setelah sekitar 10 menit.
negara bagian Lihat deskripsi lengkap dalam tabel di bagian sebelumnya. Jika parameter state disertakan dalam permintaan, maka nilai yang sama akan muncul dalam respons. Aplikasi harus memverifikasi bahwa state nilai dalam permintaan dan respons identik.

Respons kesalahan juga dapat dikirim ke URI pengalihan sehingga aplikasi dapat menanganinya dengan tepat:

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
Pengaturan Deskripsi
kesalahan String kode kesalahan yang dapat Anda gunakan untuk mengklasifikasikan jenis kesalahan yang terjadi. Anda juga dapat menggunakan string untuk bereaksi terhadap kesalahan.
deskripsi_kesalahan Pesan kesalahan tertentu yang dapat membantu Anda mengidentifikasi akar penyebab kesalahan autentikasi.
negara bagian Lihat deskripsi lengkap dalam tabel sebelumnya. Jika parameter state disertakan dalam permintaan, maka nilai yang sama akan muncul dalam respons. Aplikasi harus memverifikasi bahwa state nilai dalam permintaan dan respons identik.

2. Dapatkan token akses

Setelah memperoleh kode otorisasi, Anda dapat menukarkan code untuk token ke sumber daya yang dimaksudkan dengan mengirim permintaan POST ke /token endpoint. Di Azure AD B2C, Anda dapat meminta token akses untuk API lain seperti biasa dengan menentukan cakupannya dalam permintaan.

Anda juga dapat meminta token akses untuk API Web back-end aplikasi Anda sendiri dengan konvensi menggunakan ID klien aplikasi sebagai cakupan yang diminta (yang akan menghasilkan token akses dengan ID klien tersebut sebagai "audiens"):

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=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=00001111-aaaa-2222-bbbb-3333cccc4444 offline_access
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
&code_verifier=ThisIsntRandomButItNeedsToBe43CharactersLong 
Pengaturan Diperlukan? Deskripsi
{penyewa} Diperlukan Nama penyewa Azure AD B2C Anda
{kebijakan} Diperlukan Alur pengguna yang digunakan untuk memperoleh kode otorisasi. Anda tidak dapat menggunakan alur pengguna yang berbeda dalam permintaan ini.
ID klien Diperlukan ID aplikasi yang ditetapkan ke aplikasi Anda di portal Microsoft Azure.
client_secret (kunci rahasia klien) Ya, di Web Apps Rahasia aplikasi yang dihasilkan di portal Azure . Rahasia klien digunakan dalam alur ini untuk skenario Aplikasi Web, di mana klien dapat menyimpan rahasia klien dengan aman. Untuk skenario Aplikasi Asli (klien publik), rahasia klien tidak dapat disimpan dengan aman, dan karenanya tidak digunakan dalam panggilan ini. Jika Anda menggunakan rahasia klien, ubah secara berkala.
jenis_izin Diperlukan Jenis pemberian. Untuk alur kode otorisasi, tipe izin harus authorization_code.
ruang lingkup Direkomendasikan Daftar cakupan yang dipisahkan oleh spasi. Nilai cakupan tunggal menunjukkan kepada Azure AD B2C kedua jenis izin yang diminta. Menggunakan ID klien sebagai cakupan menunjukkan bahwa aplikasi Anda memerlukan token akses yang dapat digunakan terhadap layanan atau API web Anda sendiri, yang diwakili oleh ID klien yang sama. Cakupan offline_access menunjukkan bahwa aplikasi Anda memerlukan token refresh untuk akses berumur panjang ke sumber daya. Anda juga dapat menggunakan lingkup openid untuk meminta token ID dari Azure AD B2C.
kode Diperlukan Kode otorisasi yang Anda peroleh dari /authorize titik akhir.
alamat_pengalihan Diperlukan URI pengalihan aplikasi tempat Anda menerima kode otorisasi.
pemverifikasi kode Disarankan Cara yang sama code_verifier digunakan untuk mendapatkan kode otorisasi. Diperlukan jika PKCE digunakan dalam permintaan pemberian kode otorisasi. Untuk informasi selengkapnya, lihat PKCE RFC.

Jika Anda menguji permintaan HTTP POST ini, Anda dapat menggunakan klien HTTP apa pun seperti Microsoft PowerShell.

Respons token yang berhasil terlihat seperti ini:

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
    "expires_in": "3600",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}
Pengaturan Deskripsi
tidak sebelum Waktu ketika token dianggap valid, dalam waktu epoch.
tipe_token Nilai jenis dari token. Satu-satunya jenis yang didukung Microsoft Entra ID adalah Bearer.
access_token (token akses) Token Web JSON (JWT) yang ditandatangani yang Anda minta.
ruang lingkup Cakupan yang mana token ini berlaku. Anda juga dapat menggunakan lingkup untuk menyimpan token untuk digunakan nanti.
Kedaluarsa dalam Lamanya waktu token valid (dalam detik).
token penyegaran Token pembaruan OAuth 2.0. Aplikasi dapat menggunakan token ini untuk memperoleh token tambahan setelah token saat ini kedaluwarsa. Token penyegaran memiliki umur panjang. Anda dapat menggunakannya untuk mempertahankan akses ke sumber daya untuk jangka waktu yang lama. Untuk informasi selengkapnya, lihat referensi token Azure AD B2C.

Respons kesalahan terlihat seperti ini:

{
    "error": "access_denied",
    "error_description": "The user revoked access to the app.",
}
Pengaturan Deskripsi
kesalahan String kode kesalahan yang dapat Anda gunakan untuk mengklasifikasikan jenis kesalahan yang terjadi. Anda juga dapat menggunakan string untuk bereaksi terhadap kesalahan.
deskripsi_kesalahan Pesan kesalahan tertentu yang dapat membantu Anda mengidentifikasi akar penyebab kesalahan autentikasi.

3. Gunakan token

Setelah berhasil memperoleh token akses, Anda dapat menggunakan token dalam permintaan ke API web back-end Anda dengan menyertakannya di Authorization header:

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

4. Perbarui token tersebut

Token akses dan token ID berumur pendek. Setelah kedaluwarsa, Anda harus me-refreshnya untuk terus mengakses sumber daya. Saat Anda me-refresh token akses, Azure AD B2C mengembalikan token baru. Token akses yang di-refresh akan memperbarui nilai klaim nbf (tidak sebelumnya), iat (dikeluarkan pada), dan exp (kedaluwarsa). Semua nilai klaim lainnya sama dengan token akses yang dikeluarkan awalnya.

Untuk memperbarui token, kirim permintaan POST lain ke endpoint /token. Kali ini, berikan refresh_token alih-alih 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=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=00001111-aaaa-2222-bbbb-3333cccc4444 offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
Pengaturan Diperlukan? Deskripsi
{penyewa} Diperlukan Nama penyewa Azure AD B2C Anda
{kebijakan} Diperlukan Alur pengguna yang digunakan untuk memperoleh token refresh asli. Anda tidak dapat menggunakan alur pengguna yang berbeda dalam permintaan ini.
ID klien Diperlukan ID aplikasi yang ditetapkan ke aplikasi Anda di portal Microsoft Azure.
client_secret (kunci rahasia klien) Ya, di Web Apps Rahasia aplikasi yang dihasilkan di portal Azure . Rahasia klien digunakan dalam alur ini untuk skenario Aplikasi Web, di mana klien dapat menyimpan rahasia klien dengan aman. Untuk skenario Aplikasi Asli (klien publik), rahasia klien tidak dapat disimpan dengan aman, dan karenanya tidak digunakan dalam panggilan ini. Jika Anda menggunakan rahasia klien, silakan ubah secara berkala.
jenis_izin Diperlukan Jenis pemberian. Untuk bagian alur kode otorisasi ini, jenis otorisasi harus refresh_token.
ruang lingkup Direkomendasikan Daftar cakupan yang dipisahkan oleh spasi. Nilai cakupan tunggal menunjukkan kepada Microsoft Entra ID bahwa kedua izin sedang diminta. Menggunakan ID klien sebagai cakupan menunjukkan bahwa aplikasi Anda memerlukan token akses yang dapat digunakan terhadap layanan atau API web Anda sendiri, yang diwakili oleh ID klien yang sama. Cakupan offline_access menunjukkan bahwa aplikasi Anda memerlukan token refresh untuk akses berumur panjang ke sumber daya. Anda juga dapat menggunakan lingkup openid untuk meminta token ID dari Azure AD B2C.
alamat_pengalihan Fakultatif URI pengalihan aplikasi tempat Anda menerima kode otorisasi.
token penyegaran Diperlukan Token refresh asli yang Anda peroleh di tahap kedua dari proses.

Respons token yang berhasil terlihat seperti ini:

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
    "expires_in": "3600",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}
Pengaturan Deskripsi
tidak sebelum Waktu ketika token dianggap valid, dalam waktu epoch.
tipe_token Nilai jenis dari token. Satu-satunya jenis yang didukung Microsoft Entra ID adalah Bearer.
access_token (token akses) Token JWT yang telah ditandatangani yang Anda minta.
ruang lingkup Cakupan yang mana token ini berlaku. Anda juga dapat menggunakan ruang lingkup untuk menyimpan token yang dapat digunakan nanti.
Kedaluarsa dalam Lamanya waktu token valid (dalam detik).
token penyegaran Token pembaruan OAuth 2.0. Aplikasi dapat menggunakan token ini untuk memperoleh token tambahan setelah token saat ini kedaluwarsa. Token refresh berumur panjang dan dapat digunakan untuk mempertahankan akses ke sumber daya untuk jangka waktu yang lama. Untuk informasi selengkapnya, lihat referensi token Azure AD B2C.

Respons kesalahan terlihat seperti ini:

{
    "error": "access_denied",
    "error_description": "The user revoked access to the app.",
}
Pengaturan Deskripsi
kesalahan String kode kesalahan yang dapat Anda gunakan untuk mengklasifikasikan jenis kesalahan yang terjadi. Anda juga dapat menggunakan string untuk bereaksi terhadap kesalahan.
deskripsi_kesalahan Pesan kesalahan tertentu yang dapat membantu Anda mengidentifikasi akar penyebab kesalahan autentikasi.

Menggunakan direktori Azure AD B2C Anda sendiri

Untuk mencoba permintaan ini sendiri, selesaikan langkah-langkah berikut. Ganti nilai contoh yang kami gunakan dalam artikel ini dengan nilai Anda sendiri.

  1. Buat direktori Azure AD B2C. Gunakan nama direktori Anda dalam permintaan.
  2. Buat aplikasi untuk mendapatkan ID aplikasi dan URI pengalihan. Sertakan klien asli di aplikasi Anda.
  3. Buat alur pengguna Anda untuk mendapatkan nama alur pengguna Anda.