Masuk ke web dengan OpenID Connect di Azure Active Directory B2C
OpenID Connect adalah protokol autentikasi, yang dibangun di atas OAuth 2.0 yang dapat digunakan untuk memasukkan pengguna dengan aman ke aplikasi web. Dengan menggunakan implementasi Azure Active Directory B2C (Azure AD B2C) dari OpenID Koneksi, Anda dapat mengalihdayakan pengalaman pendaftaran, masuk, dan manajemen identitas lainnya di aplikasi web Anda ke ID Microsoft Entra. Panduan ini menunjukkan kepada Anda cara melakukannya dengan bahasa pemrogaman yang mandiri. Panduan ini menjelaskan cara mengirim dan menerima pesan HTTP tanpa menggunakan perpustakaan sumber terbuka kami.
Catatan
Sebagian besar pustaka autentikasi sumber terbuka memperoleh dan memvalidasi token JWT untuk aplikasi Anda. Sebaiknya jelajahi opsi tersebut, daripada menerapkan kode Anda sendiri. Untuk informasi selengkapnya, lihat Gambaran Umum Pustaka Autentikasi Microsoft (MSAL),dan pustaka autentikasi Web Identitas Microsoft.
OpenID Connect memperluas protokol otorisasi OAuth 2.0 untuk digunakan sebagai protokol autentikasi. Protokol autentikasi ini memungkinkan Anda melakukan SSO. Ini memperkenalkan konsep token ID, yang memungkinkan klien untuk memverifikasi identitas pengguna dan mendapatkan informasi profil dasar tentang pengguna.
OpenID Koneksi juga memungkinkan aplikasi memperoleh token akses dengan aman. Anda dapat menggunakan token akses untuk mengakses sumber daya yang diamankan server otorisasi. Kami merekomendasikan OpenID Koneksi jika Anda membangun aplikasi web yang Anda host di server dan diakses melalui browser. Untuk informasi selengkapnya tentang token, lihat gambaran umum token di Azure Active Directory B2C
Azure AD B2C memperluas protokol standar OpenID Connect untuk melakukan lebih dari autentikasi dan otorisasi sederhana. Ini memperkenalkan parameter alur pengguna, yang memungkinkan Anda menggunakan OpenID Connect untuk menambahkan pengalaman pengguna ke aplikasi Anda, seperti pendaftaran, masuk, dan manajemen profil.
Kirim permintaan autentikasi
Ketika aplikasi web Anda perlu mengautentikasi pengguna dan menjalankan alur pengguna, aplikasi web tersebut dapat mengarahkan pengguna ke titik akhir /authorize. Pengguna mengambil langkah sesuai dengan alur pengguna.
Dalam permintaan ini, klien menunjukkan izin yang diperlukan dari pengguna dalam parameter scope, dan menentukan alur pengguna untuk dijalankan. Untuk merasakan cara kerja permintaan, tempelkan permintaan ke browser Anda dan jalankan. Ganti:
{tenant}dengan nama penyewa Anda.90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6dengan ID aplikasi aplikasi yang Anda daftarkan di penyewa Anda.{application-id-uri}/{scope-name}dengan URI ID Aplikasi dan cakupan aplikasi yang Anda daftarkan di penyewa Anda.{policy}dengan nama kebijakan yang Anda miliki di penyewa Anda, misalnyab2c_1_sign_in.
GET /{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
Host: {tenant}.b2clogin.com
client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&response_type=code+id_token
&redirect_uri=https%3A%2F%2Fjwt.ms%2F
&response_mode=fragment
&scope=openid%20offline_access%20{application-id-uri}/{scope-name}
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345
| Parameter | Wajib | Deskripsi |
|---|---|---|
| {tenant} | Ya | Nama penyewa AAD B2C Anda. Jika Anda menggunakan domain kustom, ganti tenant.b2clogin.com dengan domain Anda, seperti fabrikam.com. |
| {policy} | Ya | Alur atau kebijakan pengguna yang dijalankan aplikasi. Tentukan nama alur pengguna yang Anda buat di penyewa Azure AD B2C Anda. Misalnya: b2c_1_sign_in, b2c_1_sign_up, atau b2c_1_edit_profile. |
| client_id | Ya | ID aplikasi yang ditetapkan portal Microsoft Azure ke aplikasi Anda. |
| nonce | Ya | Nilai yang tercantum dalam permintaan (dibuat oleh aplikasi) yang disertakan dalam token ID yang dihasilkan sebagai klaim. Aplikasi kemudian dapat memverifikasi nilai ini untuk meminimalkan serangan replay token. Biasanya, nilainya adalah string acak dan unik yang dapat digunakan untuk mengidentifikasi asal permintaan. |
| response_type | Ya | Harus menyertakan token ID untuk OpenID Connect. Jika aplikasi web Anda juga memerlukan token untuk memanggil API web, Anda dapat menggunakan code+id_token. |
| cakupan | Ya | Daftar cakupan yang dipisahkan 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. https://{tenant-name}/{app-id-uri}/{scope} menunjukkan izin ke sumber daya yang dilindungi, seperti API web. Untuk informasi selengkapnya, lihat Meminta token akses. |
| perintah | Tidak | Jenis interaksi pengguna yang Anda butuhkan. Satu-satunya nilai yang valid saat ini adalah login, yang memaksa pengguna untuk memasukkan kredensial mereka pada permintaan itu. |
| redirect_uri | Ya | Parameter redirect_uri aplikasi Anda, tempat server mengirim respons autentikasi ke aplikasi Anda. Ini harus sama persis dengan salah satu parameter redirect_uri yang Anda daftarkan di portal Microsoft Azure, kecuali hal itu memang harus dikodekan dengan URL. |
| response_mode | Tidak | Metode yang digunakan untuk mengirim kode otorisasi yang dihasilkan kembali ke aplikasi Anda. Bisa jadi query, form_post, atau fragment. Kami menyarankan Anda menggunakan form_post mode respons untuk keamanan terbaik. |
| state | Tidak | Nilai yang dapat Anda sertakan dalam permintaan yang dikembalikan server otorisasi dalam respons token. Ini bisa berupa string dari konten apa pun yang ingin Anda gunakan. Nilai unik yang dihasilkan secara acak biasanya digunakan untuk mencegah serangan pemalsuan permintaan lintas situs. Status ini juga digunakan untuk menyandikan informasi tentang status pengguna di aplikasi sebelum permintaan autentikasi muncul, seperti halaman tempat mereka berada. Jika tidak ingin mendaftarkan beberapa URL pengalihan di portal Microsoft Azure, Anda dapat menggunakan state parameter untuk membedakan respons di aplikasi anda dari layanan Azure AD B2C karena permintaan yang berbeda. |
| login_hint | Tidak | Dapat digunakan untuk mengisi bidang nama masuk sebelumnya dari halaman masuk. Untuk informasi selengkapnya, lihat Pengisian awal nama rincian masuk. |
| petunjuk domain | Tidak | Memberikan petunjuk kepada AAD B2C tentang IdP sosial yang harus digunakan untuk rincian masuk. Jika nilai yang valid disertakan, pengguna langsung masuk ke halaman rincian masuk IdP. Untuk informasi selengkapnya, lihat Mengalihkan rincian masuk ke penyedia sosial. |
| Parameter kustom | Tidak | Parameter kustom yang dapat digunakan dengan kebijakan kustom. Misalnya, konten halaman kustom dinamis URI, atau pemecah klaim nilai kunci. |
Pada tahap ini, pengguna diminta untuk menyelesaikan alur kerja. Pengguna mungkin harus memasukkan nama pengguna dan kata sandi mereka, masuk dengan identitas sosial, atau mendaftar ke direktori. Mungkin ada sejumlah langkah lain tergantung pada bagaimana aliran pengguna ditentukan.
Setelah pengguna menyelesaikan alur pengguna, respons dikembalikan ke aplikasi Anda pada parameter yang ditunjukkan redirect_uri , dengan menggunakan metode yang Anda tentukan dalam response_mode parameter . Responsnya sama untuk masing-masing kasus sebelumnya, independen dari aliran pengguna.
Respons yang berhasil menggunakan response_mode=fragment akan terlihat seperti:
GET https://jwt.ms/#
id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&state=arbitrary_data_you_can_receive_in_the_response
| Parameter | Deskripsi |
|---|---|
| id_token | Token ID yang diminta aplikasi. Anda dapat menggunakan token ID untuk memverifikasi identitas pengguna dan memulai sesi dengan pengguna. |
| code | Kode otorisasi yang diminta aplikasi, jika Anda menggunakan response_type=code+id_token. Aplikasi dapat menggunakan kode otorisasi untuk meminta token akses untuk sumber daya target. Kode otorisasi biasanya kedaluwarsa setelah sekitar 10 menit. |
| state | Jika parameter state disertakan dalam permintaan, maka nilai yang sama akan muncul dalam respons. Aplikasi harus memverifikasi bahwa nilai state dalam permintaan dan respons identik. |
Respons kesalahan juga dapat dikirim ke parameter redirect_uri sehingga aplikasi dapat menanganinya dengan tepat:
GET https://jwt.ms/#
error=access_denied
&error_description=AADB2C90091%3a+The+user+has+cancelled+entering+self-asserted+information.%0d%0aCorrelation+ID%3a+xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx%0d%0aTimestamp%3a+xxxx-xx-xx+xx%3a23%3a27Z%0d%0a
&state=arbitrary_data_you_can_receive_in_the_response
| Parameter | Deskripsi |
|---|---|
| kesalahan | String kode yang dapat digunakan untuk mengklasifikasikan jenis kesalahan yang terjadi. |
| error_description | Pesan kesalahan khusus yang dapat membantu Anda mengidentifikasi penyebab kesalahan autentikasi. |
| state | Jika parameter state disertakan dalam permintaan, maka nilai yang sama akan muncul dalam respons. Aplikasi harus memverifikasi bahwa nilai state dalam permintaan dan respons identik. |
Memvalidasi token ID
Hanya menerima token ID tidak cukup untuk mengautentikasi pengguna. Validasi tanda tangan token ID, dan verifikasi klaim dalam token sesuai yang diminta oleh aplikasi Anda. Azure AD B2C menggunakan JSON Web Tokens (JWTs) dan kriptografi kunci umum untuk menandatangani token dan memverifikasi keabsahannya.
Catatan
Sebagian besar pustaka autentikasi sumber terbuka memvalidasi token JWT untuk aplikasi Anda. Sebaiknya jelajahi opsi tersebut, daripada menerapkan logika validasi Anda sendiri. Untuk informasi selengkapnya, lihat Gambaran Umum Pustaka Autentikasi Microsoft (MSAL),dan pustaka autentikasi Web Identitas Microsoft.
Azure AD B2C memiliki titik akhir metadata OpenID Connect, yang memungkinkan aplikasi untuk mendapatkan informasi tentang Azure AD B2C pada saat runtime. Informasi ini meliputi titik akhir, konten token, dan kunci penandatanganan token. Ada dokumen metadata JSON untuk setiap alur pengguna di penyewa B2C Anda. Misalnya, dokumen metadata untuk b2c_1_sign_in alur pengguna fabrikamb2c.onmicrosoft.com berada di:
https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/v2.0/.well-known/openid-configuration
Salah satu properti dokumen konfigurasi ini adalah jwks_uri, yang nilainya untuk aliran pengguna yang sama adalah:
https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/discovery/v2.0/keys
Untuk menentukan alur pengguna mana yang digunakan untuk menandatangani token ID, Anda memiliki dua opsi. Pertama, nama alur pengguna disertakan dalam acr klaim di token ID, lihat klaim yang mewakili alur pengguna. Pilihan Anda yang lain adalah menyandikan aliran pengguna dalam nilai parameter state saat Anda mengeluarkan permintaan, lalu mendekodenya untuk menentukan aliran pengguna mana yang digunakan. Masing-masing metode tersebut dapat digunakan.
Setelah Anda memperoleh dokumen metadata dari titik akhir metadata OpenID Koneksi, Anda dapat menggunakan kunci umum RSA 256 untuk memvalidasi tanda tangan token ID. Mungkin akan ada beberapa kunci yang tercantum di titik akhir ini, masing-masing diidentifikasi oleh klaim kid. Header token ID juga berisi klaim kid, yang menunjukkan kunci mana yang digunakan untuk menandatangani token ID.
Untuk memverifikasi token dari Azure AD B2C, Anda perlu membuat kunci umum menggunakan eksponen(e) dan modulus(n). Untuk melakukannya, Anda perlu mempelajari cara menghasilkan kunci umum dalam bahasa pemrograman pilihan Anda. Dokumentasi resmi tentang pembuatan Kunci Umum dengan protokol RSA dapat ditemukan di sini: https://tools.ietf.org/html/rfc3447#section-3.1
Setelah Anda memvalidasi tanda tangan token ID, ada berbagai klaim yang perlu Anda verifikasi. Contohnya:
- Memvalidasi klaim
nonceuntuk mencegah serangan replay token. Nilainya harus sesuai dengan yang Anda buat dalam permintaan masuk. - Memvalidasi klaim
auduntuk memastikan bahwa token ID telah dikeluarkan untuk aplikasi Anda. Nilainya akan menjadi ID aplikasi pada aplikasi Anda. - Memvalidasi klaim
iatdanexpuntuk memastikan bahwa token ID belum kedaluwarsa.
Ada juga beberapa validasi lagi yang harus Anda lakukan. Validasi dijelaskan secara rinci dalam OpenID Koneksi Core Spec. Anda mungkin juga ingin memvalidasi lebih banyak klaim, tergantung pada skenario Anda. Beberapa validasi umum meliputi:
- Pastikan pengguna/organisasi mendaftar untuk aplikasi.
- Pastikan bahwa pengguna memiliki otorisasi/hak istimewa yang tepat.
- Pastikan bahwa kekuatan autentikasi tertentu telah terjadi, seperti autentikasi multifaktor Microsoft Entra.
Setelah token ID divalidasi, Anda dapat memulai suatu sesi dengan pengguna. Anda dapat menggunakan klaim dalam token ID untuk mendapatkan informasi tentang pengguna di aplikasi Anda. Penggunaan untuk informasi ini termasuk tampilan, rekaman, dan otorisasi.
Mendapatkan token
Jika Anda memerlukan aplikasi web untuk hanya menjalankan alur pengguna, Anda dapat melewati beberapa bagian berikutnya. Bagian-bagian ini hanya berlaku untuk aplikasi web yang perlu melakukan panggilan terautentikasi ke API web, yang dilindungi oleh Azure AD B2C itu sendiri.
Anda dapat menukarkan kode otorisasi yang Anda peroleh (dengan menggunakan response_type=code+id_token) untuk token ke sumber daya yang diinginkan dengan mengirim permintaan POST ke titik akhir /token. 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. Dalam hal ini, Anda menggunakan ID klien aplikasi sebagai cakupan yang diminta, yang 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
Host: {tenant}.b2clogin.com
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
| Parameter | Wajib | Deskripsi |
|---|---|---|
| {tenant} | Ya | Nama penyewa Azure AD B2C Anda |
| {policy} | Ya | Alur pengguna yang digunakan untuk memperoleh kode otorisasi. Anda tidak dapat menggunakan alur pengguna yang berbeda dalam permintaan ini. Tambahkan parameter ini ke string kueri, bukan ke isi POSTING. |
| client_id | Ya | ID aplikasi yang ditetapkan portal Microsoft Azure ke aplikasi Anda. |
| client_secret | Ya, di Aplikasi Web | Rahasia aplikasi yang dihasilkan di portal Microsoft Azure. Rahasia klien digunakan dalam alur ini untuk skenario Aplikasi Web, yang kliennya dapat menyimpan rahasia klien dengan aman. Untuk skenario Aplikasi Asli (klien publik), rahasia klien tidak dapat disimpan dengan aman, oleh karena itu tidak digunakan pada alur ini. Jika menggunakan rahasia klien, ubah secara berkala. |
| code | Ya | Kode otorisasi yang Anda peroleh di awal alur pengguna. |
| grant_type | Ya | Jenis persetujuan, yang harus authorization_code untuk alur kode otorisasi. |
| redirect_uri | Tidak | Parameter redirect_uri aplikasi tempat Anda menerima kode otorisasi. |
| cakupan | Tidak | Daftar cakupan yang dipisahkan spasi. Cakupan openid menunjukkan izin untuk memasukkan pengguna dan mendapatkan data tentang pengguna dalam bentuk parameter id_token. Ini dapat digunakan untuk mendapatkan token ke API web back-end aplikasi Anda sendiri, yang diwakili oleh ID aplikasi yang sama dengan klien. Cakupan offline_access menunjukkan bahwa aplikasi Anda memerlukan token refresh untuk akses lanjutan ke sumber daya. |
Respons token yang sukses terlihat seperti:
{
"not_before": "1442340812",
"token_type": "Bearer",
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
"scope": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
"expires_in": "3600",
"expires_on": "1644254945",
"refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}
| Parameter | Deskripsi |
|---|---|
| not_before | Waktu epoch di mana token menjadi valid. |
| token_type | Nilai jenis token. Bearer adalah satu-satunya tipe yang didukung. |
| access_token | Token JWT tertandatangani yang Anda minta. |
| cakupan | Cakupan yang valid untuk token. |
| Berakhir dalam | Masa berlaku token akses (dalam detik). |
| expires_on | Waktu epoch ketika token akses menjadi tidak valid. |
| refresh_token | Token refresh OAuth 2.0. Aplikasi dapat menggunakan token ini untuk memperoleh lebih banyak token setelah token saat ini kedaluwarsa. Token refresh dapat digunakan untuk mempertahankan akses ke sumber daya untuk jangka waktu yang lama. Cakupan offline_access harus telah digunakan dalam otorisasi dan permintaan token untuk menerima token refresh. |
Respons kesalahan terlihat seperti:
{
"error": "invalid_grant",
"error_description": "AADB2C90080: The provided grant has expired. Please re-authenticate and try again. Current time: xxxxxxxxxx, Grant issued time: xxxxxxxxxx, Grant expiration time: xxxxxxxxxx\r\nCorrelation ID: xxxxxxxx-xxxx-xxxX-xxxx-xxxxxxxxxxxx\r\nTimestamp: xxxx-xx-16 xx:10:52Z\r\n"
}
| Parameter | Deskripsi |
|---|---|
| kesalahan | Kode yang digunakan untuk mengklasifikasikan jenis kesalahan yang terjadi. |
| error_description | Pesan kesalahan yang dapat membantu Anda mengidentifikasi akar penyebab kesalahan autentikasi. |
Menggunakan 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...
Refresh token
Token akses dan token ID berumur pendek. Setelah kedaluwarsa, Anda harus me-refresh token untuk terus mengakses sumber daya. Saat Anda merefresh token akses, Azure AD B2C mengembalikan token baru. Token akses yang di-refresh akan diperbarui nbf (tidak sebelumnya), iat (dikeluarkan pada), dan exp (kedaluwarsa) nilai klaim. Semua nilai klaim lainnya mirip dengan yang ada di token akses sebelumnya.
Anda dapat merefresh token dengan mengirimkan permintaan POST lain ke titik akhir /token. Kali ini, sediakan parameter refresh_token alih-alih parameter code:
POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1
Host: {tenant}.b2clogin.com
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token
&client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=openid offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
| Parameter | Wajib | Deskripsi |
|---|---|---|
| {tenant} | Ya | Nama penyewa Azure AD B2C Anda |
| {policy} | Ya | Alur pengguna yang digunakan untuk memperoleh token refresh asli. Anda tidak dapat menggunakan alur pengguna yang berbeda dalam permintaan ini. Tambahkan parameter ini ke string kueri, bukan ke isi POSTING. |
| client_id | Ya | ID aplikasi yang ditetapkan portal Microsoft Azure ke aplikasi Anda. |
| client_secret | Ya, di Aplikasi Web | Rahasia aplikasi yang dihasilkan di portal Microsoft Azure. Rahasia klien digunakan dalam alur ini untuk skenario Aplikasi Web, yang kliennya dapat menyimpan rahasia klien dengan aman. Untuk skenario Aplikasi Asli (klien publik), rahasia klien tidak dapat disimpan dengan aman, oleh karena itu tidak digunakan pada panggilan ini. Jika menggunakan rahasia klien, silakan ubah secara berkala. |
| grant_type | Ya | Jenis persetujuan, yang harus refresh_token untuk bagian alur kode otorisasi ini. |
| refresh_token | Ya | Token refresh asli yang diperoleh di bagian kedua alur. Cakupan offline_access harus digunakan dalam otorisasi dan permintaan token untuk menerima token refresh. |
| redirect_uri | Tidak | Parameter redirect_uri aplikasi tempat Anda menerima kode otorisasi. |
| cakupan | Tidak | Daftar cakupan yang dipisahkan spasi. cakupan openid menunjukkan izin untuk masuk ke pengguna dan mendapatkan data tentang pengguna dalam bentuk token ID. Ini dapat digunakan untuk mengirimkan token ke API web back-end aplikasi Anda sendiri, yang diwakili oleh ID aplikasi yang sama dengan klien. Cakupan offline_access menunjukkan bahwa aplikasi Anda memerlukan token refresh untuk akses lanjutan ke sumber daya. |
Respons token yang sukses terlihat seperti:
{
"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...",
"refresh_token_expires_in": "1209600"
}
| Parameter | Deskripsi |
|---|---|
| not_before | Waktu epoch di mana token menjadi valid. |
| token_type | Nilai jenis token. Bearer adalah satu-satunya tipe yang didukung. |
| access_token | Token JWT tertandatangani yang telah diminta. |
| cakupan | Cakupan yang valid untuk token. |
| Berakhir dalam | Masa berlaku token akses (dalam detik). |
| refresh_token | Token refresh OAuth 2.0. Aplikasi dapat menggunakan token ini untuk memperoleh token tambahan setelah token saat ini kedaluwarsa. Token refresh dapat digunakan untuk mempertahankan akses ke sumber daya untuk jangka waktu yang lama. |
| refresh_token_expires_in | Lamanya waktu token refresh valid (dalam hitungan detik). |
Respons kesalahan terlihat seperti:
{
"error": "invalid_grant",
"error_description": "AADB2C90129: The provided grant has been revoked. Please reauthenticate and try again.\r\nCorrelation ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\r\nTimestamp: xxxx-xx-xx xx:xx:xxZ\r\n",
}
| Parameter | Deskripsi |
|---|---|
| kesalahan | Kode yang digunakan untuk mengklasifikasikan jenis kesalahan yang terjadi. |
| error_description | Pesan kesalahan yang dapat membantu Anda mengidentifikasi akar penyebab kesalahan autentikasi. |
Mengirim permintaan keluar
Ketika Anda ingin mengeluarkan pengguna keluar dari aplikasi, itu tidak cukup untuk menghapus cookie aplikasi atau mengakhiri sesi dengan pengguna. Alihkan pengguna ke Azure AD B2C untuk mengeluarkan. Jika Anda gagal melakukannya, pengguna mungkin dapat mengautentikasi ulang ke aplikasi Anda tanpa memasukkan kredensial mereka lagi. Untuk informasi selengkapnya, lihat perilaku sesi Azure AD B2C.
Untuk mengeluarkan pengguna, alihkan pengguna ke end_session_endpoint yang tercantum dalam dokumen metadata OpenID Connect yang dijelaskan sebelumnya:
GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/logout?post_logout_redirect_uri=https%3A%2F%2Fjwt.ms%2F
| Parameter | Wajib | Deskripsi |
|---|---|---|
| {tenant} | Ya | Nama penyewa Azure AD B2C Anda. Jika Anda menggunakan domain kustom, ganti tenant.b2clogin.com dengan domain Anda, seperti fabrikam.com. |
| {policy} | Ya | Alur pengguna yang Anda tentukan dalam permintaan otorisasi. Misalnya, jika pengguna masuk dengan alur pengguna b2c_1_sign_in, tentukan b2c_1_sign_in di permintaan keluar. |
| id_token_hint | Tidak | Token ID yang diterbitkan sebelumnya untuk diteruskan ke titik akhir logout sebagai petunjuk tentang sesi terautentikasi pengguna akhir saat ini dengan klien. id_token_hint memastikan bahwa post_logout_redirect_uri adalah URL balasan yang terdaftar di pengaturan aplikasi Azure AD B2C Anda. Untuk informasi selengkapnya, lihat Mengamankan pengalihan logout Anda. |
| client_id | Tidak* | ID aplikasi yang ditetapkan portal Microsoft Azure ke aplikasi Anda. *Ini diperlukan saat menggunakan konfigurasi SSO isolasi Application dan Memerlukan Token ID dalam permintaan logout diatur ke No. |
| post_logout_redirect_uri | Tidak | URL pengalihan yang harus dituju pengguna setelah ia berhasil keluar. Jika tidak disertakan, maka Azure AD B2C akan menampilkan pesan generik kepada pengguna. Kecuali Anda memberikan id_token_hint, Anda tidak boleh mendaftarkan URL ini sebagai URL balasan di pengaturan aplikasi Azure AD B2C Anda. |
| state | Tidak | Jika Anda menyertakan state parameter dalam permintaan otorisasi, server otorisasi mengembalikan nilai yang sama dalam respons terhadap post_logout_redirect_uri. Aplikasi harus memverifikasi bahwa state nilai dalam permintaan dan respons identik. |
Atas permintaan keluar, Azure AD B2C membatalkan sesi berbasis cookie Azure AD B2C, dan mencoba untuk keluar dari federasi penyedia identitas. Untuk informasi selengkapnya, lihat Single sign-out.
Mengamankan pengalihan keluar Anda
Setelah keluar, pengguna dialihkan ke URI yang Anda tentukan dalam post_logout_redirect_uri parameter, terlepas dari URL balasan yang Anda tentukan untuk aplikasi. Namun, jika valid id_token_hint dilewatkan, dan Memerlukan Token Id dalam permintaan logout diaktifkan, Azure AD B2C memverifikasi bahwa nilai post_logout_redirect_uri sesuai dengan salah satu URI pengalihan yang dikonfigurasi aplikasi sebelum melakukan pengalihan. Jika tidak ada URL balasan yang cocok yang dikonfigurasi untuk aplikasi, pesan kesalahan ditampilkan dan pengguna tidak dialihkan.
Untuk mengatur Token ID yang diperlukan dalam permintaan logout, lihat Mengonfigurasi perilaku sesi di Azure Active Directory B2C.
Langkah berikutnya
- Pelajari selengkapnya tentang sesi AAD B2C.