Kunci API vs OAuth 2.0: bandingkan upaya onboarding, rotasi token, akses per pengguna, dan auditabilitas agar pengembang mitra dapat mengintegrasikan dengan aman.
Ketika orang membandingkan kunci API dan OAuth 2.0, terdengar seperti debat murni soal keamanan. Untuk integrasi mitra, ini juga soal operasional: seberapa cepat mitra bisa mulai, bagaimana Anda mengendalikan akses nanti, dan seberapa menyakitkan dukungan saat sesuatu rusak.
Sebagian besar integrasi membutuhkan hal-hal dasar yang sama: cara autentikasi yang andal, batasan yang jelas (rate limit dan izin), serta keterlacakan sehingga Anda bisa menjawab “siapa melakukan apa” tanpa menebak. Metode otentikasi yang Anda pilih menentukan apakah kebutuhan itu mudah terpenuhi sejak awal atau harus Anda tambahkan dengan aturan ekstra, dashboard, dan proses manual.
Beberapa istilah sederhana membantu agar diskusinya praktis:
Keputusan sesungguhnya adalah peran apa yang dimainkan integrasi itu.
Jika itu bersifat mesin-ke-mesin, kunci API sering cocok. Contoh: mitra menjalankan sinkron malam dari server mereka ke API Anda. Tidak ada pengguna akhir yang mengklik “Setuju”. Anda biasanya peduli tentang akses level mitra, rotasi yang bisa diprediksi, dan onboarding yang cepat.
Jika itu delegasi pengguna, OAuth 2.0 biasanya lebih cocok. Contoh: pelanggan menghubungkan akunnya di aplikasi mitra, dan setiap pelanggan hanya boleh memberi akses ke data mereka sendiri. Anda biasanya peduli tentang izin per pengguna, pencabutan yang mudah, dan jejak audit yang lebih bersih.
Pilihan itu mengubah beban dukungan Anda. Dengan kunci, Anda akan menghabiskan lebih banyak waktu untuk berbagi kunci, koordinasi rotasi, dan melacak kunci milik lingkungan mitra mana. Dengan OAuth, Anda akan menghabiskan lebih banyak waktu pada flow persetujuan dan pengaturan redirect, tapi lebih sedikit waktu menebak manusia atau tenant mana yang memicu sebuah aksi.
Jika Anda membangun backend integrasi di alat seperti AppMaster, rencanakan otentikasi sejak awal. Ini memengaruhi model data Anda (mitra, pengguna, scope) dan log audit yang akan Anda inginkan sejak hari pertama.
Kunci API adalah cara termudah untuk membiarkan mitra memanggil API Anda. Kunci biasanya unggul dari sisi kecepatan: Anda memberikan string rahasia, mitra menyertakannya dalam permintaan, dan Anda bisa mulai bertukar data.
Sebagian besar waktu, kunci API mewakili aplikasi mitra (atau sebuah integrasi), bukan pengguna akhir tertentu. Jika mitra memiliki satu kunci untuk seluruh tim mereka dan semua pelanggan mereka, setiap permintaan terlihat sama dari pihak Anda: “Mitra X”. Itu membuat setup mudah, tapi aksesnya kasar.
Dalam praktiknya, kunci diterbitkan di konsol admin atau melalui langkah provisioning satu kali. Mitra kemudian menyimpannya di file konfigurasi, environment variable, atau secrets manager. Risikonya adalah seberapa sering kunci “sementara” akhirnya disalin ke spreadsheet bersama, ditempel di chat, atau disertakan di kode sisi klien.
Keterbatasan muncul cepat. Izin cenderung luas, kunci adalah kredensial bersama (jadi Anda tidak bisa mengatribusikan aksi ke seseorang dengan andal), rotasi memerlukan koordinasi, dan kunci yang bocor memungkinkan penyerang bertindak sebagai mitra sampai Anda mencabutnya.
Contoh: mitra logistik menjalankan impor malam dari server mereka. Dengan satu kunci API, mereka menarik pesanan dan mendorong pembaruan status. Saat ada masalah, log Anda menunjukkan kunci mitra, bukan apakah itu uji developer, job terjadwal, atau mesin yang dikompromikan.
Kunci API bisa bekerja baik untuk integrasi server-ke-server dengan serangkaian aksi yang stabil, terutama bila Anda bisa membatasi kunci ke IP tertentu, endpoint tertentu, atau lingkungan (test vs produksi). Jika Anda membangun lapisan API di alat seperti AppMaster, kunci seringkali langkah awal yang baik untuk percobaan mitra cepat. Tentukan saja bagaimana Anda akan merotasi dan mencabutnya sebelum go-live.
OAuth 2.0 ada untuk satu alasan utama: delegated access. Ia memungkinkan aplikasi mitra memanggil API atas nama pengguna tertentu, tanpa pengguna menyerahkan kata sandinya dan tanpa mitra mendapatkan akses permanen tak terbatas.
Pikirkan ini sebagai jabat tangan izin antara tiga pihak:
Setelah pengguna menyetujui, aplikasi mitra menerima access token. Ini adalah kredensial berumur pendek yang dikirim aplikasi ke API Anda untuk membuktikan ia memiliki izin saat itu. Access token dimaksudkan cepat kadaluarsa sehingga bila bocor, dampaknya terbatas.
Untuk menghindari memaksa pengguna menyetujui terus-menerus, banyak setup juga menggunakan refresh token. Refresh token lebih panjang umurnya dan hanya digunakan untuk mendapatkan access token baru saat yang lama kadaluarsa. Model mental yang baik: access token untuk memanggil API, refresh token untuk mendapatkan access token baru.
Scope membuat OAuth praktis. Scope adalah batas izin bernama seperti “read:invoices” atau “write:customers”. Saat consent, pengguna melihat apa yang diminta aplikasi mitra, dan sistem Anda mencatat apa yang disetujui. API Anda memeriksa scope pada setiap permintaan dan menolak panggilan yang melebihi apa yang diberikan.
Contoh: mitra CRM ingin menyinkronkan kontak. Anda bisa mewajibkan mitra meminta hanya “read:contacts” dan “write:contacts”. Jika mereka mencoba menghapus data, API memblokirnya kecuali “delete:contacts” secara eksplisit disetujui. Ini salah satu perbedaan terbesar secara praktis: OAuth memudahkan penerapan prinsip least-privilege.
Dengan kunci API, onboarding bisa hampir instan. Mitra meminta kunci, Anda memberikannya (sering dalam portal mitra atau email), dan mereka menambahkannya ke header permintaan. Waktu-untuk-panggilan-pertama sering kali menit, yang terasa hebat ketika tim mitra mencoba membuktikan integrasi dengan cepat.
Kecepatan itu punya tradeoff: “siapa yang memanggil” samar pada hari pertama. Jika satu kunci dibagi di seluruh tim mitra, Anda bisa mendapat demo bekerja cepat, tapi lebih sulit menetapkan batas awal (test vs produksi, least privilege, dan kepemilikan jelas ketika ada yang rusak).
Onboarding OAuth terasa lebih berat karena ada lebih banyak bagian sebelum panggilan pertama berhasil. Mitra biasanya perlu mendaftarkan aplikasi, mengatur redirect URI, dan menggunakan pengguna uji atau akun sandbox. Panggilan pertama bisa memakan waktu jam atau hari, bukan karena OAuth sulit, tapi karena detail setup kecil menciptakan keterlambatan besar.
Pemblokir hari pertama yang paling umum: mismatch redirect URI, bingung antara authorization code dan access token, mencampur lingkungan (kredensial test terhadap produksi), scope yang hilang, dan ketiadaan cara sederhana untuk membuat atau mereset pengguna uji.
Dokumentasi lebih menentukan untuk OAuth. Untuk kunci API, panduan singkat “salin kunci, tambahkan header, panggil endpoint” sering cukup. Untuk OAuth, mitra butuh checklist dan contoh kerja yang bisa mereka jalankan.
Jika Anda membuat tooling mitra dengan AppMaster, aplikasi starter kecil (UI web plus proxy backend) dapat membantu mitra menyelesaikan flow OAuth end-to-end tanpa menulis banyak kode, sekaligus menjaga model keamanan jelas sejak hari pertama.
Rotasi terdengar sederhana sampai Anda ingat mitra punya cron job, banyak lingkungan, dan seseorang yang menempelkan rahasia ke spreadsheet enam bulan lalu. Pertanyaan praktisnya bukan “bisakah kita merotasi?”, melainkan “bisakah kita merotasi tanpa memutus produksi?”
Dengan kunci API, rotasi sebagian besar soal koordinasi. Pola aman adalah kunci ganda dengan jendela overlap: Anda terbitkan kunci baru, mengizinkan kedua kunci untuk periode singkat, lalu menonaktifkan yang lama setelah mitra mengonfirmasi. Di sisi lain, pencabutan darurat: jika kunci bocor, Anda ingin satu klik untuk mematikannya tanpa menunggu release di pihak mereka.
Dalam praktik, rotasi kunci yang bisa dijalankan biasanya mencakup dua kunci aktif per mitra (sekarang dan berikutnya), kunci terpisah per lingkungan (dev, staging, prod), pelabelan jelas sehingga Anda tahu sistem mana memakai kunci mana, dan jalur insiden yang teruji untuk pencabutan segera.
Rotasi OAuth lebih otomatis jika Anda menggunakan access token berumur pendek. Anda membiarkan access token kedaluwarsa cepat dan bergantung pada refresh token untuk memperbarui, yang mengurangi risiko downtime saat Anda perlu memotong akses. Pencabutan fokus pada refresh token: setelah dicabut, mitra tidak bisa membuat access token baru.
Yang sulit adalah kebijakan: berapa lama refresh token hidup, apakah bisa dipakai ulang, dan apa yang memicu re-autentikasi (reset password, penghapusan admin, aktivitas mencurigakan). Jika Anda butuh respons insiden cepat, buat access token sangat pendek dan pastikan pencabutan refresh token dapat diandalkan dan langsung.
Insiden umum: log server mitra secara tidak sengaja menangkap kredensial. Dengan kunci API, Anda mencabut kunci dan integrasi langsung berhenti, lalu buru-buru menerbitkan ulang dan mengoordinasikan pembaruan. Dengan OAuth, Anda mencabut refresh token untuk mitra atau pengguna, dan access token yang ada akan segera kadaluarsa, biasanya dengan downtime yang kurang mendadak.
Jika Anda hanya perlu tahu perusahaan mana yang memanggil API Anda, identitas level mitra mungkin cukup. Tetapi saat mitra bertindak atas nama banyak pengguna akhir (agen, manajer, pelanggan), Anda juga butuh konteks pengguna yang jelas.
Dengan kunci API, pola umum adalah satu rahasia per mitra. Konteks pengguna lalu ditambal dengan salah satu dari tiga cara: tanpa pengguna sama sekali (semua terlihat sebagai mitra), mengirim user ID di header atau field, atau flow impersonation di mana mitra menandatangani user ID yang Anda berikan. Cara-cara ini bisa bekerja, tapi Anda harus menganggap setiap identifier pengguna yang dikirim mitra sebagai tidak tepercaya kecuali Anda bisa memverifikasinya.
OAuth dibangun untuk akses level pengguna. Setiap pengguna memberikan grant, dan scope membatasi apa yang bisa dilakukan mitra. Itu membuat least privilege lebih mudah: integrasi bisa membaca kontak tapi tidak mengekspor invoice, atau memperbarui tiket tapi tidak mengubah pengaturan admin.
Cara sederhana agar tetap rapi adalah memisahkan identitas dan izin: identitas mitra (siapa yang mengintegrasikan), identitas pengguna (untuk siapa aksi dilakukan), peran (apa yang bisa dilakukan pengguna di produk Anda), dan scope (apa yang bisa dilakukan mitra untuk pengguna itu).
Contoh: mitra helpdesk menyinkronkan tiket untuk 200 agen. Jika Anda hanya menggunakan satu kunci API, setiap aksi mungkin muncul sebagai “Mitra A” di log Anda. Dengan OAuth, setiap agen bisa memiliki grant sendiri, sehingga "Agen Maria memperbarui tiket 1832 via Mitra A" menjadi mungkin.
Saat Anda butuh keduanya, gunakan identitas client level mitra ditambah delegasi pengguna (token OAuth terkait pengguna). Di alat seperti AppMaster, ini terpeta dengan bersih ke modul otentikasi untuk pengguna, catatan mitra, dan pemeriksaan izin di logika bisnis Anda.
Ketika sesuatu berjalan salah dalam integrasi mitra, bagian sulitnya jarang memperbaiki bug. Yang sulit adalah membuktikan apa yang terjadi.
Dengan kunci API, banyak tim mengalami masalah identitas bersama. Satu kunci sering mewakili “mitra”, bukan orang atau instance aplikasi tertentu. Anda bisa mencatat ada permintaan dengan Kunci A, tetapi biasanya tidak bisa membuktikan pengguna akhir mana yang memicunya, atau apakah itu karyawan, script, atau kunci yang bocor. Jika mitra menyalin kunci ke banyak sistem, log Anda semua terlihat sama.
OAuth memberi jejak yang lebih jelas: pengguna mana yang memberi otorisasi aplikasi client mana, kapan mereka melakukannya, dan izin apa yang diberikan (scope). Jika aplikasi mitra dikompromikan, Anda sering bisa mempersempit dampak ke satu client_id atau bahkan subset pengguna yang memberi akses.
Pertanyaan audit di review keamanan atau pekerjaan kepatuhan meliputi: data pengguna mana yang diakses oleh aplikasi mitra mana dan di bawah scope apa; kapan akses diberikan dan terakhir digunakan; dari mana panggilan datang (IP, lingkungan); apakah ada yang melebihi scope yang disetujui; dan apakah Anda bisa mencabut akses untuk satu pengguna tanpa menghentikan seluruh integrasi.
Untuk mempercepat troubleshooting, tangkap beberapa bidang pada setiap permintaan (terlepas dari jenis otentikasi): client_id (atau id kunci), subject (user id jika tersedia), scope, alamat IP, dan ID permintaan unik yang Anda kembalikan di respons. Tambahkan cap waktu dan hasil (sukses, ditolak, rate limited) sehingga Anda bisa menyusun ulang timeline insiden dalam hitungan menit, bukan hari.
Sebagian besar insiden auth mitra bukanlah “hack canggih”. Mereka berasal dari pilihan kecil yang membuat rahasia mudah bocor atau sulit diganti.
Masalah kunci API biasanya dimulai dari tempat kunci berakhir. Mitra menaruhnya di aplikasi mobile atau browser, lalu kunci tersebut tertangkap dari log, screenshot, atau chat. Masalah umum lain adalah memperlakukan kunci sebagai permanen. Tanpa rencana rotasi, tim menghindari mengubahnya, bahkan setelah orang keluar atau repo terekspos.
Kegagalan OAuth terlihat berbeda. Tiket dukungan terbanyak adalah mismatch redirect URI: bekerja di staging dan rusak di produksi, dan developer tidak tahu kenapa. Berikutnya adalah scope yang terlalu luas “agar berjalan”, yang kemudian menjadi masalah saat security review. Layar persetujuan yang membingungkan juga menyebabkan churn saat pengguna melihat izin yang tidak sesuai dengan fungsi integrasi.
Perangkap muncul di kedua pendekatan. Rahasia dan token berumur panjang meningkatkan blast radius. Tanpa rate limit, bug bisa berubah jadi outage. Tanpa proteksi replay (misalnya, menerima request yang sama dua kali) bisa menyebabkan double-charge atau penciptaan record ganda.
Masalah dukungan seringkali self-inflicted. Jika error tidak jelas ("unauthorized"), mitra tidak bisa memperbaiki tanpa eskalasi. Jika Anda tidak menyediakan sandbox dan lingkungan konsisten, mitra menguji ke produksi secara tidak sengaja.
Jika Anda ingin batasan sebelum onboarding siapa pun, buat mereka sederhana:
Jika Anda membangun backend integrasi di alat seperti AppMaster, tanamkan aturan ini di modul otentikasi dan respons error sejak awal, sebelum mitra bergantung pada perilaku yang rapuh.
Mulailah dengan hasil yang Anda butuhkan, bukan teknologinya. Pilihan sebenarnya adalah apakah Anda mengotorisasi satu integrasi (identitas layanan tunggal) atau pengguna akhir nyata dengan izin berbeda.
Jika mitra bertindak atas nama pengguna individual, OAuth 2.0 biasanya pilihan aman default. Ia memungkinkan Anda mengaitkan panggilan ke orang, membatasi apa yang bisa dilakukan orang tersebut, dan memotong akses tanpa merusak seluruh integrasi mitra.
Jika integrasi benar-benar server-ke-server dan aksesnya tetap, kunci API bisa cukup. Ini cocok untuk kasus seperti “Mitra X mengirim pembaruan inventori setiap malam” di mana tidak ada konteks pengguna manusia dan aksi yang sama selalu terjadi.
Pemeriksaan risiko dan operasional singkat membantu:
Jika Anda harus mendukung keduanya, tetapkan batas yang jelas. Misalnya: kunci API untuk job batch back-office, OAuth untuk fitur yang menyentuh akun pengguna. Dokumentasikan endpoint mana yang menerima metode mana dan apa yang terjadi saat akses dicabut.
Contoh konkret: mitra CRM ingin mengimpor leads. Jika mereka menjalankan job malam di bawah satu akun perusahaan, kunci API mungkin cukup. Jika sales rep menghubungkan akun mereka sendiri dan hanya boleh melihat pipeline mereka sendiri, OAuth adalah pilihan yang tepat.
Sebelum membuka akses produksi, perlakukan otentikasi sebagai sistem operasional, bukan checklist. Kebakaran dukungan terbesar pada integrasi mitra dimulai dari kredensial yang tidak jelas, izin yang samar, dan log yang hilang.
Pilih satu jalur penerbitan yang jelas. Baik Anda menggunakan kunci API atau OAuth, pemeriksaan go-live serupa: siapa yang bisa mendapatkan kredensial, apa yang bisa mereka lakukan, dan seberapa cepat Anda bisa mematikannya.
Tulis dasar-dasarnya untuk tim mitra Anda: siapa yang menyetujui akses dan bagaimana Anda memverifikasi identitas mitra; bagaimana masa berlaku dan rotasi bekerja dan apa yang rusak jika rotasi terlewat; tombol “kill switch” teruji yang menonaktifkan satu mitra (atau satu pengguna) tanpa mematikan semuanya; izin yang terdefinisi dengan default least-privilege dan teks persetujuan yang jelas; serta sandbox dengan kredensial uji, data realistis, dan rate limit yang dapat diprediksi.
Realita: jika kunci API mitra bocor ke repo publik, dapatkah Anda mencabutnya dalam beberapa menit, mengonfirmasi blast radius, dan menerbitkan yang baru tanpa edit database manual?
Pastikan Anda bisa menjawab “apa yang terjadi?” dengan bukti. Setiap permintaan harus mencatat siapa yang memanggil (id mitra, id pengguna bila ada), apa yang dicoba (endpoint, scope), dan keputusan sistem (kode status, alasan error).
Juga pastikan pesan error jelas sehingga mitra tahu apa yang harus diperbaiki (scope hilang, token kedaluwarsa, signature tidak valid), rate limit yang melindungi Anda tanpa mengejutkan mitra, dan playbook insiden untuk menjeda akses dan memberi tahu mitra terdampak.
Jika Anda membangun API mitra dengan AppMaster, atur bidang dan pemeriksaan ini sejak awal agar backend dan log yang dihasilkan tetap konsisten saat kebutuhan berubah.
Bayangkan mitra CRM yang menyinkronkan kontak ke produk Anda untuk puluhan pelanggan bersama. Setiap pelanggan punya banyak tim, dan tidak setiap tim boleh melihat kontak yang sama. Vendor CRM ingin satu integrasi yang dapat mereka ulang, sementara Anda ingin lebih sedikit tiket dukungan dan catatan perubahan yang bersih.
Dengan kunci API, onboarding terlihat sederhana: Anda memberi mitra sebuah kunci, mereka mulai mendorong kontak. Masalah muncul seminggu kemudian, ketika seorang pelanggan bertanya, “Bolehkah tim Sales sinkron, tapi Support tidak?” Satu kunci jadi pas master.
Dalam setup ini, breakpoint dengan kunci API dapat diprediksi: akses sering bersifat all-or-nothing per kunci (jadi Anda membuat kunci ekstra per pelanggan, tim, atau lingkungan), kebocoran memaksa rotasi di mana-mana, atribusi lemah karena kunci mewakili aplikasi mitra bukan orang, dan “mati untuk satu pengguna” biasanya berarti menonaktifkan seluruh kunci.
Dengan OAuth, CRM mitra mengarahkan setiap admin pelanggan melalui langkah persetujuan. Anda bisa meminta hanya scope yang diperlukan untuk sinkron kontak (read contacts, write contacts, bukan billing atau pengaturan admin). Potongan akses yang lebih kecil itu mencegah banyak tiket “mengapa mereka bisa melihat ini?”.
Operasi sehari-hari biasanya lebih bersih dengan OAuth: Anda bisa mencabut akses untuk satu pelanggan (atau bahkan satu pengguna) tanpa merusak yang lain, access token berumur pendek mengurangi blast radius, dan log audit dapat mengaitkan aksi ke akun pelanggan, client OAuth, dan sering kali identitas pengguna tertentu.
Jika Anda membangun ini di platform seperti AppMaster, desain model data Anda sehingga setiap pembaruan kontak yang disinkronkan mencatat aplikasi mitra, akun pelanggan, dan pengguna yang melakukan aksi (ketika OAuth digunakan). Itu membuat “kontak terduplikasi semalam” jauh lebih mudah diselidiki.
Tulis integrasi Anda sebagai dua cerita singkat: jalur bahagia (dapat kredensial, panggil endpoint, lihat data) dan jalur gagal (token kedaluwarsa, scope hilang, akun salah). Satu halaman itu menyelamatkan hari karena mitra bisa mendiagnosis sendiri.
Mulai kecil dengan pilot mitra. Lalu lintas nyata cepat menunjukkan apa yang Anda lewatkan: endpoint mana yang butuh scope lebih jelas, error mana yang butuh pesan lebih baik, dan apa yang harus Anda log untuk menjawab pertanyaan dengan cepat.
Jika Anda membangun platform integrasi sendiri, buat versi pertama sederhana. Alat seperti AppMaster dapat membantu Anda membuat alur otentikasi, API, dan backend yang ramah-audit lebih cepat, tanpa menulis semua bagian secara manual. AppMaster tersedia di appmaster.io.
Berikut checklist praktis untuk beralih dari “bekerja” ke “aman dan bisa didukung”:
Akhirnya, buat onboarding terasa seperti setup terpandu, bukan perburuan harta karun. Sandbox yang rapi, error yang jelas, dan log yang berguna adalah yang mengubah frustasi minggu pertama menjadi integrasi yang berhasil.
Kapan saya harus memilih kunci API daripada OAuth 2.0 untuk integrasi mitra?Gunakan kunci API ketika integrasi benar-benar server-ke-server dan Anda hanya perlu mengidentifikasi sistem mitra, bukan pengguna akhir individual. Gunakan OAuth 2.0 ketika aplikasi mitra perlu bertindak atas nama berbagai pengguna atau tenant dan Anda membutuhkan persetujuan per pengguna, scope, dan kemampuan pencabutan akses.
Apa perbedaan praktis antara akses "level mitra" dan akses "delegasi pengguna"?Kunci API biasanya mengidentifikasi integrasi mitra sebagai satu identitas bersama, sehingga izin dan log cenderung kasar. OAuth 2.0 menerbitkan token yang terkait dengan grant pengguna tertentu dan scope yang disetujui, sehingga pemeriksaan izin per pengguna dan jejak audit jauh lebih mudah.
Mengapa kunci API terasa lebih cepat untuk onboarding daripada OAuth?Dengan kunci API, onboarding seringnya memakan waktu beberapa menit karena mitra cukup menambahkan kunci ke permintaan. Onboarding OAuth lebih lama karena mitra harus mendaftarkan aplikasi, mengonfigurasi redirect URI, dan menyelesaikan flow persetujuan sebelum panggilan API pertama berhasil.
Apa saja kesalahan setup OAuth yang paling sering dilakukan mitra?Masalah paling umum adalah mismatch redirect URI antara yang dikonfigurasi mitra dan yang diharapkan server otorisasi Anda. Masalah lain yang sering muncul: mencampur kredensial test dan produksi, bingung antara authorization code dan access token, serta meminta scope yang salah.
Bagaimana cara merotasi kunci API tanpa memutuskan job produksi mitra?Rencanakan dua kunci per mitra dengan jendela overlap agar dapat berganti tanpa downtime: terbitkan kunci baru, izinkan kedua kunci untuk sementara, lalu nonaktifkan kunci lama setelah konfirmasi. Jaga kunci terpisah per lingkungan dan pastikan Anda bisa mencabut segera jika kunci terekspos.
Apa pendekatan rotasi dan pencabutan token yang masuk akal dengan OAuth 2.0?Jaga access token berumur pendek dan andalkan refresh token untuk membuat access token baru. Untuk respons insiden, pastikan pencabutan refresh token dapat dilakukan segera sehingga mitra tidak bisa terus memperbarui akses setelah Anda memotongnya.
Apakah aman menaruh kunci API di aplikasi mobile atau browser?Secara default, anggap apa pun yang ada di browser atau aplikasi mobile dapat diekstrak, jadi kunci API sebaiknya hanya disimpan di server. Jika mitra membutuhkan sign-in di klien dan akses spesifik pengguna, OAuth lebih aman karena menghindari penempatan rahasia permanen di sisi klien.
Bagaimana scope membantu, dan bagaimana merancangnya untuk mitra?Scope adalah izin bernama seperti “read contacts” atau “write tickets” yang API Anda periksa pada setiap permintaan. Buat scope kecil dan sesuai tindakan nyata, lalu minta mitra hanya meminta yang mereka butuhkan agar Anda bisa menegakkan prinsip least privilege dan mengurangi sengketa dukungan nantinya.
Apa yang harus kita log agar masalah otentikasi mitra mudah ditangani?Catat identifier mitra (key id atau client id), pengguna atau subject bila tersedia, scope yang diberi, endpoint/aksi yang dicoba, keputusan (sukses atau ditolak) dengan alasan jelas, alamat IP, dan ID permintaan unik yang Anda kembalikan di respons. Ini memungkinkan Anda menjawab “siapa melakukan apa” dengan cepat saat insiden atau tiket dukungan.
Apa saja pemeriksaan go-live penting sebelum membuka akses produksi untuk mitra?Tentukan metode otentikasi default dan kapan Anda mengizinkan pengecualian, verifikasi bahwa Anda bisa menerbitkan dan mencabut kredensial dengan cepat, dan pastikan rate limit serta idempotency untuk endpoint tulis. Sediakan sandbox, pesan error yang jelas, dan playbook teruji untuk menjeda satu mitra atau satu pengguna tanpa memutus semua orang.
27 Jan 2026
7 menit
26 Jan 20268 menit
21 Jan 20266 menitEksperimen dengan AppMaster dengan paket gratis.
Saat Anda siap, Anda dapat memilih langganan yang tepat.
