Belajar 2FA Authentication - Ekosistem 2026: Provider & Authenticator Apps

#Pendahuluan

Setelah 20 episode membangun 2FA sendiri, episode 21 melihat peta yang lebih luas. Tidak semua tim perlu menulis kode yang baru saja kalian pelajari — dan kalian kini punya kemampuan untuk menilai dengan tepat kapan memakai provider dan kapan membangun sendiri.

Episode ini membandingkan empat auth provider besar — Clerk, Auth0, Supabase Auth, dan WorkOS — lalu menelusuri kompatibilitas aplikasi authenticator yang paling umum dipakai pengguna. Keputusan arsitektur yang baik lahir dari memahami keduanya.

#Kapan Memakai Auth Provider

#Empat Provider Utama

Keempat provider menawarkan 2FA bawaan, tapi dengan karakter berbeda:

Perbandingan auth provider untuk 2FA

Provider        Model 2FA                      Kekuatan utama
Clerk           TOTP + passkeys + SMS          onboarding cepat, UI lengkap
Auth0           TOTP, push, passkeys, SMS      ekosistem enterprise, SSO
Supabase Auth   TOTP + SMS                      terintegrasi Postgres/RLS
WorkOS          TOTP + enterprise SSO           jalur ke klien enterprise

Auth0 unggul saat kebutuhan SSO enterprise mendominasi, sementara Clerk dan Supabase Auth mempercepat jika aplikasi memakai ekosistem masing-masing. WorkOS menjembatani produk SaaS menuju login enterprise dengan mulus.

Penting untuk dicatat: keempat provider ini berubah cepat. Verifikasi kapabilitas 2FA terbaru di dokumentasi masing-masing sebelum berkomitmen — tabel di atas adalah peta awal, bukan keputusan final.

#Keputusan Build versus Buy

Pertanyaan yang harus dijawab bukan "apakah bisa", tapi "apakah ini kompetensi inti". Pilih build jika: kontrol atas secret dan recovery codes adalah kebutuhan compliance, kebijakan per-tenant sangat spesifik, atau biaya provider melebihi biaya pemeliharaan internal.

Pilih provider jika: waktu ke pasar lebih penting, tim kecil, atau 2FA bukan pembeda produk. Yang penting dari episode ini: kalian sekarang tahu apa yang ditangani provider — secret storage, backup codes, rate limit — sehingga bisa mengevaluasi klaim mereka dengan pengetahuan, bukan kepercayaan buta.

Keputusan ini tidak permanen — banyak tim mulai dengan provider lalu membawa fitur ke internal saat skala tumbuh, atau sebaliknya. Rancang abstraksi auth yang tipis sejak awal agar perpindahan tidak menuntut tulis ulang seluruh aplikasi.

Satu uji yang berguna: tulis requirement fungsional 2FA kalian — enrollment QR, recovery codes, enforce per role, ekspor data — lalu bandingkan berapa persen yang sudah tersedia di provider. Angka di atas 80 persen biasanya menandakan build tidak diperlukan.

#Menilai Keamanan Provider

Saat mengevaluasi, tanyakan hal yang sama seperti yang kalian implementasikan sendiri: di mana secret disimpan dan bagaimana dienkripsi, apakah recovery codes di-hash, apakah ada rate limiting yang bisa dikonfigurasi, dan bagaimana ekspor data jika pindah. Provider yang menjawab dengan jelas biasanya lebih aman daripada provider yang menolak detail.

Selain pertanyaan teknis, tanyakan SLA dan proses respons insiden. 2FA yang mati bersama provider adalah insiden yang sama seriusnya dengan kebocoran data — pastikan kalian tahu apa yang terjadi saat downtime.

#Authenticator Apps dan Kompatibilitas

#Google Authenticator di 2026

Google Authenticator tetap yang paling universal. Di 2026 ia mendukung backup ke Google Account, sinkronisasi antar perangkat, dan import/export. Backup ke Google Account adalah fitur penting: kehilangan perangkat tidak otomatis kehilangan semua akun TOTP.

Kelemahannya: fitur backup ke Google Account menuntut login Google yang bisa menjadi titik sentral — evaluasi apakah ini dapat diterima untuk akun yang ingin dipisahkan dari ekosistem Google.

