Panduan Registrasi Aplikasi dan OAuth untuk Integrasi Aplikasi yang Aman

By Mirko Peters · 2026-05-04

Daftarkan aplikasi Anda dengan OAuth 2.0. Pahami alur kode otorisasi untuk akses yang aman, bagian penting dari grant kode otorisasi OAuth 2.0.

Automatically translated with AI from the original post. Read the English original

Mari kita akui saja: menerapkan autentikasi dan registrasi aplikasi dengan benar bukan hanya soal mengikuti protokol yang cerdas, tetapi juga memastikan pengguna, data, dan organisasi Anda tetap aman. Panduan ini menjelaskan registrasi aplikasi dan OAuth 2.0 secara sederhana, sehingga Anda dapat membangun autentikasi yang aman dan sesuai standar dengan Microsoft Entra ID (sebelumnya Azure AD) atau penyedia pilihan Anda.

Kami akan menguraikan langkah dan konsep yang Anda butuhkan, mulai dari memahami alasan di balik OAuth hingga langsung mempraktikkannya pada aplikasi web, seluler, atau SaaS. Di sepanjang jalan, Anda akan menemukan definisi yang jelas, saran praktis, dan peta jalan yang dirancang untuk menjaga integrasi Anda tetap berjalan sesuai rencana serta menghindari kesalahan umum yang sering dialami pengembang yang baru mengenal OAuth. Baik Anda baru pertama kali menjajaki maupun menyempurnakan konfigurasi perusahaan yang lanjutan, Anda berada di tempat yang tepat untuk membangun dengan percaya diri dan memahami pengenal (identifier) yang dibutuhkan aplikasi Anda.

Panduan Registrasi Aplikasi & OAuth — Definisi

Registrasi aplikasi adalah proses membuat dan mengonfigurasi identitas aplikasi pada penyedia identitas (seperti Azure AD, Google, atau Auth0) agar aplikasi dapat meminta autentikasi dan otorisasi secara aman. Proses ini biasanya mencakup penetapan client ID, client secret atau sertifikat, pendefinisian redirect URI, pengaturan izin/scope, serta konfigurasi jenis grant yang diizinkan.

8 Fakta Mengejutkan tentang Panduan Registrasi Aplikasi & OAuth

• Client secret bisa bocor melalui log: Banyak pengembang tanpa sadar mencatat client ID dan secret saat proses debugging, sehingga kredensial registrasi aplikasi menjadi rentan kecuali kebijakan logging diperketat; selalu perlakukan pengenal dengan hati-hati.
• Redirect URI lebih ketat dari yang Anda kira: Penyedia OAuth sering mensyaratkan redirect URI yang sama persis (termasuk garis miring di akhir dan skema), sehingga perbedaan kecil dapat merusak alur yang tampaknya sudah dikonfigurasi dengan benar pada registrasi aplikasi Anda.
• Public client tidak memerlukan secret, tetapi tetap perlu dilindungi: Aplikasi native dan single-page diperlakukan sebagai public client tanpa client secret, namun tetap harus menggunakan PKCE dan pendekatan redirect yang aman untuk mencegah pencegatan kode.
• Scope tidak otomatis menjamin hak akses minimal: Saat mendaftarkan aplikasi, scope default atau layar persetujuan dapat meminta izin yang luas; pembatasan scope secara eksplisit dan persetujuan bertahap (incremental consent) sangat penting untuk menerapkan prinsip hak akses minimal.
• Pencabutan token tidak didukung secara universal: Tidak semua penyedia identitas menerapkan pencabutan token atau menyediakan logout langsung di seluruh sesi, sehingga registrasi aplikasi harus mencakup manajemen sesi dan kebijakan refresh token.
• Metadata registrasi aplikasi adalah permukaan serangan: Nama aplikasi, logo, dan redirect URI yang terpapar secara publik dapat dimanfaatkan penyerang untuk menyusun phishing yang meyakinkan atau serangan open redirect jika tidak dikelola dengan cermat.
• Provisioning otomatis dapat salah mengonfigurasi izin: Otomatisasi CI/CD yang membuat registrasi aplikasi sering memberikan izin API yang terlalu longgar atau gagal mendaftarkan redirect URI yang dibutuhkan, sehingga menimbulkan kegagalan diam-diam atau paparan keamanan.
• UX persetujuan memengaruhi keputusan keamanan: Pengguna dan admin sering memberikan persetujuan yang terlalu luas karena dialog persetujuan membingungkan; merancang permintaan persetujuan yang jelas dan minimal pada registrasi aplikasi serta panduan OAuth dapat mengurangi pemberian akses yang berlebihan.

Memahami OAuth 2.0 dan Dasar-Dasar Entra ID

OAuth 2.0 adalah fondasi alur autentikasi modern yang memungkinkan aplikasi mengakses data dan sumber daya pengguna secara aman tanpa pernah melihat kata sandi. Berikut gambaran umum proses OAuth. Intinya, OAuth 2.0 mendefinisikan cara pengguna (“resource owner”), aplikasi (“client”), dan penyedia identitas (“authorization server”) bekerja sama agar pengguna tetap memegang kendali atas informasi mereka.

Lalu, bagaimana jika Anda ingin mengautentikasi pengguna, bukan sekadar memberikan otorisasi akses ke data? Di sinilah OpenID Connect berperan, dengan menambahkan lapisan identitas dan proses masuk yang aman di atas OAuth 2.0. Dengan OpenID Connect, penyedia seperti Microsoft Entra ID dan Google memungkinkan aplikasi Anda memverifikasi siapa pengguna dan meminta izin dengan cakupan tertentu untuk sumber daya tambahan, dalam satu pengalaman yang terpadu.

Jika Anda mendengar istilah seperti “client ID”, “authorization endpoint”, atau “access token”, jangan langsung kewalahan. Semuanya berkaitan dengan satu hal: siapa yang berkomunikasi dengan siapa, dan apa yang boleh mereka lakukan. Microsoft Entra ID, khususnya, menggunakan protokol ini untuk memberikan fondasi berbasis standar bagi pengembang, mulai dari aplikasi bisnis single-tenant hingga produk SaaS multi-tenant berskala besar.

Memahami dasar-dasar ini berarti Anda membangun di atas landasan yang sudah terbukti. Memilih alur OAuth yang tepat untuk skenario Anda, misalnya code flow untuk aplikasi web atau device flow untuk smart TV, memastikan proses masuk yang aman, sederhana, dan dapat dipercaya pengguna, serta tentu saja dihargai oleh tim kepatuhan Anda.

Panduan Registrasi Aplikasi & OAuth: Kesalahan Umum dengan OAuth 2.0 dan Entra ID

