Jenis aplikasi yang dapat digunakan dalam Active Directory B2C

  • Artikel

Azure Active Directory B2C (Azure AD B2C) mendukung autentikasi untuk berbagai arsitektur aplikasi modern. Semuanya didasarkan pada protokol standar industri OAuth 2.0 atau OpenID Connect. Artikel ini menjelaskan jenis aplikasi yang dapat Anda buat, terbersalisasi dari bahasa atau platform yang Anda sukai. Ini juga membantu Anda memahami skenario tingkat tinggi sebelum Anda mulai membangun aplikasi.

Setiap aplikasi yang menggunakan Azure AD B2C harus terdaftar di penyewa Azure AD B2C dengan menggunakan portal Microsoft Azure. Proses pendaftaran aplikasi mengumpulkan dan menetapkan nilai, seperti:

  • ID Aplikasi yang secara unik mengidentifikasi aplikasi Anda.
  • URL Balasan yang dapat digunakan untuk mengarahkan respons kembali ke aplikasi Anda.

Setiap permintaan yang dikirim ke Azure AD B2C menentukan alur pengguna (kebijakan bawaan) atau kebijakan kustom yang mengontrol perilaku Azure AD B2C. Kedua jenis kebijakan memungkinkan Anda membuat serangkaian pengalaman pengguna yang sangat dapat disesuaikan.

Interaksi setiap aplikasi mengikuti pola tingkat tinggi yang serupa:

  1. Aplikasi mengarahkan pengguna ke titik akhir v2.0 untuk menjalankan kebijakan.
  2. Pengguna menyelesaikan kebijakan sesuai dengan definisi kebijakan.
  3. Aplikasi menerima token keamanan dari titik akhir v2.0.
  4. Aplikasi ini menggunakan token keamanan untuk mengakses informasi yang dilindungi atau sumber daya yang dilindungi.
  5. Server sumber daya memvalidasi token keamanan untuk memverifikasi bahwa akses dapat diberikan.
  6. Aplikasi secara berkala me-refresh token keamanan.

Langkah-langkah ini dapat sedikit berbeda berdasarkan jenis aplikasi yang Anda bangun.

Aplikasi web

Untuk aplikasi web (termasuk .NET, PHP, Java, Ruby, Python, dan Node.js) yang dihosting di server web dan diakses melalui browser, Azure AD B2C mendukung OpenID Connect untuk semua pengalaman pengguna. Dalam implementasi OpenID Connect Azure AD B2C, aplikasi web Anda memulai pengalaman pengguna dengan mengeluarkan permintaan autentikasi ke ID Microsoft Entra. Hasil dari permintaan adalah id_token. Token keamanan ini mewakili identitas pengguna. Ini juga memberikan informasi tentang pengguna dalam bentuk klaim:

// Partial raw id_token
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtyaU1QZG1Cd...

// Partial content of a decoded id_token
{
    "name": "John Smith",
    "email": "john.smith@gmail.com",
    "oid": "d9674823-dffc-4e3f-a6eb-62fe4bd48a58"
    ...
}

Pelajari selengkapnya tentang jenis token dan klaim yang tersedia untuk aplikasi di referensi token Azure AD B2C.

Dalam aplikasi web, setiap eksekusi kebijakan mengambil langkah-langkah tingkat tinggi ini:

  1. Pengguna menelusuri aplikasi web.
  2. Aplikasi web mengalihkan pengguna ke Azure AD B2C yang menunjukkan kebijakan untuk dijalankan.
  3. Pengguna menyelesaikan kebijakan.
  4. Azure AD B2C mengembalikan id_token ke browser.
  5. id_token diposting ke URI pengalihan.
  6. id_token divalidasi dan cookie sesi disetel.
  7. Halaman aman dikembalikan ke pengguna.

Validasi id_token dengan menggunakan kunci penandatanganan publik yang diterima dari ID Microsoft Entra cukup untuk memverifikasi identitas pengguna. Proses ini juga menetapkan cookie sesi yang dapat digunakan untuk mengidentifikasi pengguna pada permintaan halaman berikutnya.

