Pengaturan Otorisasi Aplikasi: Panduan Pengembang untuk 2026

Anda mungkin sudah menghadapi masalah ini. Login aplikasi berfungsi, pengguna dapat masuk dengan Google, Microsoft, atau email, dan API menerima token. Lalu pertanyaan-pertanyaan utama muncul. Apakah pengguna ini dapat melihat faktur dari akun lain? Apakah aplikasi desktop menyimpan token akses secara lokal? Bagaimana cara mengatasi persetujuan dalam Capacitor build tanpa mengungkapkan keadaan di lapisan webview dan native?

Itu adalah titik di mana pengaturan otorisasi aplikasi tidak lagi menjadi pilihan dan mulai mempengaruhi kepercayaan produk, tanggapan insiden, dan hasil tinjauan aplikasi. Dalam aplikasi multi-platform, terutama dengan Capacitor dan Electron, bagian yang sulit bukanlah memahami konsep otorisasi. Melainkan mengimplementasikannya di tempat-tempat di mana asumsi browser tidak lagi berlaku, penyimpanan yang aman berperilaku berbeda per platform, dan singkatan di klien menciptakan risiko server-side.

Daftar Isi

• Apa Saja Arti Otorisasi Aplikasi?
• Blok-Blok Dasar Otorisasi
  • Kartu Kunci Hotel adalah Model Mental yang Baik
  • Kata-Kata yang Penting dalam Sistem Nyata
• Model Otorisasi dan Protokol yang Umum Digunakan
  • Protokol Mengatur Percakapan
  • Model Mengatur Logika Keputusan
  • RBAC vs. ABAC: Ringkasan
• Anatomi Aliran OAuth 2.0
  • Apa yang Terjadi Ketika Pengguna Menekan Tombol Login
  • Di Mana Aplikasi Berbasis Multi-Tingkat Biasanya Mengalami Kesalahan
• Ancaman Keamanan dan Praktik Terbaik yang Wajib Diketahui
  • Kegagalan yang Terus Muncul
  • Daftar Periksa yang Praktis dan Berlaku
• Polanya Implementasi untuk Capacitor dan Electron
  • Polanya Capacitor yang Berhasil
  • Polanya Electron yang Perlu Perhatian Khusus
• Jalan Menuju Otorisasi Aplikasi yang Aman

Apa Itu Otorisasi Aplikasi yang Sebenarnya

Saat pengguna menginstal aplikasi Anda, mengetuk ‘Lanjutkan dengan Google,’ masuk dengan berhasil, dan kemudian mendapatkan layar persetujuan yang bertanya apakah aplikasi dapat membaca kontak atau data kalender. Saat itu mengandung kedua sisi cerita akses. Pengenalan identitas dikonfirmasi. Layar persetujuan menentukan apa yang dapat dilakukan aplikasi setelah identitas diketahui.

Perbedaan ini masih membuat tim kebingungan. Autentikasi menetapkan siapa pengguna itu. Authorization menentukan apa yang pengguna, sesi, atau aplikasi dapat akses. ID memungkinkan Anda masuk ke bangunan. Kunci menentukan pintu mana yang terbuka.

Dalam kerja aplikasi, perbedaan ini sangat penting karena tim sering kali memastikan aliran login dan kemudian mengabaikan desain setelahnya. Mereka terlalu percaya pada token, melewatkan pengecekan izin server-side, atau membiarkan klien mengatur aturan akses yang seharusnya berada di kebijakan. Itulah bagaimana 'pengguna telah masuk' secara halus berubah menjadi 'pengguna dapat mengakses terlalu banyak.'

Authorization adalah tempat di mana kepercayaan menjadi konkrit. Pengguna tidak hanya peduli bahwa aplikasi Anda tahu siapa mereka. Mereka peduli bahwa aplikasi hanya menyentuh apa yang mereka setujui.

Ada tiga aktor yang perlu Anda ketahui:

• Pengguna yang masuk dan mungkin memberikan persetujuan.
• Aplikasi yang meminta akses atas nama pengguna.
• Pemilik sumber atau API yang melindungi data dan menerapkan keputusan.