Panduan registrasi aplikasi & OAuth ini merangkum kesalahan yang sering dilakukan tim saat menerapkan OAuth 2.0 dengan Microsoft Entra ID (Azure AD), serta dampaknya terhadap keamanan, fungsionalitas, dan pengalaman pengguna.

• Mencampuradukkan konsep OAuth 2.0 dengan OpenID Connect (misalnya, berharap ID token diterbitkan padahal yang diterbitkan hanya access token).
• Menggunakan alur OAuth secara keliru, misalnya menganggap implicit flow sesuai untuk aplikasi modern alih-alih Authorization Code dengan PKCE.

• Mendaftarkan redirect URI dengan keliru (skema salah, garis miring di akhir, atau menggunakan localhost di lingkungan produksi).
• Menggunakan pengaturan public client untuk aplikasi confidential atau sebaliknya, yang menyebabkan error token atau membocorkan secret.
• Tidak menetapkan API permissions/scope yang benar, atau lupa memberikan persetujuan admin bila diperlukan.

• Menyisipkan client secret di kode sisi klien atau di repositori publik.
• Tidak merotasi secret/sertifikat secara berkala, atau tidak menghapus kredensial yang sudah kedaluwarsa dari registrasi aplikasi.
• Menggunakan secret berumur panjang tanpa alasan, alih-alih sertifikat berumur pendek atau managed identity.

• Tidak memvalidasi token dengan benar (issuer, audience, signature, nonce, exp).
• Menyimpan access token atau refresh token secara tidak aman (misalnya di local storage browser tanpa proteksi).
• Mempercayai isi token tanpa memverifikasi scope/role yang dikembalikan oleh Entra ID.

• Menganggap persetujuan pengguna sama dengan izin aplikasi, tanpa menyadari bahwa sebagian izin memerlukan persetujuan admin.
• Meminta izin/scope yang berlebihan, yang menimbulkan risiko tidak perlu dan meningkatkan tingkat penolakan saat persetujuan.

• Tidak menangani rotasi refresh token dan kebijakan pencabutan dari Entra ID, sehingga pengguna keluar (sign-out) secara tidak terduga.
• Menggunakan refresh token pada public client tanpa perlindungan yang memadai (gunakan PKCE dan masa berlaku token yang sesuai).

• Gagal mengonfigurasi pengaturan multi-tenant dengan benar untuk aplikasi yang dimaksudkan bekerja lintas penyewa.
• Menggunakan endpoint yang keliru (spesifik-tenant vs common) sehingga muncul masalah saat masuk atau persetujuan.

• Tidak menguji perilaku aplikasi saat Conditional Access, MFA, atau kebijakan kepatuhan perangkat diterapkan.
• Mengasumsikan token akan selalu diterbitkan dalam kondisi yang sama. Kebijakan dapat memblokir atau mewajibkan langkah autentikasi tambahan.

• Menggunakan alur OAuth lama atau pola Azure AD v1, alih-alih rekomendasi platform identitas Microsoft (v2).
• Menggunakan contoh dari komunitas tanpa memverifikasi bahwa contoh tersebut menerapkan praktik keamanan yang benar (PKCE, penyimpanan yang aman, validasi yang tepat).

• Tidak mencatat kegagalan autentikasi atau error penerbitan token, sehingga diagnosis menjadi sulit.
• Menampilkan pesan error mentah kepada pengguna, alih-alih memetakannya ke panduan yang dapat ditindaklanjuti.

Gunakan panduan pendaftaran aplikasi dan OAuth ini untuk meninjau implementasi Anda, mengikuti praktik terbaik platform identitas Microsoft, dan mengurangi risiko keamanan maupun operasional saat mengintegrasikan OAuth 2.0 dengan Entra ID.

Prasyarat Pendaftaran Aplikasi untuk Penyiapan OAuth

Sebelum memulai layar pendaftaran dan menyalin nama aplikasi Anda ke portal, periksa beberapa hal wajib terlebih dahulu. Pertama, Anda memerlukan akses ke pusat admin Microsoft Entra organisasi Anda, atau konsol yang sesuai dari penyedia identitas yang Anda gunakan. Tidak ada jalan pintas di sini. Tanpa izin yang tepat, Anda akan menemui hambatan bahkan sebelum masuk.

Berikutnya, tentukan jenis aplikasi yang Anda bangun dan identifier apa saja yang diperlukan untuk fungsinya. Apakah ini aplikasi web, single-page application, aplikasi seluler, atau mungkin layanan otomatis? Setiap jenis memiliki persyaratan sendiri terkait autentikasi dan otorisasi. Menentukan ini di awal akan membentuk pengaturan keamanan yang Anda pilih nanti.

Penting juga untuk memetakan siapa saja yang akan menggunakan aplikasi Anda. Apakah hanya orang di dalam organisasi Anda sendiri (single-tenant)? Atau perlu melayani pengguna dari bisnis lain maupun publik luas (multi-tenant)? Hal ini memengaruhi pengaturan pendaftaran, direktori pengguna yang berlaku, dan alur persetujuan (consent) yang akan dilihat pengguna Anda.

Terakhir, kumpulkan detail teknis seperti URL yang diizinkan untuk pengalihan sign-in, platform yang akan didukung (iOS, Android, Windows?), dan izin (atau "scope") yang perlu diminta aplikasi Anda. Menyelaraskan detail ini menghemat banyak waktu saat penyiapan dan menghindari kendala umum, seperti URI yang tidak valid atau jenis akun yang tidak cocok di kemudian hari.

Cara Mendaftarkan Aplikasi Anda di Microsoft Entra ID

Mendaftarkan aplikasi Anda di Microsoft Entra ID (sebelumnya Azure AD) menjadi fondasi untuk semua hal terkait autentikasi dan akses API. Prosesnya dimulai di pusat admin Entra, tempat Anda membuat pendaftaran aplikasi baru, yang memberi aplikasi Anda identitas unik (disebut "client ID") dalam direktori organisasi Anda.

Anda akan memasukkan nama untuk aplikasi Anda, lalu memilih siapa yang dapat menggunakannya: hanya organisasi Anda, beberapa organisasi, atau akun Microsoft apa pun. Langkah ini sangat penting, terutama untuk aplikasi SaaS dan B2B, karena langkah ini menentukan jangkauan aplikasi Anda dan cara persetujuan penyewa (tenant consent) dikelola.

Setelah memilih audiens, Anda mengonfigurasi detail platform aplikasi Anda. Untuk aplikasi web, Anda akan menambahkan redirect URI. Untuk aplikasi seluler atau single-page, pengaturan khusus platform memastikan pengalaman sign-in berjalan lancar. Portal Entra memandu Anda menambahkan kredensial, seperti client secret atau sertifikat, yang akan digunakan aplikasi Anda untuk membuktikan identitasnya.

