Konfigurasi masuk yang di-hosting
Daftarkan URL callback yang tepat dan origin web Anda untuk aplikasi sandbox Anda. Salin origin masuk (https://<slug>.sandbox.auth.didit.me) dari konsol, seperti dijelaskan di ikhtisar. Contoh ini menggunakan API kriptografi browser dan memerlukan HTTPS, atau localhost di sandbox: lihat pengembangan lokal untuk mengetahui apa yang perlu didaftarkan.
Aplikasi Anda yang mengelola state dan verifier PKCE. Masuk yang di-hosting mengelola layar kata sandi, email, passkey, telepon, SSO, dan MFA yang wajib. Tidak ada kunci API yang boleh ada dalam kode ini.
auth.js
signIn() dari tombol masuk Anda. Pada halaman callback yang sudah didaftarkan, panggil handleCallback() satu kali, tampilkan status memuat, dan tampilkan errornya jika gagal. Gunakan getSession() untuk pengguna saat ini dan signOut() untuk keluar. Callback menghapus kodenya dari bilah alamat sebelum membuat permintaan.
Contoh minimal ini menyimpan token di memori dan meminta masuk ulang setelah halaman dimuat ulang atau token akses kedaluwarsa. Untuk sesi yang persisten, gunakan backend Anda dan cookie aman, atau terapkan rotasi refresh token secara serial. Jangan pernah menaruh refresh token di URL atau log. Pemeriksaan sesi di frontend hanya mengatur tampilan; backend Anda harus memvalidasi pemanggil pada setiap permintaan yang dilindungi.
Pratinjau rilis SDK autentikasi
Inti@didit-protocol/auth yang direncanakan menyediakan createDiditAuth({publishableKey}), signIn(), handleRedirectCallback(), getSession(), getToken(), onAuthStateChange, dan signOut(), dengan vendorData pada identitas. SDK ini dimaksudkan untuk menambahkan sinyal perangkat otomatis dan titik masuk server dengan verifyToken().
Kunci yang dapat dipublikasikan berupa pk_live_ (aplikasi produksi) atau pk_test_ (aplikasi sandbox), diikuti encoding base64url tanpa padding dari origin aplikasi Anda.
SDK mengirim panggilan API-nya ke origin tersebut.
Kunci ini bersifat publik: kunci ini mengidentifikasi aplikasi dan bukan rahasia.
Step-up dan autentikasi ulang dalam pratinjau
stepUp({ action, amount?, currency?, redirectUri? })memanggil endpointPOST step-up/pada aplikasi Anda untuk menanyakan apakahactionmemerlukan pemeriksaan identitas.actionberupapayout,bank, ataucontact, dan pencairan memerlukanamount. Ketika salah satu aturan step-up Anda berlaku, SDK mengarahkan ke halaman verifikasi yang dikembalikan Didit.handleStepUpCallback(url?)dijalankan di halaman tempat orang tersebut kembali. Fungsi ini membaca?step_up=<id>, menghapusnya dari bilah alamat, dan membaca hasilnya denganGET step-up/{id}/.reauthenticate({ method? })masuk kembali dengan orang yang sama, di halaman yang di-hosting (method: "redirect", bawaan) atau dengan passkey (method: "passkey", hanya pada domain masuk Didit milik aplikasi Anda). Setelah halaman yang di-hosting, selesaikan denganhandleRedirectCallback(). Jika orang lain yang menyelesaikannya, proses ditolak denganstep_up_user_mismatchdan sesi asli tetap berlaku.
{ id, status, approved, rule, method }, dengan status berupa not_required, pending, approved, review, declined, atau expired.
redirectUri menggunakan alamat redirect klien sebagai bawaan dan harus sama persis dengan salah satu alamat redirect aplikasi Anda yang sudah didaftarkan: ketika pemeriksaan diperlukan, Didit menolak alamat lain.
Sebelum backend Anda bertindak berdasarkan step-up, baca kembali step-up dengan GET step-up/{id}/ dan token akses pengguna, karena hasil yang dilaporkan browser bisa diubah.
Masuk tanpa antarmuka juga dapat mengembalikan protection_required ketika aturan proteksi aplikasi Anda menandainya. Pengguna kemudian menyelesaikannya dengan kode yang dikirim Didit ke emailnya (protection.verify({ code })) atau dengan passkey (protection.passkey()), dan methods berisi daftar metode mana dari kedua metode tersebut yang dapat mereka gunakan.
Jangan memasang versi yang hanya diperkirakan atau menulis kode berdasarkan opsi callback yang hanya diperkirakan. Pastikan ekspor paket yang dipublikasikan, penerbit, dan konfigurasi kunci sebelum mengganti contoh yang di-hosting. Kata sandi, kode email, tautan ajaib, passkey, telepon, MFA, masuk melalui media sosial, step-up, dan metode agen akan bergantung pada API yang didukung rilis tersebut.
Tambahkan produk lain
Backend Anda memverifikasi token akses (lihat token dan JWKS) dan membacavendor_data-nya. Gunakan nilai itu sebagai vendor_data saat membuat sesi verifikasi atau membuat token transaksi. Masuk yang berhasil tidak berarti salah satu produk tersebut telah menyetujui pengguna.
Sebelum rilis, uji pendaftaran, masuk kembali, pembatalan, state yang tidak cocok, kode yang dipakai ulang, lupa kata sandi, MFA, kedaluwarsa, dan keluar pada aplikasi sandbox Anda yang sudah diaktifkan.