Dalam prakteknya, aplikasi otorisasi juga bersinggungan dengan kontrol akses yang lebih kuat seperti MFA. Sejak Januari 2023, sekitar 66% pengguna global menggunakan MFA, dan 83% dari lebih dari 1.000 profesional IT SME yang diinterogasi memerlukan MFA untuk akses ke semua sumber daya perusahaan dalam survei JumpCloud 2024 menurut Ringkasan statistik MFA JumpCloudItu tidak menggantikan otorisasi, tapi itu meningkatkan dasar untuk siapa yang bisa meminta akses terlebih dahulu.

Jika tim Anda sedang mengatur peran, ruang lingkup, dan akses yang didelegasikan, ringkasan pola manajemen akses aplikasi ini adalah teman yang berguna untuk pilihan implementasi yang dibahas di sini. Blok-Blok Dasar Otorisasi Otorisasi menjadi lebih mudah sekali Anda berhenti menganggapnya sebagai keajaiban di dalam token. Model mental yang lebih baik adalah hotel.

Kartu kunci hotel adalah model mental yang baik

A hotel keycard is a good mental model

Jika tim Anda sedang mengatur peran, ruang lingkup, dan akses yang didelegasikan, ringkasan pola manajemen akses aplikasi ini adalah teman yang berguna untuk pilihan implementasi yang dibahas di sini.

Seorang tamu berjalan ke meja resepsionis dan menunjukkan ID. Hotel memverifikasi identitas, membuat catatan perjalanan, dan mengeluarkan kartu akses. Kartu itu tidak membuktikan siapa tamu itu setiap kali pintu dibuka. Ia membawa izin untuk mengakses tempat tertentu selama periode tertentu.

Aplikasi Anda bekerja sama seperti itu.

Poin penting adalah kartu itu bukan kebijakan. Ia mencerminkan kebijakan. Pintu-pintu masih memerlukan sistem yang memeriksa apakah kartu itu boleh membuka kunci tertentu. Dalam perangkat lunak, itu adalah API gateway, middleware backend, mesin kebijakan, atau lapisan otorisasi layanan.

Kata-kata yang berpengaruh dalam sistem nyata

Principal
Pengguna yang meminta akses. Biasanya pengguna, tetapi juga bisa perangkat, tugas latar, atau akun layanan.

Resource
Sumber daya yang dilindungi. Proyek, faktur, jalur admin, file, API endpoint, atau satu rekaman di database.

Scope
Set aksi yang diminta. Baca profil. Unggah file. Kelola tagihan. Scope harus sempit dan dapat dipahami.

Konsensi
Persetujuan pengguna untuk tingkat akses yang diminta. Layar persetujuan yang baik membuat permintaan dapat dibaca. Yang buruk meminta segalanya.

Token akses
Kredensial yang klien presentasikan ke server sumber daya setelah otorisasi berhasil. Harus dianggap sebagai data sensitif.

Banyak kesalahan implementasi datang dari mengompresi semua itu ke dalam asumsi tunggal: “pengguna memiliki token, jadi biarkan mereka masuk.” Itu tidak berlaku di produksi. Token mungkin valid tetapi masih salah untuk aksi saat ini, penyewa, lingkungan, atau sumber daya.

Untuk tim mobile dan desktop, penanganan token membutuhkan perhatian khusus karena penyimpanan adalah bagian dari sistem otorisasi, baik Anda suka atau tidak. Jika klien menyimpan artefak akses dengan tidak hati-hati, desain kebijakan Anda tidak akan menyelamatkan Anda nanti. Panduan ini tentang penyimpanan token yang aman untuk pengembang mobile patut Anda tinjau sebelum Anda kirim. Satu aturan yang tahan lama adalah sederhana. Jaga otentikasi, persetujuan, penerbitan token, dan penegakan sisi server terpisah dalam pikiran dan dalam __CAPGO_KEEP_0__. Tim yang menyatukan mereka biasanya menghabiskan waktu untuk memperbaiki bug otorisasi di layer yang salah.

A durable rule is simple. Keep authentication, consent, token issuance, and server-side enforcement separate in your head and in your code. Teams that merge them usually end up debugging permission bugs in the wrong layer.

Saat tim mengatakan “kami menggunakan OAuth,” mereka sering kali berarti beberapa hal yang berbeda sekaligus. Itu adalah bagian dari kebingungan. Protokol dan model otorisasi memecahkan masalah yang berbeda.

Protokol mengelola percakapan

OAuth 2.0