Menyelesaikan pendaftaran menyelaraskan aplikasi Anda dengan standar OAuth 2.0 dan memastikan alur autentikasi Anda tetap aman dan patuh. Baik Anda memilih single-tenant maupun mengincar multi-tenant, memahami pengaturan ini sejak awal menjadi fondasi yang kuat untuk kebutuhan skalabilitas dan integrasi di masa depan.

Manfaat Utama Mendaftarkan Aplikasi Anda di Microsoft Entra ID

• Manajemen identitas terpusat: Kelola autentikasi, otorisasi, dan identitas pengguna untuk aplikasi Anda dari satu penyewa Entra ID.
• Alur OAuth yang aman: Manfaatkan dukungan bawaan OAuth 2.0 dan OpenID Connect untuk menerapkan sign-in yang aman, penerbitan token, dan akses terdelegasi.
• Single sign-on (SSO): Sediakan SSO yang mulus di seluruh Microsoft 365, Azure, dan layanan terintegrasi lainnya untuk meningkatkan pengalaman pengguna dan mengurangi permintaan kata sandi.
• Kontrol izin granular: Tentukan dan kelola izin API yang terperinci, pengalaman persetujuan, serta akses dengan hak minimum untuk izin yang didelegasikan maupun izin aplikasi.
• Akses bersyarat dan kebijakan keamanan: Terapkan MFA, kepatuhan perangkat, lokasi, dan kebijakan berbasis risiko untuk melindungi akses aplikasi dan data sensitif.
• Kelola rahasia dan kredensial aplikasi: Simpan dan rotasi client secret, sertifikat, serta konfigurasi multi-penyewa secara aman dengan praktik manajemen siklus hidup untuk menjaga integritas penggunaan aplikasi.
• Integrasi dengan layanan platform Microsoft: Akses Microsoft Graph, API Azure, Teams, dan kemampuan platform lainnya menggunakan token standar dan model persetujuan.
• Dukungan untuk aplikasi hibrida dan multi-platform: Autentikasi pengguna di skenario web, seluler, desktop, dan layanan-ke-layanan dengan protokol identitas yang konsisten, serta pastikan setiap aplikasi menggunakan identifier yang tepat.
• Pemantauan dan audit: Gunakan log, laporan masuk, dan wawasan keamanan untuk mendeteksi anomali, menyelidiki insiden, serta menjaga kepatuhan.
• Skalabilitas dan kesiapan enterprise: Manfaatkan infrastruktur global Entra ID, opsi multi-penyewa, dan fitur enterprise untuk mendukung pertumbuhan jumlah pengguna dan kebutuhan organisasi yang kompleks.
• Alat pengembang dan dokumentasi: Manfaatkan SDK, contoh kode, dan panduan pendaftaran aplikasi & oauth untuk mempercepat implementasi dan memecahkan masalah umum.

Mengonfigurasi Redirect URI dan Pengaturan Platform untuk Aplikasi Entra ID

Menetapkan redirect URI yang tepat saat pendaftaran aplikasi tampak sederhana, tetapi langkah ini sangat menentukan dari sisi keamanan. Redirect URI memberi tahu Entra ID ke mana harus mengirim pengguna (beserta token mereka) setelah percobaan login berhasil. Saat Anda mengaturnya, Entra menerapkan aturan ketat: tidak ada domain wildcard, tidak ada skema URI yang berbahaya, dan tidak ada celah yang bisa dieksploitasi penyerang.

Jika Anda membangun aplikasi halaman tunggal (SPA), Anda umumnya akan menggunakan URL HTTPS yang mengarah ke domain aplikasi Anda agar komunikasi untuk memperoleh data tetap aman. Aplikasi native memerlukan skema URI yang terikat pada nama bundle atau paket aplikasi, yang mencegah aplikasi lain di perangkat yang sama membajak token. Aplikasi web biasanya menggunakan endpoint callback login-nya, dan setiap endpoint harus didaftarkan secara eksplisit.

Kesalahan konfigurasi di sini memicu galat "redirect URI mismatch" yang klasik dan, yang lebih buruk, membuka celah bagi penyerang untuk mencegat token. Luangkan waktu untuk memetakan setiap platform tempat aplikasi Anda akan berjalan beserta redirect URI-nya masing-masing. Ini membantu memastikan autentikasi berjalan lancar dan memberi ketenangan pikiran.

Ingatlah untuk memperbarui pendaftaran aplikasi Anda setiap kali mengubah URL klien, menambahkan platform, atau memperluas lingkungan (seperti pengujian dan produksi). Menjaga URI ini tetap terkunci dan rapi adalah langkah pertama untuk memastikan alur token Anda tetap kedap.

Dasar-Dasar Alur OAuth dan Manajemen Token

OAuth 2.0 dibangun di atas serangkaian alur otorisasi yang menangani berbagai kasus penggunaan, seperti login web, masuk dari perangkat seluler, panggilan server-ke-server, atau aplikasi yang berjalan tanpa kehadiran pengguna. Yang paling populer sekaligus paling aman di antaranya adalah alur kode otorisasi, yang dirancang untuk menjaga token sensitif tetap berada di luar browser dan aplikasi seluler, dengan keamanan sebagai prioritas utama.

Setelah pengguna terautentikasi dan memberikan persetujuan, aplikasi Anda menerima kode berumur pendek. Kode ini harus ditukarkan di endpoint token untuk mendapatkan access token dan refresh token. Token-token ini memberikan akses ke data dengan batas waktu. Ketika token kedaluwarsa, refresh token dapat meminta access token baru agar sesi Anda tetap aktif.

Manajemen token bukan sekadar menangani tanggal kedaluwarsa; ini tentang menjaga keamanan token di setiap tahapnya. Hal ini mencakup penggunaan komunikasi aman (seperti HTTPS), tidak pernah mengekspos rahasia dalam kode sisi klien, dan menerapkan prinsip hak akses minimum saat meminta scope.

Bagian ini mempersiapkan Anda untuk memahami bagaimana OAuth menangani jabat tangan penting antara pengguna, aplikasi, dan platform, serta bagaimana manajemen token yang andal mendukung alur kerja yang persisten dan aman, baik untuk pengguna akhir maupun sistem otomatis.

Menerapkan Alur Kode Otorisasi OAuth

