// docs / baas security / auth0 hardening

Checklist keamanan Auth0: 22 item

Auth0 adalah platform identity-as-a-service dengan permukaan yang sangat besar — aplikasi, API (resource server), tenant, action, rule (legacy), connection, dan grant. Miskonfigurasi salah satunya adalah bypass auth. Checklist ini adalah audit 22-item lintas aplikasi, allowlist callback / logout, token dan rotasi refresh, custom action, RBAC, deteksi anomali, dan pemantauan berkelanjutan. Setiap item dapat diverifikasi di Auth0 Dashboard dalam waktu kurang dari 10 menit.

Untuk checklist setara di Clerk, lihat Checklist keamanan Clerk. Untuk latar belakang mengapa miskonfigurasi lapisan identitas adalah titik buta AI-tool, lihat Mengapa AI coding tools meninggalkan celah keamanan.

Tipe aplikasi dan tipe grant

Tipe aplikasi dan tipe grant yang diaktifkan adalah pengaturan dengan dampak tertinggi di Auth0. Mendapatkannya salah membuka kelas serangan yang tidak akan ditutup oleh sebanyak apa pun kode frontend.

Gunakan Application Type = Single Page Application untuk aplikasi hanya-browser dan Regular Web Application untuk aplikasi server-rendered. Tipe yang salah mengizinkan tipe grant yang salah — misalnya, Regular Web App dengan grant SPA mengaktifkan alur Implicit tanpa-PKCE, yang membocorkan token via fragmen URL.
Nonaktifkan tipe grant Implicit pada setiap aplikasi. Dashboard → Application → Advanced Settings → Grant Types → hapus centang Implicit. Alur Implicit mengembalikan token di fragmen URL, di mana mereka dicatat di history browser dan analitik. Gunakan Authorization Code dengan PKCE sebagai gantinya.
Nonaktifkan grant Password kecuali Anda memiliki kebutuhan yang terdokumentasi. Grant Resource Owner Password Credentials (ROPC) mengharuskan Anda menangani password user sendiri — mengalahkan sebagian besar dari apa yang Anda beli Auth0 untuk itu. Nonaktifkan kecuali mengintegrasikan sistem warisan.
Aktifkan Authorization Code dengan PKCE pada setiap klien publik. Dashboard → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = enabled. PKCE diperlukan untuk aplikasi mobile dan SPA untuk mencegah intersepsi kode.

Allowlist URL callback dan logout

Open redirect pada path callback OAuth adalah primitif pencurian token. Allowlist Auth0 adalah satu-satunya pertahanan Anda.

Set Allowed Callback URLs ke path callback produksi persis Anda — tanpa wildcard. https://yourapp.com/callback, bukan https://yourapp.com/*. Callback wildcard memungkinkan penyerang mengarahkan token ke subpath sewenang-wenang di domain Anda.
Set Allowed Logout URLs ke daftar terbatas. Aturan sama: hanya URL eksplisit. Open logout redirect memungkinkan penyerang membuat halaman phishing yang terlihat seperti state pasca-logout Anda.
Set Allowed Web Origins hanya ke origin produksi Anda. Digunakan untuk autentikasi diam (perpanjangan token via iframe tersembunyi). Origin wildcard memungkinkan halaman penyerang melakukan auth diam terhadap tenant Anda.
Set Allowed CORS origins untuk endpoint API, bukan aplikasi. Tenant Settings → Advanced → Allowed CORS origins. Default kosong (dibatasi); hanya tambahkan origin eksplisit yang Anda kendalikan.

Token dan rotasi refresh

Lifetime token, rotasi refresh, dan algoritma penandatanganan memutuskan radius ledakan dari kebocoran token apa pun.