Token akses terutama tentang otorisasi yang didelegasikan. Ini menjelaskan bagaimana sebuah aplikasi dapat meminta dan menerima izin untuk bertindak atas nama pengguna tanpa menangani kata sandi pengguna secara langsung.

OpenID Connect, atau OIDC, berdiri di atas OAuth 2.0 dan menambahkan informasi identitas. Dalam hal praktis, OAuth menjawab “apa yang dapat aplikasi ini lakukan,” sementara OIDC membantu menjawab “siapa yang masuk.”

Perbedaan ini penting dalam aplikasi Capacitor dan Electron karena banyak bug dimulai dengan menggunakan token ID di mana token akses diharapkan, atau asumsi bahwa masuk sukses berarti API harus memberikan akses untuk setiap aksi downstream. Tidak boleh.

Jika Anda menghubungkan ini ke aplikasi hybrid, langkah demi langkah Implementasi guide OAuth2 untuk aplikasi Capacitor adalah jenis sumber daya yang mencegah banyak kesalahan aliran yang dapat dihindari.

Model menghandle logika keputusan

Dalam sistem Anda sendiri, Anda masih perlu aturan untuk menentukan apakah akses harus diberikan. Itu di mana RBAC dan ABAC Datanglah.

Kontrol Akses Berdasarkan Peran (RBAC) peta hak akses ke peran seperti admin, editor, agen dukungan, atau penonton. Ini umum karena itu mudah dipahami, dapat diverifikasi, dan relatif stabil. Menurut diskusi BrightSec tentang autentikasi dan otorisasi yang aman, RBAC adalah mekanisme standar industri untuk menerapkan hak akses yang halus, dan bukti yang dikutip di sana mengatakan bahwa menerapkan RBAC dengan struktur peran hierarkis dan audit hak akses secara berkala mengurangi insiden keamanan hingga 40% di lingkungan perusahaan.

Kontrol Akses Berdasarkan Sifat (ABAC) membuat keputusan menggunakan atribut bukan hanya peran. Itu bisa termasuk departemen, posisi perangkat, kepemilikan rekaman, tingkat akun, geografi, waktu permintaan, atau apakah sesi melewati MFA. ABAC lebih ekspresif, tapi juga lebih mudah membuatnya tidak transparan jika Anda tidak dokumentasi kebijakan dengan baik.

Praktik yang berguna: Mulai dengan RBAC ketika hak akses produk Anda stabil dan dapat dibaca manusia. Tambahkan ABAC di mana konteks memang mengubah keputusan.

Pemandangan Ringkas RBAC vs. ABAC

Tidak ada hadiah untuk memilih model yang paling canggih. Pilihan yang lebih baik adalah yang dapat diterapkan tim Anda secara konsisten. Di sebagian besar kodebasis produk, itu berarti RBAC untuk batasan akses luas dan atribut yang spesifik untuk kecuali seperti kepemilikan, penyewa, atau status perangkat.”

Anatomi Aliran OAuth 2.0

Banyak penjelasan OAuth tetap abstrak terlalu lama. Dalam aplikasi nyata, urutan itu penting, terutama untuk klien publik seperti Capacitor dan aplikasi Electron yang tidak dapat menjaga rahasia klien dengan aman.

Apa yang terjadi ketika pengguna mengetuk tombol login

Seorang pengguna membuka aplikasi Capacitor Anda dan mengetuk “Masuk dengan GitHub.” Aplikasi membuat verifikasi PKCE code dan tantangan yang dihasilkan code, kemudian mengirim pengguna ke server otorisasi dalam tab browser sistem atau tab browser aman. Aplikasi juga termasuk status sehingga dapat memverifikasi respons yang dimiliki oleh permintaan yang diinisiasi.

Pada server otorisasi, pengguna masuk jika diperlukan dan menyetujui akses yang diminta. Server kemudian mengalihkan kembali dengan kode otorisasi code, bukan dengan kredit yang berlangsung lama yang dapat digunakan secara langsung. Aplikasi Anda menerima kode otorisasi code melalui URI pengalihan yang disesuaikan.

Aplikasi kemudian menukar kode otorisasi code untuk token. PKCE sangat penting dalam proses ini. Aplikasi mengirimkan verifikasi asli code bersama dengan kode otorisasi code. Server membandingkannya dengan tantangan awal code. Jika mereka cocok, proses menukar token berhasil. Jika seseorang menangkap kode otorisasi code tetapi tidak memiliki verifikasi, proses menukar token gagal.