1. Mulai otorisasi: Aplikasi Anda mengarahkan pengguna ke endpoint otorisasi Entra ID, dengan menyertakan detail seperti client ID Anda, scope yang diminta, dan parameter state yang unik dan acak untuk perlindungan CSRF.
2. Pengguna memberikan izin: Pengguna meninjau layar persetujuan, yang dengan jelas menampilkan izin apa saja yang dibutuhkan aplikasi Anda, lalu menyetujui akses tersebut.
3. Menerima kode otorisasi: Setelah persetujuan diberikan, Entra ID mengarahkan kembali ke redirect URI yang telah Anda tentukan, dengan membawa kode otorisasi sementara serta nilai state yang awalnya Anda atur.
4. Menukar kode dengan token: Backend Anda mengirimkan kode tersebut secara aman, bersama kredensial klien Anda (dan PKCE code verifier jika digunakan), ke token endpoint Entra. Jika terverifikasi, Anda akan menerima access token (dan sering kali refresh token).
5. Menggunakan token untuk mengakses API: Aplikasi Anda kini melampirkan access token pada setiap permintaan API, sebagai bukti otorisasi atas nama pengguna. Access token hanya berlaku dalam waktu singkat untuk meminimalkan paparan, sementara refresh token digunakan untuk memperoleh access token baru guna menjaga sesi yang berkelanjutan.

Menjalankan langkah-langkah ini dengan urutan yang benar akan menutup celah keamanan dan membantu mencegah serangan seperti intersepsi kode atau penyalahgunaan token, terutama saat Anda bekerja dengan public client atau menangani data sensitif.

Praktik Terbaik untuk Mengelola Masa Berlaku Access dan Refresh Token

1. Simpan token dengan aman: Gunakan solusi penyimpanan aman yang disediakan OS, seperti Keychain di iOS, Keystore di Android, atau secrets manager terenkripsi di server. Jangan pernah menyimpan token secara hard-code di dalam binary aplikasi atau menampilkannya di log.
2. Perhatikan masa berlaku token: Pantau nilai kedaluwarsa (klaim exp) pada setiap token, dan perbarui token secara proaktif sebelum kedaluwarsa agar permintaan API tidak gagal dan pengalaman pengguna tetap baik.
3. Dukung rotasi token: Selalu gunakan refresh token terbaru pada setiap permintaan; segera buang token yang digunakan ulang atau sudah usang. Langkah ini membatasi dampak jika sebuah token berhasil dikompromikan.
4. Batasi izin per token: Minta hanya scope yang benar-benar dibutuhkan dan utamakan access token yang berumur pendek. Langkah ini secara signifikan mengurangi kerugian jika sebuah token bocor atau dicuri.

Mengamankan Implementasi OAuth dalam Berbagai Konteks

Mengintegrasikan OAuth dengan benar bukan sekadar mencentang langkah-langkah, melainkan membangun lapisan keamanan yang sesuai dengan arsitektur dan pola penggunaan aplikasi Anda. Baik aplikasi Anda berjalan di browser, di ponsel, maupun sepenuhnya di cloud, Anda memerlukan strategi autentikasi yang disesuaikan untuk setiap konteks.

Teknologi seperti PKCE (Proof Key for Code Exchange) mengunci alur kode untuk public client, sehingga mencegah penyerang mencegat kode dan menukarnya dengan token. Di sisi lain, untuk aplikasi yang berjalan di lingkungan aman, client secret dan sertifikat menjadi alat terbaik untuk membuktikan identitas dan mengelola kepercayaan.

Penyimpanan token yang cermat dan pengawasan ketat terhadap tingkat privilese membantu mencegah kebocoran yang tidak disengaja serta membatasi potensi dampak jika terjadi kesalahan. Dengan memilih alat keamanan yang tepat, yaitu PKCE, secret, sertifikat, dan pembatasan scope yang benar, Anda secara signifikan mengurangi attack surface dan meningkatkan peluang operasi yang lancar serta patuh terhadap regulasi.

Berikut ini adalah strategi yang sudah teruji untuk menangkal ancaman umum dan menyesuaikan konfigurasi OAuth Anda agar terlindungi dengan kokoh di berbagai jenis aplikasi dan lingkungan.

Cara PKCE Melindungi Otorisasi OAuth pada Public Client

PKCE (Proof Key for Code Exchange) sangat penting saat menggunakan OAuth pada aplikasi seluler dan aplikasi berbasis browser, yaitu public client yang tidak memungkinkan penyimpanan secret. Saat Anda memulai alur authorization code, aplikasi akan membuat "code verifier" acak dan "code challenge" yang sudah di-hash. Nilai-nilai ini dibawa bersama alur pengguna hingga permintaan token akhir. Meskipun penyerang berhasil mendapatkan authorization code, mereka tidak dapat menukarnya dengan token tanpa secret verifier tersebut, sehingga serangan intersepsi kode hampir mustahil dilakukan pada Microsoft Entra ID dan platform serupa.

Mengelola Client Secret, Sertifikat, dan Federated Credential

• Client Secret: Digunakan oleh confidential app, seperti layanan backend tepercaya, untuk membuktikan identitasnya di token endpoint. Simpan secret di vault yang aman, rotasi secara berkala, dan jangan pernah menyertakannya dalam kode aplikasi sisi klien.
• Sertifikat: Untuk tingkat keyakinan yang lebih tinggi, gunakan sertifikat X.509 alih-alih secret biasa guna meningkatkan keamanan identifier aplikasi Anda. Sertifikat memungkinkan validasi yang lebih aman melalui pasangan kunci publik/privat dan sangat cocok untuk industri yang diatur ketat atau aplikasi dengan tuntutan kepatuhan yang ketat.
• Federated Credential: Untuk skenario "bring your own identity", gunakan federated credential seperti federated identity dari Microsoft Entra atau penyedia eksternal. Cara ini memungkinkan autentikasi tanpa harus menangani secret secara langsung, sehingga beban pengelolaan berkurang.
• Penanganan di Pipeline: Dalam alur kerja CI/CD, sisipkan dan rotasi secret/sertifikat sesuai kebutuhan, dan jangan pernah melakukan hard-code di source control. Peringatan kedaluwarsa otomatis menambah lapisan ketahanan lainnya.

Mengamankan Token dan Mengurangi Paparan Hak Akses

• Simpan token hanya di lokasi yang aman (vault sistem operasi, lingkungan server terenkripsi), jangan pernah di penyimpanan yang dapat diakses pengguna.
• Selalu kirim token melalui HTTPS atau saluran aman; HTTP biasa membuka token untuk disadap.
• Minta izin minimal ("scopes") untuk setiap token; jangan pernah meminta lebih dari yang dibutuhkan aplikasi Anda.
• Audit penggunaan token dan penetapan hak akses secara berkala untuk mencegah perluasan izin yang tidak disadari.