Aktifkan Refresh Token Rotation. Application → Refresh Token Settings → Rotation. Setiap refresh menerbitkan refresh token baru dan menginvalidasi yang lama. Dikombinasikan dengan kadaluarsa absolut, ini membatasi pencurian token.
Set Refresh Token Reuse Interval ke 0 (atau serendah toleransi replay Anda mengizinkan). Interval reuse memungkinkan token digunakan dua kali dalam jendela yang sama — matikan kecuali Anda memiliki alasan spesifik untuk mempertahankannya.
Set Absolute Refresh Token Expiry ke 14-30 hari, bukan infinity. Application → Refresh Token Expiration → Absolute Expiration. Auth0 default ke Inactivity-only, yang berarti sesi idle dapat bertahan bertahun-tahun.
Set JWT Signature Algorithm ke RS256. Application → Advanced → OAuth → JsonWebToken Signature Algorithm. RS256 menggunakan penandatanganan asimetris sehingga klien tidak dapat memalsukan token. Jangan pernah gunakan HS256 untuk aplikasi yang menghadap klien.
Verifikasi claim aud dan iss pada setiap JWT yang diterima API Anda. Gunakan SDK Auth0 resmi di sisi server — ia memverifikasi ini secara otomatis. Parsing JWT yang dibuat sendiri biasanya melewatkan validasi audience, yang merupakan bypass auth.

Action dan kode kustom

Auth0 Actions (dan Rules warisan) berjalan di sisi server pada login dan peristiwa siklus hidup lainnya. Mereka memiliki akses ke seluruh konteks request. Kode yang tidak aman di sini adalah kerentanan luas tenant.

Jangan pernah mencatat event.user atau event.transaction sebagai objek utuh. Ini berisi alamat email, alamat IP, dan PII lainnya. Gunakan pencatatan tingkat field saja, dan hanya catat apa yang Anda butuhkan.
Gunakan secrets store untuk API key atau URL webhook apa pun. Actions → Edit → Secrets. Jangan pernah inline API key sebagai literal string dalam kode action — kode terlihat oleh siapa saja dengan akses Action editor di tenant.
Validasi input sebelum menyimpannya sebagai user_metadata atau app_metadata. Action layanan-mandiri yang menulis event.body.name ke user.user_metadata.display_name adalah vektor stored-XSS jika frontend Anda merender field itu tanpa escape.

RBAC dan resource server

Jika Anda menggunakan Auth0 RBAC, pemetaan role-ke-izin adalah lapisan otorisasi Anda. Mendapatkannya salah dan user terautentikasi mana pun dapat menyentuh endpoint admin.

Definisikan Resource Server (API) secara eksplisit di Auth0 Dashboard, bukan secara langsung. Setiap API memiliki pengenal (audience), scope, dan pengaturan penandatanganan. Tanpa API yang terdaftar, semua token diterbitkan untuk "Auth0 Management API" implisit — audience salah.
Konfigurasikan Permission per API dan minta mereka dalam kode Anda dengan claim scope. Jangan periksa keanggotaan role dalam logika aplikasi Anda; periksa scope di access token. Scope adalah mekanisme otorisasi native OAuth.
Uji bahwa user terautentikasi tanpa role / scope yang diperlukan tidak dapat menyentuh endpoint berhak istimewa. Masuk sebagai user normal, coba panggil POST /api/admin/users/delete. Response harus 403.

Deteksi anomali dan log tenant

Auth0 mengeluarkan peristiwa dengan sinyal tinggi. Atur agar mereka memperingatkan tim Anda, bukan hanya duduk di buffer log.

Aktifkan Attack Protection: Bot Detection, Brute Force, Suspicious IP Throttling. Dashboard → Security → Attack Protection. Masing-masing mati secara default pada tier gratis; aktifkan semuanya untuk produksi.
Streamingkan log tenant ke SIEM atau log aplikasi Anda. Dashboard → Monitoring → Streams. Auth0 menyimpan log selama 30 hari pada sebagian besar paket; retensi jangka panjang memerlukan stream ke sistem Anda sendiri.
Beri peringatan pada lonjakan fcoa (failed cross-origin auth) dan fp (failed login). Ledakan ini dalam jendela pendek adalah credential stuffing. Arahkan ke channel on-call Anda.

Langkah berikutnya

Jalankan scan FixVibe terhadap URL produksi Anda — check baas.clerk-auth0 menandai client secret Auth0 yang ter-bundle di JavaScript dan kelas eksposur identity-provider lainnya. Untuk setara di Clerk, lihat Checklist keamanan Clerk. Untuk tinjauan menyeluruh lintas penyedia BaaS, baca Scanner miskonfigurasi BaaS.