Itulah mengapa PKCE sangat penting untuk klien native dan hybrid. Aplikasi-aplikasi ini adalah klien publik. Anda harus asumsikan penyerang dapat memeriksa bundle, mengembalikan code jalur, atau mengganggu status lokal. PKCE mempersempit salah satu risiko yang paling umum dalam aliran berdasarkan pengalihan.

Berikut adalah ringkasan singkat jika Anda ingin memperbarui visual sebelum menerapkan urutan dalam code:

Di mana aplikasi cross-platform biasanya gagal

The protocol adalah sederhana. Namun, implementasinya sering kali tidak.

Aplikasi Capacitor biasanya gagal di salah satu tempat ini:

1. Menggunakan tampilan web terintegrasi untuk masuk sebaliknya dari browser sistem. Hal ini dapat mengganggu batasan keamanan yang diharapkan dan menciptakan perilaku cookie yang tidak konsisten.
2. Kehilangan status redirect ketika aplikasi kembali dari browser ke shell native.
3. Menyimpan token di penyimpanan browser yang tidak terenkripsi karena proyek dimulai sebagai aplikasi web dan tim tidak pernah memeriksa penyimpanan untuk mobile.

Aplikasi Electron memiliki masalah yang berbeda. Tim kadang-kadang membiarkan proses renderer mengelola logika autentikasi yang terlalu banyak, mengekspos token melalui IPC tanpa batasan yang ketat, atau menganggap aplikasi desktop seperti lingkungan yang dipercaya. Tidaklah.

Aplikasi desktop yang dikemas masih memerlukan mindset klien yang berbahaya. Pengulangan refresh juga memerlukan perancangan yang sengaja. Token akses harus kadaluarsa, sesi harus pulih dengan bersih, dan logika refresh tidak boleh menciptakan kondisi balapan di antara permintaan koncurrent yang banyak. Ini aliran refresh token yang aman ini adalah referensi yang solid untuk membangun bagian tersebut tanpa berakhir di dalam loop ulang atau kekacauan sesi yang kering.

Kebiasaan implementasi yang satu dapat membantu lebih dari yang lain. Simpanlah tangan genggaman OAuth di dalam modul autentikasi kecil dengan input dan output yang eksplisit. Jangan menyebarkan penanganan redirect, parsing token, dan logika refresh di komponen, hook, dan utilitas jaringan acak.

Ancaman Keamanan dan Praktik Terbaik yang Paling Esensial

Bugs autentikasi jarang terlihat dramatis dalam code tinjauan. Mereka terlihat seperti kemudahan. Lingkup luas di sini, token yang disimpan di sana, pengecekan server yang hilang karena UI sudah menyembunyikan tombol. Kemudian aplikasi tersebut dikirim dan kepanjangan-kepanjangan tersebut menjadi permukaan serangan.

Kegagalan yang terus muncul

Ekosistem mobile memberikan tanda peringatan yang berguna. Menurut Statistik Keamanan Mobile DeepStrike, 95% aplikasi mobile yang dites gagal setidaknya satu kontrol OWASP MASVS terkait autentikasi dan otorisasi, dan 85% aplikasi mobile yang dianalisis mengandung kelemahan keamanan. Anda tidak perlu menerima setiap penjelasan dalam pemasaran keamanan untuk mengambil signal inti serius. Kesalahan autentikasi adalah umum.

Patron yang familiar:

• Token yang terlepas dari penyimpanan yang tidak aman, log, laporan kegagalan, atau keadaan renderer yang dapat diakses.
• Istilah ruang lingkup yang terlalu luas karena meminta semuanya lebih mudah daripada mengembangkan persetujuan secara bertahap.
• Pengaturan sisi klien dimana aplikasi menyembunyikan aksi yang tidak diizinkan tetapi API masih menerimanya.
• Serangan ulang dan redirect ketika validasi keadaan, PKCE, atau URI redirect yang dapat diakses tidak teliti.
• Perubahan hak istimewa setelah tim menambahkan peran dan kecuali tanpa tinjauan yang terjadwal.

Jika backend Anda tidak memverifikasi otorisasi pada setiap aksi yang dilindungi, Anda tidak memiliki otorisasi aplikasi. Anda memiliki petunjuk UI.

Daftar periksa yang praktis yang tetap berlaku