Praktik Terbaik OAuth pada Aplikasi Seluler dan Native

Aplikasi seluler dan native saat ini menghadapi tantangan khusus: perangkat bisa hilang, aplikasi berbagi ruang penyimpanan, dan pengguna mengharapkan proses masuk yang cepat dan nyaris tidak terlihat. Itulah sebabnya mengikuti praktik terbaik OAuth di iOS, Android, dan desktop, dengan menggunakan SDK bawaan dan mekanisme penyimpanan yang terbukti andal, memberikan perbedaan yang sangat besar.

SDK yang tepat (seperti MSAL untuk Microsoft Entra ID) menangani sebagian besar pekerjaan berat: mengelola token, menangani logika refresh, dan terintegrasi dengan penyimpanan aman tingkat sistem operasi. Untuk token sensitif, SDK ini secara default memilih penyimpanan yang paling aman, sekaligus menangani keunikan khusus perangkat atau sistem operasi.

Jangan abaikan UX yang mulus: universal links, deep links, dan alur browser sistem membantu pengguna menyelesaikan proses masuk tanpa kebingungan atau risiko phishing. Jika dikonfigurasi dengan benar, aplikasi Anda mengarahkan pengguna ke tampilan web sistem yang aman dan tepercaya, lalu membawa mereka kembali ke dalam aplikasi dengan aman setelah proses masuk selesai, tanpa pop-up dan tanpa kebocoran token.

Praktik-praktik ini dirancang tidak hanya untuk menjaga keamanan token, tetapi juga untuk membangun kepercayaan pengguna akhir, yang pada akhirnya meningkatkan tingkat adopsi dan mengurangi beban dukungan di kemudian hari.

Universal Links dan Autentikasi Native First-Party

Universal links (di iOS) dan skema aplikasi (di Android) membuat autentikasi pengguna jauh lebih aman. Dengan menggunakan tautan yang diverifikasi OS dan terikat pada identitas aplikasi Anda, aplikasi nakal tidak bisa lagi mencegat pengalihan proses masuk dan mengambil token yang bukan miliknya. Autentikasi native memanfaatkan browser sistem tepercaya sehingga yang masuk adalah pengguna yang sebenarnya, sehingga phishing, penyadapan token, dan login tidak sengaja di antara aplikasi yang tidak berhubungan dapat dihindari. Kombinasi keduanya memberi pengguna pengalaman yang mulus dan aman, yang hampir kebal terhadap ancaman OAuth umum di perangkat seluler.

Mengatasi Error OAuth dan Skenario Lanjutan

Integrasi OAuth hampir tidak pernah berjalan sempurna pada percobaan pertama; error dan kasus tepi yang aneh adalah bagian dari prosesnya. Seringkali, masalah muncul dari ketidakcocokan redirect URI, kode yang kedaluwarsa, atau client secret yang salah, yang dapat menghentikan alur autentikasi dan memengaruhi penggunaan aplikasi. Bagian ini akan membantu Anda membaca respons error, melacak pertukaran yang gagal, dan menyelesaikan masalah sebelum sampai ke helpdesk Anda.

Selain dasar-dasarnya, beberapa skenario, seperti komunikasi aplikasi server-ke-server, proses masuk perangkat IoT, atau kebutuhan akan jaminan protokol yang lebih kuat, memerlukan ekstensi OAuth khusus atau alur nonInteraktif. Service account, mutual TLS, dan device code flow dirancang khusus untuk memenuhi kebutuhan tersebut.

Dengan panduan untuk kegagalan umum maupun kasus penggunaan lanjutan, Anda akan lebih siap untuk memecahkan masalah, merancang, dan memelihara solusi OAuth yang andal, meskipun ekosistem aplikasi Anda semakin kompleks.

Baik Anda sedang memburu error endpoint token yang membandel atau mempersiapkan aplikasi Anda menghadapi kerumitan dunia nyata (tempat perangkat dengan input terbatas dan layanan tanpa antarmuka tersebar di mana-mana), wawasan ini akan membantu integrasi Anda tetap lancar dan aman.

Memahami Respons Error OAuth dan Kegagalan Pertukaran Kode

• Invalid redirect URI: Terjadi ketika redirect tidak cocok dengan daftar yang terdaftar; periksa kembali input dan kapitalisasinya.
• Expired authorization code: Pengguna terlalu lama atau kode digunakan ulang; selalu gunakan kode hanya sekali dan segera setelah diterima.
• Mismatched client credentials: Secret atau sertifikat yang diberikan salah; periksa dan rotasi kredensial sesuai kebutuhan.
• Invalid scope or resource: API atau scope yang diminta tidak diizinkan atau salah ketik; verifikasi konfigurasi dan izin aplikasi.

Service Accounts, Perangkat Input Terbatas, dan Ekstensi OAuth

• Service account (client credentials flow): Memungkinkan aplikasi melakukan autentikasi tanpa pengguna; sangat cocok untuk otomatisasi dan tugas server-ke-server.
• Device code flow: Untuk smart TV dan IoT, meminta pengguna melanjutkan di perangkat lain; cocok untuk kondisi tanpa browser.
• Mutual TLS extension: Menggunakan sertifikat untuk server dan klien sekaligus, meningkatkan keamanan untuk integrasi sensitif serta memastikan aplikasi menggunakan metode autentikasi yang kuat.
• Registrasi klien dinamis: Mengotomatiskan proses onboarding aplikasi di sistem SaaS besar atau multi-penyewa, sehingga pengelolaan kredensial dalam skala besar menjadi lebih sederhana.

Panduan App Registration & OAuth di Entra ID

Kelebihan

• Manajemen identitas terpusat: terintegrasi dengan Microsoft Entra ID untuk identitas pengguna dan aplikasi yang konsisten di seluruh layanan.
• Kontrol keamanan yang kuat: mendukung OAuth 2.0, OpenID Connect, akses bersyarat, dan izin yang sangat rinci (scope dan peran).
• Protokol standar industri: memanfaatkan standar OAuth/OIDC yang didukung luas, sehingga interoperabilitas dengan alat dan library pihak ketiga menjadi lebih mudah.
• Konfigurasi aplikasi yang detail: memungkinkan pengaturan redirect URI, sertifikat & rahasia, izin API, dan opsi branding untuk aplikasi.
• Model persetujuan yang granular: mendukung izin delegated dan application dengan alur persetujuan admin untuk membatasi aplikasi yang memiliki izin berlebihan.
• Fitur kelas enterprise: mendukung aplikasi multi-penyewa, kolaborasi B2B, serta integrasi dengan Microsoft 365 dan layanan Azure.
• Pemantauan dan audit: tersedia log, sign-in, dan jejak audit bawaan untuk registrasi aplikasi dan alur OAuth, yang membantu kepatuhan dan pemecahan masalah.
• Alat pengembang dan SDK: tersedia banyak SDK Microsoft identity platform, dokumentasi, dan contoh quickstart yang mempercepat implementasi.