#Microsoft Authenticator, Authy, dan 1Password

Aplikasi lain kompatibel karena semua mengikuti standar yang sama:

Microsoft Authenticator: TOTP plus push approval untuk akun Microsoft, kompatibel dengan URI otpauth.
Authy: backup terenkripsi lintas perangkat dengan multi-device.
1Password: TOTP terintegrasi dengan penyimpanan password, kode otomatis terisi.

Seluruhnya memakai TOTP RFC 6238, sehingga secret yang kalian buat di episode 4 bisa dipindai oleh semua aplikasi ini. Standar terbuka adalah alasan utama ekosistem authenticator bekerja tanpa fragmentasi.

Karena semuanya membaca parameter yang sama dari URI otpauth — secret, algorithm, digits, period — pertukaran antar aplikasi tidak pernah memerlukan migrasi data, cukup pindai ulang.

#Contoh Nyata: Tailscale dan SSO MFA

Produk yang memakai SSO dengan MFA menunjukkan bagaimana 2FA hidup di produk nyata:

tailscale up
tailscale status
tailscale logout

tailscale up mengarahkan browser ke alur SSO penyedia identitas yang dipilih organisasi — di situlah MFA (termasuk TOTP) dituntut. Setelah berhasil, tailscale status menampilkan node terautentikasi. Contoh ini memperlihatkan 2FA sebagai lapisan yang disembunyikan provider di balik alur login, bukan diimplementasikan ulang setiap produk.

Perhatikan juga atribut organisasi: SSO yang memaksa MFA adalah enforcement yang dibahas episode 18 — bukti bahwa keputusan teknis dan kebijakan organisasi selalu berjalan beriringan.

Untuk lab, praktikkan juga alur logout dan login ulang dengan akun SSO yang punya 2FA aktif, sehingga kalian merasakan pengalaman yang akan dirancang untuk pengguna.

#Memilih Kombinasi yang Tepat

#Default yang Aman

Untuk produk baru yang tidak punya kebutuhan enterprise khusus, kombinasi paling masuk akal di 2026: provider auth yang menyediakan passkeys untuk pengguna baru, TOTP sebagai fallback universal, dan SMS hanya untuk recovery dengan pengawasan ketat. Kalian tidak harus menulis semuanya — tapi kalian bisa mengauditnya.

Sedikit catatan: "default" di sini berarti titik awal yang disarankan, bukan kebijakan yang kaku — setiap aplikasi tetap menyesuaikan dengan risiko dan demografi penggunanya.

#Saat Kalian Sudah Punya Implementasi Sendiri

Jika sudah membangun sendiri seperti series ini, keputusan tetap di tangan: terus kembangkan internal untuk kontrol penuh, atau pindah ke provider saat tim bergeser. Evaluasi berkala — sekalipun tidak pindah, benchmark provider memberi target kualitas untuk implementasi sendiri.

Catat juga biaya operasional: memelihara secret storage, rotasi kunci, dan on-call untuk insiden 2FA adalah beban berkelanjutan yang harus dibandingkan dengan biaya langganan provider.

#Penutup

Episode 21 memetakan ekosistem: kapan memakai Clerk, Auth0, Supabase Auth, dan WorkOS, bagaimana menilai keamanan provider, serta kompatibilitas Google Authenticator, Microsoft Authenticator, Authy, dan 1Password yang semuanya mengikuti TOTP RFC 6238.

Inti yang harus dibawa pulang:

Provider 2FA menangani secret storage, backup codes, dan rate limit.
Pilih build jika kontrol dan kebijakan khusus menjadi kebutuhan inti.
Evaluasi keamanan provider dengan pertanyaan yang sama seperti audit internal.
Semua aplikasi authenticator besar kompatibel dengan URI otpauth.
Google Authenticator mendukung backup ke Google Account di 2026.
Kombinasi ideal 2026: passkeys, TOTP sebagai fallback, SMS untuk recovery.

Di episode 22 selanjutnya — episode penutup — kita akan membahas ekosistem, alternatif, dan refleksi akhir — perbandingan menyeluruh TOTP, WebAuthn, SMS, dan hardware key, kapan memilih masing-masing, rekap seluruh episode, dan checklist produksi final.