Gunakan prinsip keamanan terkecil sebagai default, bukan sebagai pekerjaan pembersihan nanti. Dalam proyek nyata, itu berarti mengurangi apa yang dapat dilakukan oleh setiap token, mengurangi tempat di mana setiap token hidup, dan mengurangi berapa lama setiap kredensial tetap berguna.

• Minta ruang lingkup yang sempit: Hanya minta izin yang dibutuhkan untuk fitur yang digunakan oleh pengguna saat ini. Jika aplikasi dapat menunda persetujuan, lakukan itu.
• Tegakkan di server: Tangani klien sebagai tidak dapat dipercaya. Tombol, jalur, dan layar tersembunyi bukanlah batas keamanan.
• Gunakan penyimpanan aman platform: Pada perangkat mobile, gunakan akses ke keychain atau keystore native melalui plugin daripada penyimpanan lokal biasa. Pada desktop, jaga bahan sensitif di luar jangkauan renderer yang mudah.
• Validasi pengaturan dan penanganan redirect: Respons autentikasi harus sesuai dengan permintaan aplikasi Anda yang diluncurkan.
• Masa aktif yang singkat membatasi kerusakan ketika mereka bocor. Logika refresh harus berputar dengan bersih dan gagal tertutup. Revoke ketika diperlukan:
• Minta izin yang dibutuhkan untuk fitur yang digunakan oleh pengguna saat ini. Jika aplikasi dapat menunda persetujuan, lakukan itu. Kegagalan sesi dan tanggapan insiden harus mencakup kemampuan untuk membatalkan token dan memaksa reautentikasi.
• Validasi input dan perlindungan transportasi: HTTPS, pemberian sertifikat pinning di mana-mana yang sesuai, dan validasi input semua berperan karena otorisasi dapat dilawan melalui kelemahan yang berdekatan.

Untuk tim yang mengirimkan aplikasi melalui toko, desain autentikasi juga bertemu dengan API pengungkapan dan tinjauan kewenangan. Ringkasan standar keamanan API untuk kewenangan toko. API security standards for app store compliance Poin akhir yang mudah dilupakan. Hak keistimewaan yang paling rendah berlaku juga pada alat internal. Panel admin, konsol dukungan, dan aplikasi pengujian biasanya berakhir dengan kontrol yang paling longgar di perusahaan, meskipun mereka sering menampilkan aksi yang paling sensitif.

Polanya Implementasi untuk __CAPGO_KEEP_0__ dan Electron

Pengautentikan aplikasi lintas platform menjadi lebih mudah ketika Anda berhenti berpikir bahwa aplikasi Anda hanya browser dengan pengemasan tambahan. Capacitor dan Electron sama-sama membutuhkan pola yang menghormati penyimpanan native, batasan proses, dan pengolahan redirect.

Seorang developer muda yang fokus bekerja di laptop dengan Capacitor di monitor di lingkungan kantor yang cerah.

Untuk Capacitor, gunakan plugin atau library autentikasi yang mendukung OAuth sistem-browser dengan PKCE dan callback deep-link atau app-link yang tepat. Library seperti

Capacitor capacitor-oauth2 dapat menghapus banyak lem code, tetapi hanya jika Anda masih menjaga penyimpanan token dan perilaku refresh eksplisit.

Struktur yang praktis seperti ini:

• Koordinator autentikasi: Mulai login, track status, tangani callback.
• Jasa token: Menyimpan token melalui penyimpanan aman native, bukan penyimpanan browser.
• API klien: Menempelkan token akses, mencoba sekali pada refresh, kemudian memaksa keluar pada kegagalan yang tidak dapat diperbaiki.
• Backend yang sadar kebijakan: Menghubungkan klaim token ke pengecekan otorisasi sisi server.

Anda juga ingin alat sesi yang sesuai dengan siklus aplikasi hybrid. Jika Anda mengevaluasi opsi untuk lapisan itu, Capacitor plugin untuk pengelolaan sesi yang aman adalah tempat yang baik untuk membandingkan pendekatan.

Bentuk refresh token yang minimal dalam pseudocode seperti ini:

async function authorizedFetch(request) {
  let token = await tokenStore.getAccessToken()
  let response = await api(request, token)

  if (response.status !== 401) return response

  const refreshed = await auth.refresh()
  if (!refreshed) {
    await auth.signOut()
    throw new Error('Session expired')
  }

  token = await tokenStore.getAccessToken()
  return api(request, token)
}