Kekurangan

• Kompleks bagi pemula: konfigurasi dan model izin (redirect URI, reply URL, implicit vs. authorization code flow, scope) bisa membingungkan bagi pengembang baru.
• Kurva belajar yang curam untuk fitur keamanan: akses bersyarat, managed identity, dan pengaturan token lanjutan memerlukan pengetahuan keamanan yang lebih dalam agar dapat dikonfigurasi dengan aman.
• Risiko penumpukan izin: persetujuan yang tidak tepat atau izin aplikasi yang terlalu luas dapat menghasilkan aplikasi dengan izin berlebihan jika tidak ditinjau secara rutin.
• Seluk-beluk pengelolaan token: penanganan refresh token, masa berlaku token, dan pencabutan token memiliki perilaku yang berbeda di setiap platform sehingga dapat menimbulkan masalah integrasi.
• Pertimbangan batas penyewa: perilaku aplikasi multi-penyewa dan permintaan persetujuan admin menambah kompleksitas operasional untuk skenario lintas penyewa.
• Perubahan UI dan istilah: Microsoft secara berkala memperbarui antarmuka dan penamaan Entra (Azure AD → Entra ID), yang dapat menyebabkan dokumentasi tidak sesuai atau membingungkan.
• Ketergantungan pada ekosistem Microsoft: keterikatan yang erat dengan fitur Entra ID dapat membatasi portabilitas ke penyedia identitas non-Microsoft tanpa perlu pengerjaan ulang.
• Potensi kesalahan konfigurasi: pengaturan registrasi aplikasi yang tidak tepat (misalnya redirect URI, reply URL, atau pengaturan implicit flow) dapat menciptakan celah keamanan atau merusak alur autentikasi.

Langkah Selanjutnya dan Sumber Daya Komunitas Utama untuk Keberhasilan OAuth

Oke, OAuth sudah terpasang dan berjalan, tetapi jangan kendurkan dulu. Pastikan aplikasi Anda untuk mendapatkan token sudah dikonfigurasi dengan benar. Menyiapkan dasar-dasarnya baru langkah pertama. Jika Anda ingin aplikasi Anda menonjol dan membuat pengguna tetap aman, saatnya mendalami fitur-fitur tambahannya. Mulailah dengan library klien yang lebih canggih, cobalah Microsoft Graph, dan jelajahi fitur identitas terbaru yang dapat membuat integrasi Anda lebih kuat, dan lebih lancar bagi semua pihak.

Anda juga tidak harus memecahkannya sendirian. Dokumentasi Microsoft Entra ID sedalam Danau Michigan, berisi panduan yang selalu diperbarui, contoh kode, dan spesifikasi teknis yang kemungkinan besar Anda butuhkan. Biasakan diri untuk memeriksa pembaruan, terutama karena standar OAuth dan identitas cloud terus berubah.

Sudah puas dengan registrasi aplikasi Anda? Bagus. Sekarang, lihat bagaimana para praktisi di lapangan berkreasi. Telusuri forum pengembang, papan diskusi resmi, dan bahkan repo GitHub untuk library autentikasi. Jika Anda menemui jalan buntu, kemungkinan besar orang lain sudah menyelesaikan masalah yang sama persis, atau setidaknya pernah mengeluhkannya dengan cukup keras sehingga ada yang menjawab.

Jika Anda tipe yang suka bereksperimen dan belajar dengan praktik langsung, manfaatkan uji coba gratis, tenant uji, dan fitur public preview yang tersedia. Fitur-fitur ini memungkinkan Anda bereksperimen (dengan aman) dan mengetahui apa yang berhasil sebelum menerapkan perubahan ke pengguna sungguhan. Dan jangan lupa, OAuth dan keamanan adalah upaya bersama komunitas, jadi bagikan keberhasilan dan pertanyaan Anda. Hal ini akan membuat seluruh ekosistem tetap jujur dan terus berkembang, serta membantu semua orang memahami alur kerja OAuth.

Checklist App Registration & OAuth Guide - Entra ID

• Rencanakan jenis aplikasi dan model akses: tentukan antara single-tenant, multi-tenant, atau akun Microsoft pribadi, serta tentukan apakah aplikasinya berjenis SPA, web app, mobile, daemon, atau service app.
• Daftarkan aplikasi di Entra ID: buat App Registration baru dengan nama yang jelas dan jenis akun yang didukung.
• Konfigurasikan URI pengalihan: tambahkan URI redirect/callback yang benar untuk setiap platform (https, skema kustom, localhost untuk pengembangan).
• Atur pengaturan platform aplikasi: aktifkan opsi platform SPA, web, mobile & desktop, lalu konfigurasikan implicit/grant flow sesuai kebutuhan.
• Buat dan kelola rahasia klien: hasilkan client secret untuk confidential client, catat masa berlakunya, dan simpan dengan aman (Key Vault).
• Gunakan sertifikat untuk autentikasi: unggah sertifikat kunci publik untuk confidential client produksi, sebagai pengganti rahasia dengan masa berlaku panjang.
• Konfigurasikan izin API: tambahkan scope dan izin Microsoft Graph atau API kustom yang dibutuhkan aplikasi.
• Berikan persetujuan admin jika diperlukan: ajukan dan catat persetujuan admin untuk izin delegated yang memerlukan persetujuan di seluruh penyewa.
• Definisikan dan ekspos scope kustom (jika aplikasi berupa API): tambahkan scope di bawah “Expose an API” dan tentukan nama scope, deskripsi, serta nama tampilan persetujuan admin.
• Siapkan app role (jika diperlukan): definisikan peran application dan delegated untuk kontrol akses berbasis peran, lalu tetapkan ke pengguna, grup, atau aplikasi klien.
• Konfigurasikan CORS untuk SPA yang memanggil API: tambahkan origin yang diizinkan pada API, atau konfigurasikan kebijakan CORS di gateway.
• Pilih alur OAuth 2.0: pilih Authorization Code (dengan PKCE untuk public client), Client Credentials untuk aplikasi daemon, atau Device Code sesuai kebutuhan.
• Terapkan PKCE untuk public client: wajibkan Proof Key for Code Exchange untuk SPA dan aplikasi native guna mencegah intersepsi kode.
• Validasi token dengan benar: periksa issuer, audience, tanda tangan, masa berlaku, dan klaim yang diperlukan menggunakan library identitas Microsoft atau logika validasi JWT.
• Gunakan Microsoft Authentication Libraries (MSAL): utamakan MSAL untuk perolehan token, caching, refresh, dan penanganan yang aman di berbagai platform.
• Konfigurasikan conditional access dan MFA (jika diperlukan): terapkan kebijakan pada app registration atau alur sign-in pengguna untuk menegakkan kontrol keamanan.
• Pantau sign-in dan audit log: aktifkan logging dan tinjau peristiwa sign-in, persetujuan, serta operasi admin di log Entra ID.
• Terapkan izin dengan hak akses minimal: minta hanya izin yang dibutuhkan dan utamakan incremental consent untuk meminimalkan paparan.
• Rotasi rahasia dan sertifikat secara berkala: terapkan rotasi otomatis dan pemberitahuan untuk kredensial yang akan kedaluwarsa.
• Amankan kode dan penyimpanan sisi klien: hindari menyimpan rahasia di aplikasi klien, gunakan penyimpanan aman, dan ikuti praktik terbaik platform.
• Uji alur sign-in dan token di lingkungan dev/staging: validasi alur autentikasi, masa berlaku token, logika refresh, penanganan error, dan pengalaman persetujuan.
• Siapkan dokumentasi untuk pengguna dan admin: sertakan langkah persetujuan, izin yang dibutuhkan, dan panduan pemecahan masalah.
• Tinjau dan perbarui app registration secara berkala: audit izin, peran, rahasia, dan registrasi untuk aplikasi yang sudah usang atau tidak digunakan.
• Terapkan proteksi jaringan dan API: pertimbangkan API Management, WAF, rate limiting, dan service endpoint untuk melindungi API backend.

