Pelajari bagaimana kode yang dihasilkan AI biasanya menginfer sistem login, otorisasi, dan peran, pola yang dipakai, serta cara memvalidasi dan menguatkan hasilnya.

Autentikasi menjawab: “Siapa kamu?” Ini langkah di mana aplikasi memverifikasi identitas—biasanya dengan kata sandi, kode sekali pakai, login OAuth (Google, Microsoft), atau token bertanda tangan seperti JWT.
Otorisasi menjawab: “Apa yang boleh kamu lakukan?” Setelah aplikasi tahu siapa kamu, ia memeriksa apakah kamu boleh melihat halaman ini, mengedit data itu, atau memanggil endpoint API ini. Otorisasi berkaitan dengan aturan dan keputusan.
Peran (sering disebut RBAC—Role-Based Access Control) adalah cara umum untuk mengorganisir otorisasi. Daripada memberi puluhan izin ke setiap pengguna, Anda menetapkan peran (seperti Admin, Manager, Viewer), dan peran itu menggambarkan sekumpulan izin.
Saat Anda menghasilkan kode dengan AI (termasuk platform "vibe-coding" seperti Koder.ai), menjaga batasan-batasan ini tetap jelas sangat penting. Cara tercepat untuk mengirimkan sistem yang tidak aman adalah membiarkan “login” dan “permissions” runtuh menjadi satu fitur "auth" yang samar.
Alat AI sering menggabungkan autentikasi, otorisasi, dan peran karena prompt dan contoh kode yang diberikan juga mengaburkannya. Anda akan melihat keluaran di mana:
Ini bisa menghasilkan kode yang bekerja pada demo jalur bahagia tetapi memiliki batasan keamanan yang tidak jelas.
AI dapat membuat pola umum—alur login, penanganan session/JWT, dan pengkabelan RBAC dasar—tetapi AI tidak bisa menjamin aturan Anda sesuai kebutuhan bisnis atau bahwa kasus tepi aman. Manusia masih perlu memvalidasi skenario ancaman, aturan akses data, dan konfigurasi.
Selanjutnya, kita akan membahas bagaimana AI menginfer persyaratan dari prompt dan codebase Anda, alur autentikasi tipikal yang dihasilkan (JWT vs session vs OAuth), bagaimana otorisasi diimplementasikan (middleware/guard/policy), celah keamanan yang sering muncul, dan daftar periksa prompting serta review praktis untuk membuat kontrol akses yang dihasilkan AI lebih aman.
AI tidak “menemukan” persyaratan auth Anda seperti rekan kerja. Ia menginfer dari beberapa sinyal dan mengisi kekosongan dengan pola yang paling sering dilihatnya.
Sebagian besar kode auth dan role yang dihasilkan AI dibentuk oleh:
Jika Anda menggunakan builder chat-first seperti Koder.ai, Anda memiliki tuas ekstra: Anda bisa menyimpan pesan "spesifikasi keamanan" yang dapat digunakan ulang (atau menggunakan langkah perencanaan) yang platform terapkan secara konsisten saat menghasilkan route, service, dan model database. Itu mengurangi drift antar fitur.
Jika codebase Anda sudah berisi User, Role, dan Permission, AI biasanya akan mencerminkan kosakata itu—membuat tabel/collection, endpoint, dan DTO yang cocok dengan nama-nama tersebut. Jika Anda malah menggunakan Account, Member, Plan, atau Org, skema yang dihasilkan sering bergeser ke semantik subscription atau tenancy.
Isyarat penamaan kecil dapat mengarahkan keputusan besar:
Ketika Anda tidak menentukan detail, AI sering berasumsi:
AI mungkin menyalin pola populer (mis., "roles array di JWT", "isAdmin boolean", "permission strings di middleware") karena sering digunakan—bukan karena cocok dengan model ancaman atau kebutuhan kepatuhan Anda.
Perbaikannya sederhana: nyatakan batasan secara eksplisit (batasan tenancy, granularitas peran, masa hidup token, dan di mana pemeriksaan harus ditegakkan) sebelum memintanya menghasilkan kode.
Alat AI cenderung merakit autentikasi dari template yang familiar. Itu membantu untuk kecepatan, tetapi juga berarti Anda sering mendapatkan alur yang paling umum, bukan yang sesuai tingkat risiko, kebutuhan kepatuhan, atau UX produk Anda.
Email + password adalah default. Kode yang dihasilkan biasanya mencakup endpoint registrasi, endpoint login, reset password, dan endpoint "current user".
Magic links (link/kode sekali pakai lewat email) sering muncul ketika Anda menyebut "passwordless." AI umum menghasilkan tabel untuk token sekali pakai dan endpoint untuk memverifikasinya.
SSO (OAuth/OIDC: Google, Microsoft, GitHub) muncul saat Anda meminta "Sign in with X." AI biasanya menggunakan integrasi library dan menyimpan provider user ID plus email.
API tokens umum untuk "akses CLI" atau "server-to-server." Kode yang dihasilkan sering membuat token statis per pengguna (atau per aplikasi) dan memeriksanya di setiap permintaan.
Jika prompt Anda menyebut "stateless", "mobile apps", atau "microservices", AI biasanya memilih JWT. Jika tidak, seringkali default ke server-side sessions.
Dengan JWT, kode yang dihasilkan sering:
localStorage (praktis, tapi lebih berisiko terhadap XSS)Dengan sessions, ia sering paham konsepnya tapi lupa pengamanan cookie. Anda mungkin perlu secara eksplisit meminta pengaturan cookie seperti HttpOnly, Secure, dan kebijakan SameSite yang ketat.
Bahkan ketika alurnya bekerja, bagian "membosankan" dari keamanan mudah dihilangkan:
Nyatakan alur dan batasan di satu tempat: "Gunakan session sisi-server dengan cookie aman, tambahkan rate limit login, gunakan Argon2id dengan parameter yang ditentukan, dan implementasikan token reset password yang kedaluwarsa dalam 15 menit."
Jika Anda ingin JWT, tentukan penyimpanan (lebih suka cookie), rotasi, dan strategi revokasi di awal.
Tip untuk builder berbantuan AI: di Koder.ai, Anda bisa meminta sistem untuk menghasilkan tidak hanya endpoint tetapi juga “acceptance checks” (kode status, flag cookie, TTL token) sebagai bagian dari rencana, lalu iterasi dengan snapshot/rollback jika implementasi menyimpang.
Otorisasi adalah bagian yang menjawab: “Apakah pengguna yang sudah diautentikasi ini diizinkan melakukan tindakan ini pada sumber daya itu?” Dalam proyek yang dihasilkan AI, ini biasanya diimplementasikan sebagai rantai pemeriksaan yang tersebar di sepanjang jalur permintaan.
Sebagian besar kode yang dihasilkan mengikuti tumpukan yang dapat diprediksi:
user (atau principal) ke request.billing:read".Pendekatan berlapis ini baik bila setiap lapisan memiliki tanggung jawab jelas: autentikasi mengidentifikasi pengguna; otorisasi mengevaluasi izin; pemeriksaan database memverifikasi fakta khusus sumber daya.
Kode yang dihasilkan AI sering mengarah ke allow by default: jika kebijakan hilang, endpoint tetap bekerja. Itu nyaman selama scaffolding, tetapi berisiko—route baru atau refactor diam-diam menjadi publik.
Polanya yang lebih aman adalah deny by default:
@Public()), bukan mengandalkan penghilangan.Dua gaya wiring umum muncul:
@Roles('admin'), @Require('project:update')). Mudah dibaca, tapi mudah terlupa.can(user, action, resource)), dipanggil dari controller/service. Lebih konsisten, tapi membutuhkan disiplin agar developer tidak melewatinya.Bahkan ketika route HTTP terlindungi, kode yang dihasilkan sering lupa titik masuk non-jelas:
Perlakukan setiap jalur eksekusi—HTTP, job, webhook—sebagai memerlukan jaminan otorisasi yang sama.
Saat AI menghasilkan kode otorisasi, biasanya harus memilih model meskipun Anda tidak menentukan. Pilihan sering mencerminkan apa yang umum dalam tutorial dan framework, bukan yang paling sesuai produk Anda.
RBAC (Role-Based Access Control) menetapkan pengguna peran seperti admin, manager, atau viewer, dan kode memeriksa peran untuk mengizinkan aksi.
Permission-based access menetapkan kapabilitas eksplisit seperti invoice.read atau invoice.approve. Peran masih bisa ada sebagai bundel izin.
ABAC (Attribute-Based Access Control) memutuskan berdasarkan atribut dan konteks: departemen pengguna, pemilik resource, waktu, tenant, tier langganan, region, dll. Aturannya seperti "bisa edit jika user.id == doc.ownerId" atau "bisa export jika plan == pro dan region == EU."
Hybrid paling umum di aplikasi nyata: RBAC untuk perbedaan admin vs non-admin secara luas, ditambah permissions dan pemeriksaan resource untuk detail.
Kode yang dihasilkan AI cenderung default ke RBAC karena mudah dijelaskan dan diimplementasikan: kolom role pada users, middleware yang memeriksa req.user.role, dan beberapa pernyataan if.
RBAC biasanya cukup ketika:
Itu mulai berat ketika “role” menjadi tempat menumpuk aturan detail ("support_admin_limited_no_export_v2").
Aturan praktis: gunakan peran untuk identitas, izin untuk kapabilitas.
Jika Anda terus menambah peran setiap sprint, besar kemungkinan Anda memerlukan sistem izin (dan mungkin pemeriksaan kepemilikan).
Mulai dengan:
users.role dengan 2–4 peranLalu berkembang ke:
Ini menjaga kode awal terbaca sambil memberi jalur bersih untuk menskalakan otorisasi tanpa menulis ulang semuanya.
Sistem auth yang dihasilkan AI cenderung mengikuti beberapa bentuk database yang familiar. Mengetahui pola-pola ini membantu Anda menyadari saat model menyederhanakan kebutuhan—terutama seputar multi-tenancy dan aturan kepemilikan.
Sebagian besar kode yang dihasilkan membuat tabel users plus salah satu:
roles, user_roles (tabel join)permissions, role_permissions, dan kadang user_permissionsTata relasi relasional tipikal terlihat seperti:
users(id, email, password_hash, ...)
roles(id, name)
permissions(id, key)
user_roles(user_id, role_id)
role_permissions(role_id, permission_id)
AI sering memberi nama role seperti admin, user, editor. Itu ok untuk prototipe, tetapi di produk nyata Anda ingin identifier yang stabil (mis., key = "org_admin") dan label yang mudah dibaca disimpan terpisah.
Jika prompt Anda menyebut “teams”, “workspaces”, atau “organizations”, AI sering menginfer multi-tenancy dan menambahkan field organization_id / tenant_id. Kesalahan adalah inkonsistensi: bisa jadi field ditambahkan ke users tapi lupa ditambahkan pada roles, tabel join, atau tabel resource.
Tentukan sejak awal apakah:
Dalam RBAC berskala-org, biasanya Anda memerlukan roles(..., organization_id) dan user_roles(..., organization_id) (atau tabel memberships yang meng-anchorkan relasi tersebut).
Peran menjawab “apa yang orang ini bisa lakukan?” Kepemilikan menjawab “apa yang bisa mereka lakukan pada catatan tertentu?” Kode yang dihasilkan AI sering lupa kepemilikan dan berusaha menyelesaikan semuanya dengan peran.
Polanya praktis adalah menyimpan field kepemilikan eksplisit pada resource (mis., projects.owner_user_id) dan menegakkan aturan seperti "owner ATAU org_admin bisa mengedit." Untuk resource bersama, tambahkan tabel keanggotaan (mis., project_members(project_id, user_id, role)), daripada memaksa peran global.
Migrasi yang dihasilkan sering kali melewatkan constraint yang mencegah bug auth halus:
users.email (dan (organization_id, email) di setup multi-tenant)(user_id, role_id) dan (role_id, permission_id)user_roles, tapi hindari cascading ke resource bersama secara tidak sengajaJika skema tidak meng-encode aturan-aturan ini, lapisan otorisasi Anda akan menambal di kode—biasanya dengan cara yang tidak konsisten.
Stack auth yang dihasilkan AI sering berbagi "assembly line" yang dapat diprediksi: autentikasi permintaan, muat konteks user, lalu otorisasi setiap aksi menggunakan policy yang dapat dipakai ulang.
Sebagian besar generator kode menghasilkan campuran dari:
Authorization: Bearer <JWT>, memverifikasinya, dan melampirkan req.user (atau konteks setara).canEditProject(user, project) atau requireRole(user, "admin").Kode AI sering menaruh pemeriksaan langsung di controller karena mudah dihasilkan. Itu bekerja untuk aplikasi sederhana, tetapi cepat menjadi tidak konsisten.
Pola wiring yang lebih aman adalah:
WHERE org_id = user.orgId) supaya Anda tidak sengaja mengambil data yang dilarang lalu memfilternya kemudian.Centralisasikan keputusan di pembantu policy dan standarisasi respons. Misalnya, selalu kembalikan 401 ketika belum diautentikasi dan 403 ketika diautentikasi tetapi dilarang—jangan campur aduk antar endpoint.
Sebuah pembungkus authorize(action, resource, user) yang tunggal mengurangi bug "lupa cek" dan mempermudah audit. Jika Anda membangun dengan Koder.ai dan mengekspor kode yang dihasilkan, titik entri seperti ini juga merupakan "hotspot diff" yang nyaman untuk ditinjau setelah setiap iterasi.
Kode yang dihasilkan AI mungkin melakukan cache role/claim secara agresif. Lebih baik:
permissions_version saat role berubah).Itu membuat otorisasi cepat sambil memastikan pembaruan role segera berlaku.
AI dapat menghasilkan autentikasi dan pemeriksaan peran yang bekerja dengan cepat, tapi sering mengoptimalkan untuk "jalur bahagia". Saat prompt samar, contoh tidak lengkap, atau codebase kurang konvensi, model cenderung merangkai snippet umum yang pernah dilihat—kadang termasuk default yang tidak aman.
Masalah umum adalah membuat token atau session yang berlaku terlalu lama, tidak pernah berotasi, atau disimpan tidak aman.
HttpOnly, Secure, dan SameSite yang sesuai, atau session disimpan di localStorage "karena gampang."Pencegahan: minta expirasi eksplisit, implementasikan rotasi refresh-token dengan revokasi sisi-server, dan standarkan pengaturan cookie di satu pembantu agar setiap route menggunakan default aman yang sama.
Kode yang dihasilkan sering memeriksa "sudah login" tapi lupa "diizinkan". Kegagalan tipikal meliputi:
/orders/:id tanpa memverifikasi pesanan milik pengguna saat ini.role dari body request atau header alih-alih klaim yang disimpan server.isAdmin menggantikan otorisasi per-record.Pencegahan: tegakkan otorisasi sisi-server dari data otoritatif, tambahkan pemeriksaan tingkat objek di lapisan data (mis., query difilter oleh userId/orgId), dan default ke menolak akses kecuali diizinkan secara eksplisit.
AI terkadang “membantu” dengan shortcut testing: email admin yang di-hardcode, password default, atau route admin yang tidak terdokumentasi.
Pencegahan: larang kredensial yang di-hardcode dalam review, minta feature flags untuk endpoint debug, dan gagalkan build jika scanning/lint menemukan secrets/password default.
AI akan dengan senang hati mengisi detail kontrol akses dengan "default yang masuk akal"—yang justru cara bug keamanan halus dikirim. Pendekatan paling aman adalah memperlakukan prompt seperti mini spesifikasi keamanan: persyaratan eksplisit, non-persyaratan eksplisit, dan acceptance test eksplisit.
Tuliskan apa yang ada di produk Anda dan bagaimana seharusnya berperilaku:
admin, manager, member, viewer) dan bagaimana pengguna mendapatkannya.org_id mereka", termasuk kasus tepi seperti undangan lintas-org.Ini mencegah model mengarang "admin bypass" yang terlalu luas atau melewatkan isolasi tenant.
Jika Anda bekerja di sistem yang mendukung langkah perencanaan terstruktur (mis., mode perencanaan Koder.ai), minta model untuk mengeluarkan:
Baru hasilkan kode setelah rencana itu terlihat benar.
Minta:
401 (belum login) vs 403 (sudah login, tapi tidak diizinkan), tanpa membocorkan detail sensitif.Jangan hanya meminta implementasi—minta bukti:
Sertakan yang tidak bisa dinegosiasikan seperti:
Jika Anda ingin prompt template yang dapat dipakai ulang tim, simpan di dokumen bersama dan link secara internal (mis., /docs/auth-prompt-template).
AI bisa menghasilkan auth yang bekerja cepat, tapi review harus menganggap kode belum lengkap sampai terbukti sebaliknya. Gunakan daftar periksa yang fokus pada cakupan (di mana akses ditegakkan) dan kebenaran (bagaimana akses ditegakkan).
Daftarkan setiap titik masuk dan verifikasi aturan akses yang sama ditegakkan konsisten:
Teknik cepat: scan setiap fungsi akses data (mis., getUserById, updateOrder) dan konfirmasi ia menerima actor/context dan menerapkan cek.
Verifikasi detail implementasi yang mudah dilewatkan AI:
HttpOnly, Secure, SameSite benar; TTL session pendek; rotasi saat login.* dengan credentials; preflight ditangani.Pilih library JWT/OAuth/hashing password yang dikenal aman; hindari kripto kustom.
Jalankan analisis statis dan pemeriksaan dependency (SAST + npm audit/pip-audit/bundle audit) dan pastikan versi sesuai kebijakan keamanan Anda.
Terakhir, tambahkan gerbang peer-review untuk setiap perubahan auth/authz, bahkan jika ditulis AI: minta setidaknya satu reviewer mengikuti daftar periksa dan memverifikasi tes mencakup kasus diizinkan dan ditolak.
Jika alur kerja Anda mencakup generasi kode cepat (mis., dengan Koder.ai), gunakan snapshot dan rollback untuk menjaga tinjauan ketat: hasilkan perubahan kecil yang dapat ditinjau, jalankan tes, dan revert cepat jika keluaran memperkenalkan default berisiko.
Bug kontrol akses sering "diam": pengguna melihat data yang tidak seharusnya, dan tidak ada yang crash. Ketika kode dihasilkan AI, tes dan monitoring adalah cara tercepat untuk mengonfirmasi aturan yang Anda pikir jalankan memang benar-benar dijalankan.
Mulailah dengan menguji titik keputusan terkecil: pembantu policy/permission (mis., canViewInvoice(user, invoice)). Bangun "matriks peran" compact di mana tiap peran dites terhadap tiap aksi.
Fokus pada kasus izinkan dan tolak:
Tanda baik adalah ketika tes memaksa Anda mendefinisikan apa yang terjadi saat data hilang (tidak ada tenant id, tidak ada owner id, user null).
Tes integrasi harus mencakup flow yang sering rusak setelah AI refactor:
Tes ini harus memanggil route/controller nyata dan memverifikasi status HTTP dan body respons (tidak ada kebocoran data parsial).
Tambahkan tes eksplisit untuk:
Log penolakan otorisasi dengan kode alasan (bukan data sensitif), dan beri alert pada:
Anggap metrik ini sebagai gerbang rilis: jika pola penolakan berubah tak terduga, investigasi sebelum pengguna melaporkan.
Meluncurkan auth yang dihasilkan AI bukan sekali jadi. Perlakukan seperti perubahan produk: definisikan aturan, implementasikan irisan sempit, verifikasi perilaku, lalu perluas.
Sebelum mem-prompt kode, tuliskan aturan akses Anda dengan bahasa biasa:
Ini menjadi "sumber kebenaran" untuk prompt, review, dan tes. Jika mau template cepat, lihat /blog/auth-checklist.
Pilih satu pendekatan utama—session cookie, JWT, atau OAuth/OIDC—dan dokumentasikan di repo (README atau /docs). Minta AI mengikuti standar itu setiap kali.
Hindari pola campuran (mis., beberapa endpoint menggunakan session, lainnya JWT) kecuali Anda punya rencana migrasi dan batasan yang jelas.
Tim sering mengamankan route HTTP tapi lupa "pintu samping." Pastikan otorisasi ditegakkan konsisten untuk:
Minta AI menunjukkan di mana cek terjadi dan agar ia gagal tertutup (default deny).
Mulai dengan satu user journey end-to-end (mis., login + lihat akun + perbarui akun). Merge di balik feature flag jika perlu. Lalu tambahkan irisan berikutnya (mis., aksi khusus admin).
Jika Anda membangun end-to-end dengan Koder.ai (mis., React web app, backend Go, dan database PostgreSQL), pendekatan irisan tipis juga membantu membatasi apa yang model hasilkan: diff lebih kecil, batas review lebih jelas, dan lebih sedikit bypass otorisasi tidak sengaja.
Gunakan proses review berbasis daftar periksa dan wajibkan tes untuk tiap aturan izin. Pertahankan beberapa monitor "tidak boleh pernah terjadi" (mis., non-admin mengakses endpoint admin).
Untuk keputusan pemodelan (RBAC vs ABAC), selaraskan lebih awal dengan /blog/rbac-vs-abac.
Rollout bertahap lebih baik daripada rewrite besar—terutama saat AI bisa menghasilkan kode lebih cepat daripada tim bisa memvalidasinya.
Jika Anda ingin lapisan keamanan tambahan, pilih alat dan alur kerja yang mempermudah verifikasi: kode sumber yang dapat diekspor untuk audit, deployment yang dapat diulang, dan kemampuan revert cepat bila perubahan yang dihasilkan tidak memenuhi spesifikasi keamanan Anda. Koder.ai didesain untuk gaya iterasi seperti itu, dengan export source dan snapshot-based rollback—berguna saat Anda mengencangkan kontrol akses melalui beberapa generasi kode yang dihasilkan AI.