Untuk melihat skenario ini dalam tindakan, cobalah salah satu sampel kode rincian masuk aplikasi web di bagian Memulai bagian kami.

Selain memfasilitasi masuk sederhana, aplikasi web mungkin juga perlu mengakses layanan web back-end. Dalam hal ini, aplikasi web dapat melakukan aliran OpenID Connect yang sedikit berbeda dan memperoleh token dengan menggunakan kode otorisasi dan token refresh. Skenario ini digambarkan di bagian API Web berikut.

Aplikasi satu halaman

Banyak aplikasi web modern dibangun sebagai aplikasi satu halaman sisi klien ("SPA"). Pengembang menulisnya dengan menggunakan JavaScript atau kerangka kerja SPA seperti Angular, Vue, dan React. Aplikasi ini berjalan di browser web dan memiliki karakteristik autentikasi yang berbeda dari aplikasi web sisi server tradisional.

Azure AD B2C menyediakan dua opsi untuk mengaktifkan aplikasi satu halaman untuk masuk ke pengguna dan mendapatkan token untuk mengakses layanan back-end atau API web:

Aliran kode otorisasi (dengan PKCE)

Alur kode Otorisasi OAuth 2.0 (dengan PKCE) memungkinkan aplikasi menukar kode otorisasi untuk token ID untuk mewakili pengguna yang diautentikasi dan token Akses yang diperlukan untuk memanggil API yang dilindungi. Selain itu, alur mengembalikan token Refresh yang menyediakan akses jangka panjang ke sumber daya atas nama pengguna tanpa memerlukan interaksi dengan pengguna tersebut.

Kami merekomendasikan pendekatan ini. Memiliki token refresh seumur hidup terbatas membantu aplikasi Anda beradaptasi dengan keterbatasan privasi cookie browser modern, seperti Safari ITP.

Untuk memanfaatkan alur ini, aplikasi Anda dapat menggunakan pustaka autentikasi yang mendukungnya, seperti MSAL.js 2.x.

Aplikasi-auth satu halaman

Aliran hibah implisit

Beberapa pustaka, seperti MSAL.js 1.x, hanya mendukung alur pemberian implisit atau aplikasi Anda diterapkan untuk menggunakan alur implisit. Dalam kasus ini, Azure Active Directory B2C mendukung alur implisit OAuth 2.0. Aliran hibah implisit memungkinkan aplikasi untuk mendapatkan token ID dan Akses. Tidak seperti alur kode otorisasi, alur pemberian implisit tidak menampilkan token Refresh.

Kami tidak merekomendasikan pendekatan ini.

Alur autentikasi ini tidak mencakup skenario aplikasi yang menggunakan kerangka kerja JavaScript lintas platform seperti Electron dan React-Native. Skenario-skenario tersebut memerlukan kemampuan lebih lanjut untuk interaksi dengan platform asli.

API Web

Anda dapat menggunakan Azure AD B2C untuk mengamankan layanan web seperti API web RESTful aplikasi Anda. API Web dapat menggunakan OAuth 2.0 untuk mengamankan datanya, dengan mengautentikasi permintaan HTTP masuk menggunakan token. Penelepon API web menambahkan token di header otorisasi permintaan HTTP:

GET /api/items HTTP/1.1
Host: www.mywebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6...
Accept: application/json
...

API web kemudian dapat menggunakan token untuk memverifikasi identitas penelepon API dan untuk mengekstrak informasi tentang penelepon dari klaim yang dikodekan dalam token. Pelajari selengkapnya tentang jenis token dan klaim yang tersedia untuk aplikasi di referensi token Azure AD B2C.