Penggunaan token akses Azure OAuth auth

Apa itu app registration & panduan oauth dan mengapa penting?

Panduan app registration & oauth menjelaskan cara mendaftarkan aplikasi klien ke identity provider (misalnya menggunakan Azure) dan menerapkan alur otorisasi OAuth 2.0 agar aplikasi Anda dapat meminta akses ke sumber daya yang dilindungi secara aman. Ini sangat penting baik Anda membangun aplikasi web, single-page app, aplikasi desktop, maupun backend web server, karena aplikasi memerlukan application id atau app id, serta client id dan client secret (untuk confidential client), untuk memperoleh access token dan menerima ID token bila diperlukan.

Bagaimana cara mendaftarkan aplikasi Azure dan memperoleh application id dan app id?

Untuk mendaftarkan aplikasi Azure, buka Azure portal, buat app registration baru, berikan nama dan URI redirect, lalu catat client id (application id) yang ditampilkan di ringkasan aplikasi. Jika aplikasi Anda adalah confidential client (web server atau web tradisional), buat client secret untuk digunakan bersama client id dan client secret. Aplikasi yang telah didaftarkan ini digunakan dalam otorisasi dan untuk meminta access token dari layanan Microsoft.

Alur otorisasi OAuth 2.0 mana yang sebaiknya saya gunakan untuk single-page app?

Aplikasi single-page sebaiknya menggunakan grant kode otorisasi dengan PKCE (proof key for code exchange), bukan implicit flow, agar aplikasi yang memperoleh token tetap aman. Code grant dengan PKCE memungkinkan aplikasi menukar kode menjadi access token secara aman dari klien berbasis browser, sehingga aplikasi single-page dapat menggunakan OAuth tanpa mengekspos client secret di browser.

Bagaimana cara kerja permintaan otorisasi dan parameter apa saja yang diperlukan?

Permintaan otorisasi dikirim ke authorization endpoint dari identity provider dan biasanya menyertakan client_id (ID aplikasi), response_type (misalnya code), redirect_uri, scope, dan state. Untuk aplikasi single-page yang menggunakan code grant dengan PKCE, Anda juga menyertakan code_challenge dan code_challenge_method. Pengguna melakukan autentikasi dan memberikan persetujuan (OAuth consent), lalu authorization server mengembalikan kode ke redirect URI, yang kemudian dapat ditukar aplikasi menjadi access token.

Bagaimana cara menulis kode untuk menukar kode otorisasi dengan access token?

Setelah menerima kode otorisasi, aplikasi klien mengirim permintaan ke token endpoint yang berisi code, client_id (dan client_secret untuk confidential client), redirect_uri, serta grant_type=authorization_code. Untuk PKCE, Anda juga menyertakan code_verifier. Token endpoint merespons dengan access token, id token (jika diminta), dan mungkin refresh token untuk memperoleh access token baru saat access token sudah kedaluwarsa.

Bagaimana cara memperoleh access token dan menggunakannya untuk memanggil API?

Peroleh access token dengan menyelesaikan alur OAuth 2.0 yang Anda pilih lalu memanggil token endpoint. Setelah memiliki access token, kirimkan di header Authorization dengan format Bearer saat memanggil layanan Microsoft atau API lain (misalnya Google Calendar atau API kustom). Verifikasi token di sisi web server atau resource untuk memastikan permintaan aplikasi memang berwenang.

Apa yang harus dilakukan ketika access token kedaluwarsa, dan bagaimana cara memperoleh refresh token baru?

Saat access token kedaluwarsa, gunakan refresh token (jika tersedia) untuk meminta access token dari token endpoint dengan grant_type=refresh_token. Beberapa alur atau penyedia layanan mungkin menerbitkan refresh token baru saat proses refresh, sementara yang lain menggunakan kembali refresh token yang sama. Jika tidak ada refresh token (misalnya public client atau alur berumur pendek), arahkan kembali pengguna ke aplikasi Anda untuk melakukan permintaan otorisasi baru.

Apakah saya perlu membuat pendaftaran aplikasi terpisah untuk aplikasi web dan aplikasi mobile atau desktop?

Sering kali pendaftaran aplikasi terpisah diperlukan ketika jenis aplikasinya sangat berbeda, misalnya web server tradisional, single-page app, dan aplikasi desktop, karena redirect URI, client secret, serta alur yang diizinkan berbeda-beda. Dengan pendaftaran aplikasi terpisah, Anda dapat mengatur alur otorisasi dan redirect URI yang spesifik untuk setiap jenis aplikasi.

Apa perbedaan antara pendaftaran aplikasi klien dan aplikasi di dalam penyewa?

Pendaftaran aplikasi klien merujuk pada entri pendaftaran tertentu di identity provider (aplikasi Azure) yang menyimpan konfigurasi seperti redirect URI dan secret. Aplikasi di dalam penyewa menunjukkan bahwa pendaftaran tersebut berada di penyewa Azure AD tertentu dan dapat diberi peran serta izin di dalam penyewa tersebut. Satu pendaftaran aplikasi dapat bersifat multi-tenant atau single-tenant, tergantung kebutuhan Anda.