Bagian penting bukanlah sintaks. Itu adalah menjaga refresh tetap sentralisasi agar setiap layar tidak menciptakan perilaku sesi sendiri.

Polanya Electron yang perlu perhatian lebih lanjut

Electron memerlukan batasan yang lebih ketat. Simpan token exchange dan penyimpanan yang aman di proses utama ketika memungkinkan. Buatkan metode IPC yang sempit untuk renderer daripada memberikan token mentah kepada renderer dan berharap perilakunya baik.

Aplikasi desktop terasa lebih terkendali daripada aplikasi mobile. Terganjalkan perasaan itu sebagai risiko, bukan sebagai jaminan.

Hindari cara-cara ini:

• Jangan menyimpan token di penyimpanan lokal yang dapat diakses renderer. Jika bisa dihindari.
• Jangan biarkan setiap jendela berbagi konteks autentikasi yang luas tanpa memeriksa tujuan jendela dan umur hidup sesi.
• Jangan terlalu percaya skrip preload sebagai pengganti isolasi proses dan batasan eksplisit API.

Ketersediaan operasional juga penting. Menurut ringkasan Splunk tentang kebutuhan keamanan aplikasi, otorisasi aplikasi harus diintegrasi dengan pemantauan aktivitas terus-menerus dan logging, dan data benchmark yang dikutip di sana mengatakan bahwa organisasi yang merekam dan memantau kejadian otorisasi secara proaktif dapat mendeteksi 95% upaya akses tidak berwenang dalam 15 menit. Dalam prakteknya, itu berarti merekam aksi yang ditolak, gagal memperbarui token, perubahan peran, pengunduran diri dari persetujuan, dan pola akses sumber daya yang tidak biasa.

Jika proses rilis Anda termasuk pembaruan aplikasi hybrid, salah satu opsi dalam ekosistem ini adalah Capgo, yang menyediakan pembaruan hidup yang ditandatangani untuk Capacitor dan aplikasi Electron. Hal itu tidak menerapkan otorisasi untuk Anda, tetapi itu mempengaruhi seberapa cepat Anda dapat mengirimkan perbaikan ketika logika autentikasi, pengolahan redirect, atau code sesi memerlukan perbaikan darurat.

Jalan Menuju Otorisasi Aplikasi yang Aman

Otorisasi aplikasi yang baik bukanlah satu keputusan. Itu adalah rantai keputusan yang semua perlu menopang bersama-sama. Anda autentikasi pengguna dengan benar, meminta akses yang dibutuhkan, menukar token melalui aliran yang aman seperti OAuth 2.0 dengan PKCE, menyimpan rahasia di tempat yang tepat, dan menerapkan izin pada server setiap kali.

Bahwa bagian yang paling penting untuk Capacitor dan tim Electron adalah disiplin di tepi. Singkatkan dari era browser tidak bertahan setelah kontak dengan penyimpanan native, tautan dalam, batasan proses desktop, atau persyaratan tinjauan aplikasi. Tim yang tetap keluar dari masalah biasanya tidak melakukan apa pun yang eksotis. Mereka hanya konsisten tentang ruang lingkup, pengelolaan sesi, pengecekan server, dan auditabilitas.

Jika setup autentikasi Anda saat ini terasa berantakan, itu normal. Mulai dengan memperketat satu batasan pada satu waktu. Perbaiki aliran. Perbaiki penyimpanan. Pindahkan aturan akses keluar dari antarmuka pengguna. Tambahkan log yang memberitahu Anda ketika seseorang meminta sesuatu yang tidak seharusnya.

Itu cara aplikasi autentikasi menjadi lebih mudah diatur. Bukan lebih sederhana secara teori. Lebih aman dalam code.

Capgo membantu tim mengirimkan perbaikan ke Capacitor dan aplikasi Electron tanpa harus menunggu tinjauan toko, yang penting ketika Anda perlu memperbaiki aliran autentikasi, pengelolaan token, atau bug sesi dengan cepat. Jika tim Anda ingin memiliki kontrol yang lebih ketat atas rilis lintas platform, peluncuran yang sasaran, dan dukungan rollback. Capgo layak dievaluasi bersamaan dengan stack autentikasi aplikasi Anda.