API web dapat menerima token dari banyak jenis klien, termasuk aplikasi web, aplikasi desktop dan seluler, aplikasi satu halaman, daemon sisi server, dan API web lainnya. Berikut adalah contoh alur lengkap untuk aplikasi web yang memanggil API web:

  1. Aplikasi web menjalankan kebijakan dan pengguna menyelesaikan pengalaman pengguna.
  2. Azure AD B2C mengembalikan (OpenID Connect) id_token dan kode otorisasi ke browser.
  3. Browser memposting kode id_token otorisasi dan ke URI pengalihan.
  4. Server web memvalidasi id_token dan menyetel cookie sesi.
  5. Server web meminta Azure AD B2C untuk access_token dengan memberikan kode otorisasi, ID klien aplikasi, dan info masuk klien.
  6. access_token dan refresh_token dikembalikan ke server web.
  7. API web dipanggil dengan access_token di header otorisasi.
  8. API web memvalidasi token.
  9. Data aman dikembalikan ke aplikasi web.

Untuk mempelajari lebih lanjut tentang kode otorisasi, token refresh, dan langkah-langkah untuk mendapatkan token, baca tentang protokol OAuth 2.0.

Untuk mempelajari cara mengamankan API web dengan menggunakan Azure AD B2C, lihat tutorial API web di bagian Memulai.

Aplikasi seluler dan native

Aplikasi yang dipasang pada perangkat, seperti aplikasi seluler dan desktop, sering kali perlu mengakses layanan back-end atau API web atas nama pengguna. Anda dapat menambahkan pengalaman manajemen identitas yang disesuaikan ke aplikasi asli Anda dan dengan aman memanggil layanan back-end dengan menggunakan Azure AD B2C dan aliran kode otorisasi OAuth 2.0.

Dalam alur ini, aplikasi menjalankan kebijakan dan menerima authorization_code dari ID Microsoft Entra setelah pengguna menyelesaikan kebijakan. authorization_code mewakili izin aplikasi untuk memanggil layanan back-end atas nama pengguna yang saat ini masuk. Aplikasi kemudian dapat bertukar authorization_code di latar belakang untuk access_token dan refresh_token. Aplikasi dapat menggunakan access_token untuk mengautentikasi ke API web back-end dalam permintaan HTTP. Ini juga dapat menggunakan refresh_token untuk mendapatkan access_token baru ketika yang lebih tua kedaluwarsa.

Daemons/aplikasi sisi server

Aplikasi yang berisi proses jangka panjang atau yang beroperasi tanpa kehadiran pengguna juga memerlukan cara untuk mengakses sumber daya yang aman seperti API web. Aplikasi ini dapat mengautentikasi dan mendapatkan token menggunakan identitasnya (bukan identitas yang didelegasikan pengguna) dan dengan menggunakan alur info masuk klien OAuth 2.0. Alur info masuk klien tidak sama dengan alur atas nama dan alur atas nama tidak boleh digunakan untuk autentikasi server-ke-server.

Untuk Azure AD B2C, alur info masuk klien OAuth 2.0 saat ini dalam pratinjau publik. Namun, Anda dapat menyiapkan alur kredensial klien menggunakan ID Microsoft Entra dan titik akhir platform identitas Microsoft /token (https://login.microsoftonline.com/your-tenant-name.onmicrosoft.com/oauth2/v2.0/token) untuk aplikasi Microsoft Graph atau aplikasi Anda sendiri. Untuk informasi selengkapnya, lihat artikel referensi token Microsoft Entra.

Jenis aplikasi yang tidak didukung

Rantai API Web (aliran atas nama)

Banyak arsitektur termasuk API web yang perlu memanggil API web hilir lainnya, di mana keduanya diamankan oleh Azure AD B2C. Skenario ini umum terjadi pada klien asli yang memiliki back-end Web API dan memanggil layanan online Microsoft seperti Microsoft Graph API.

Skenario API web berantai ini dapat didukung dengan menggunakan hibah info masuk token pembawa OAuth 2.0 JWT, yang juga dikenal sebagai aliran atas nama. Namun, alur atas nama saat ini tidak diterapkan di Azure AD B2C.

Langkah berikutnya

Cari tahu lebih lanjut tentang kebijakan bawaan yang disediakan oleh Alur pengguna di Azure Active Directory B2C.