Bagaimana cara meminta akses ke layanan Microsoft dan izin apa yang diperlukan?

Mintalah akses dengan menentukan scope yang dibutuhkan aplikasi Anda dalam permintaan otorisasi. Untuk layanan Microsoft, konfigurasikan izin API pada pendaftaran aplikasi Azure, lalu minta pengguna memberikan persetujuan (OAuth consent) atau minta admin memberikan persetujuan untuk seluruh penyewa. Aplikasi meminta scope seperti User.Read atau scope API kustom dalam permintaan aplikasi, lalu menggunakan access token untuk memanggil layanan tersebut.

Bagaimana cara mengamankan client secret dan mencegah kebocoran kredensial di single-page app?

Single-page app sebaiknya tidak menyimpan client secret karena kode yang berjalan di browser dapat diperiksa oleh siapa pun. Gunakan code grant dengan PKCE agar aplikasi dapat memperoleh access token secara aman tanpa client secret. Untuk aplikasi confidential (web server), simpan client ID dan client secret di sisi server agar tidak terekspos kepada pengguna.

Apa peran redirect URI, dan mengapa harus sesuai dengan pendaftaran aplikasi?

URI pengalihan (redirect URI) adalah tempat penyedia identitas mengirimkan respons otorisasi (kode atau token). URI ini harus cocok dengan URI pengalihan yang didaftarkan di pendaftaran aplikasi untuk mencegah pembajakan respons otorisasi. Gunakan pencocokan persis atau pola yang diizinkan sebagaimana ditentukan oleh penyedia; ketidakcocokan akan menyebabkan pertukaran token gagal.

Bagaimana cara membuat pengguna melakukan autentikasi dan menerima id token selain access token?

Untuk menerima id token, minta scope openid dan sertakan response_type yang memicu penerbitan id token (alur kode otorisasi dengan openid). Id token berisi klaim identitas tentang pengguna yang telah terautentikasi. Gunakan id token untuk masuk ke aplikasi klien Anda dan access token untuk memanggil API hilir.

Alur otorisasi spesifik apa yang berlaku untuk aplikasi web tradisional dibandingkan aplikasi single page?

Aplikasi web tradisional (sisi server) umumnya menggunakan alur kode otorisasi dengan kredensial klien (client id dan client secret) dan menukar kode di server web. Aplikasi single page menggunakan kode otorisasi dengan PKCE dan tanpa client secret. Aplikasi desktop juga menggunakan PKCE. Pilih alur berdasarkan jenis aplikasi dan lokasi penyimpanan rahasia yang aman.

Apakah satu pendaftaran aplikasi dapat digunakan untuk beberapa aplikasi klien, atau sebaiknya saya membuat satu pendaftaran aplikasi untuk setiap aplikasi?

Anda dapat menggunakan satu pendaftaran aplikasi untuk beberapa aplikasi klien jika mereka berbagi konfigurasi dan URI pengalihan yang sama. Namun, praktik terbaik sering merekomendasikan pendaftaran aplikasi terpisah untuk aplikasi yang berbeda (pendaftaran aplikasi terpisah) guna mengisolasi izin, URI pengalihan, dan pengelolaan siklus hidup. Pertimbangkan apakah aplikasi mungkin memerlukan cakupan izin atau perilaku persetujuan admin yang berbeda.

Bagaimana cara memvalidasi token di server web atau API saya?

Server web atau API Anda harus memvalidasi tanda tangan, penerbit (issuer), audiens (audience; app id atau application id), dan masa berlaku dari access token atau id token. Gunakan dokumen discovery penyedia untuk memperoleh kunci penandatanganan dan ikuti pustaka validasi yang direkomendasikan untuk platform Anda. Validasi memastikan hanya permintaan dari aplikasi yang terautentikasi dan berwenang yang diterima.

Apa prosesnya untuk meminta access token bagi layanan backend menggunakan kredensial klien?

Untuk skenario server-ke-server, daftarkan aplikasi Azure, berikan izin aplikasi kepadanya, lalu gunakan alur kredensial klien: kirim POST ke token endpoint dengan grant_type=client_credentials, client_id, client_secret, dan scope/resource. Token endpoint akan mengembalikan access token yang dapat digunakan backend untuk memanggil layanan Microsoft atau API yang dilindungi.

Bagaimana cara menangani persetujuan OAuth dan persetujuan admin untuk aplikasi multi-penyewa?

Ketika aplikasi Anda didaftarkan sebagai multi-penyewa, pengguna dari penyewa lain dapat menyetujui izin delegasi selama permintaan otorisasi. Untuk izin yang memerlukan persetujuan admin, seorang administrator harus memberikan persetujuan untuk penyewanya. Sertakan petunjuk dan URL persetujuan bagi admin penyewa agar dapat memberikan persetujuan OAuth dalam skala besar.

Langkah pemecahan masalah apa yang sebaiknya saya lakukan jika permintaan otorisasi saya gagal?

Pastikan aplikasi sudah didaftarkan di portal Microsoft, URI pengalihan cocok, client id dan secret benar, scope valid, serta parameter grant type dan PKCE (jika digunakan) sudah benar. Periksa pesan kesalahan yang dikembalikan oleh authorization endpoint atau token endpoint, dan lihat log di sisi klien maupun server. Stack Overflow dan dokumentasi penyedia dapat membantu untuk kode kesalahan tertentu.

Bagaimana cara mengintegrasikan API pihak ketiga seperti Google Calendar dengan aplikasi terdaftar saya?

Untuk mengintegrasikan Google Calendar atau API pihak ketiga lainnya, terapkan alur otorisasi OAuth 2.0 yang disyaratkan oleh penyedia tersebut. Aplikasi Anda harus meminta scope yang benar untuk API pihak ketiga dan menangani siklus hidup token yang terpisah. Anda mungkin perlu mendaftarkan aplikasi klien terpisah pada setiap penyedia dan mengoordinasikan perolehan access token untuk setiap layanan.

Kapan sebaiknya saya menggunakan device code flow atau alur khusus lainnya untuk perangkat tertentu?

Gunakan device code flow untuk perangkat dengan input terbatas yang tidak memiliki browser. Alur perangkat memungkinkan pengguna mengunjungi URL verifikasi di perangkat lain untuk melakukan autentikasi. Alur ini merupakan salah satu alur otorisasi khusus yang didukung di samping kode otorisasi, kredensial klien, dan refresh token untuk mengakomodasi berbagai jenis faktor bentuk aplikasi.