Cara Menambahkan Login ke Aplikasi Anda: Kata Sandi, Magic Link, Google, dan Peran

Untuk menambahkan login ke aplikasi, pilih satu metode — email dan kata sandi, magic link (tautan masuk sekali pakai yang dikirim lewat email), atau "Masuk dengan Google" — dan terapkan dengan library auth yang sudah terbukti atau penyedia yang di-hosting, bukan dari nol. Lalu tentukan apa yang boleh dilakukan setiap jenis pengguna (peran), dan terapkan itu di server untuk setiap halaman dan permintaan API. Sesi sebaiknya memakai cookie yang aman, berakhir pada waktunya, dan benar-benar berakhir saat logout.

Panduan ini membahas setiap pilihan dan detail yang membedakan login yang berfungsi dari login yang aman. Untuk konsep di baliknya, lihat apa itu autentikasi.

Putuskan dulu: apakah Anda memerlukan login?

Login menambah hambatan dan tanggung jawab. Anda membutuhkannya ketika:

• Pengguna memiliki data privat (pemesanan, dokumen, faktur mereka)
• Pengguna bisa mengubah hal yang akan dilihat orang lain
• Anda memungut biaya untuk akses
• Orang yang berbeda membutuhkan izin yang berbeda (pemilik vs staf vs pelanggan)

Anda mungkin tidak memerlukannya untuk situs pemasaran, direktori publik, atau formulir yang hanya mengirimkan email kepada Anda. Daftar tunggu tidak memerlukan akun; kolom email sudah cukup.

Empat metode login yang umum

Banyak aplikasi menggabungkan dua metode: masuk dengan Google ditambah magic link email adalah pasangan populer yang mencakup sebagian besar orang tanpa menyimpan kata sandi apa pun.

Email dan kata sandi

Jika Anda menawarkan kata sandi, ini hal yang wajib:

• Hash kata sandi dengan algoritma hashing yang lambat. Panduan penyimpanan kata sandi dari OWASP merekomendasikan Argon2id, dengan scrypt, bcrypt, atau PBKDF2 sebagai alternatif. Jangan pernah menyimpan kata sandi dalam teks biasa atau dengan hash umum yang cepat.
• Reset kata sandi memakai tautan acak sekali pakai yang kedaluwarsa, dikirim ke email yang sudah diverifikasi.
• Jangan mengungkap email mana yang punya akun. "Jika email itu terdaftar, kami sudah mengirim tautan reset" lebih baik daripada "Akun tidak ditemukan".
• Batasi laju percobaan login dan reset untuk memperlambat tebak-tebakan kata sandi.
• Izinkan kata sandi panjang dan pengelola kata sandi; hindari aturan yang memaksa kombinasi karakter yang aneh.

Magic link dan kode sekali pakai

Magic link adalah tautan masuk yang dikirim ke email pengguna. Mengkliknya langsung membuat mereka masuk. Kode sekali pakai adalah ide yang sama, tetapi diketik alih-alih diklik.

• Tautan dan kode kedaluwarsa dengan cepat dan hanya bisa dipakai sekali.
• Tautan sebaiknya membuat pengguna masuk di perangkat tempat mereka mengkliknya, dan token tidak boleh tertinggal di log atau alat analitik.
• Anda membutuhkan pengiriman email yang andal — lihat cara mengirim email dari aplikasi Anda. Uji dengan Gmail dan Outlook, dan periksa folder spam.

Masuk dengan Google (dan penyedia OAuth lainnya)

"Masuk dengan Google" memakai OAuth dan OpenID Connect: Google memastikan siapa pengguna itu dan memberi tahu aplikasi Anda email dan nama mereka. Penyiapannya, per September 2026, dilakukan di bagian Google Auth Platform di Google Cloud Console:

1. Buat atau pilih proyek, dan isi halaman Branding — yang dilihat pengguna di layar persetujuan (nama aplikasi, email dukungan, logo).
2. Di halaman Clients, buat klien dengan tipe "Web application".
3. Tambahkan authorized JavaScript origins dan redirect URI — alamat persis tempat aplikasi Anda berjalan dan tempat Google mengirim pengguna kembali setelah masuk.
4. Simpan client ID dan client secret di secret aplikasi Anda.

Hal-hal yang sering salah, menurut dokumentasi OAuth Google:

• redirect_uri_mismatch: alamat redirect harus cocok persis, termasuk http vs https, huruf besar-kecil, dan garis miring di akhir. Tambahkan satu untuk alamat pratinjau dan satu untuk domain live Anda.
• HTTPS wajib: redirect URI harus memakai HTTPS, kecuali localhost saat pengembangan.
• Parameter state sebaiknya diperiksa saat kembali untuk melindungi dari cross-site request forgery. Library yang baik melakukan ini untuk Anda.

Jika Anda hanya meminta informasi masuk dasar (nama, email, profil), Google menyatakan verifikasi aplikasi tidak wajib. Meminta akses ke Gmail, Drive, atau Kalender pengguna berbeda dan memerlukan verifikasi.

Bangun sendiri atau pakai penyedia?

Keduanya dari dua opsi pertama sama-sama wajar. Penyedia yang di-hosting menangani lebih banyak untuk Anda tetapi menambah ketergantungan dan kadang dikenai biaya per pengguna aktif; periksa harga terkini di situs mereka. Library menyimpan semuanya di database Anda tetapi menyisakan lebih banyak konfigurasi yang harus Anda lakukan dengan benar. Apa pun pilihannya, mintalah AI untuk memakainya alih-alih menulis sendiri logika kata sandi atau sesi.

Peran dan izin

Login memberi tahu Anda siapa seseorang. Izin menentukan apa yang boleh mereka lakukan. Buat sederhana di awal:

Aturan yang lebih penting daripada nama peran:

• Periksa di server, setiap kali. Menyembunyikan tombol di halaman tidak menghentikan siapa pun memanggil API secara langsung.
• Batasi berdasarkan pemilik. Anggota yang mengambil "pemesanan 123" hanya boleh mendapatkannya jika itu miliknya.
• Pengguna tidak bisa menaikkan peran sendiri. Abaikan kolom peran yang dikirim dari browser saat memperbarui profil.
• Default ke tanpa akses. Route baru sebaiknya memerlukan login kecuali Anda memutuskan sebaliknya.

Uji dengan dua akun: masuk sebagai yang satu, catat ID sebuah catatan, lalu masuk sebagai yang lain dan coba membukanya. Checklist keamanan kami memuat pengujian lengkapnya.

Keamanan sesi

Setelah login, aplikasi mengingat pengguna dengan sesi — biasanya cookie. Panduan manajemen sesi dari OWASP merekomendasikan:

• Cookie sesi diatur dengan Secure (hanya HTTPS), HttpOnly (tidak bisa dibaca skrip halaman), dan SameSite
• ID sesi baru diterbitkan saat login, dan lagi saat hak akses berubah
• Timeout saat idle dan masa berlaku maksimum mutlak, ditegakkan di server
• Logout yang mengakhiri sesi di server, bukan hanya menghapus cookie
• Sesi dibatalkan saat pengguna mengubah kata sandinya

Menyimpan token login di local storage browser sering muncul di tutorial, tetapi itu membuatnya bisa diakses skrip apa pun yang berjalan di halaman; cookie aman biasanya pilihan default yang lebih baik untuk aplikasi web.

Prompt yang mencakup hal-hal penting

Tambahkan akun pengguna ke aplikasi ini. Pengguna bisa mendaftar dan masuk dengan email dan kata sandi, atau dengan Google. Gunakan [library atau penyedia] alih-alih kode auth buatan sendiri. Hash kata sandi dengan Argon2id atau bcrypt. Tambahkan reset kata sandi lewat email dengan tautan sekali pakai yang kedaluwarsa dalam satu jam. Simpan sesi di cookie yang aman dan HttpOnly. Lindungi /dashboard dan setiap route /api agar hanya pengguna yang sudah masuk yang bisa memakainya, dan pastikan pengguna hanya bisa melihat proyek mereka sendiri. Tambahkan peran "admin" yang bisa melihat semua pengguna; hanya admin yang bisa mengakses /admin, diperiksa di server.

Lalu uji: daftar, keluar, masuk, reset kata sandi, coba URL privat saat belum masuk, dan coba catatan pengguna lain.

Kesalahan umum dalam login buatan AI

• Perlindungan hanya di halaman. Halaman mengalihkan pengguna yang belum masuk, tetapi API mengembalikan data kepada siapa pun.
• Secret di browser. Client secret OAuth dan kunci admin penyedia auth harus berada di server.
• URL pratinjau dan live tertukar. Redirect URI Google atau tautan reset email mengarah ke pratinjau, sehingga login rusak setelah publikasi.
• Tidak ada verifikasi email. Siapa pun bisa mendaftar sebagai siapa saja@perusahaan.com. Verifikasi email sebelum memberikan apa pun yang terkait dengan alamat itu.
• Hanya menguji jalur yang berhasil. Coba kata sandi salah, tautan kedaluwarsa, dan akun kedua.

Menambahkan login di Mythex

Di Mythex, login untuk pengguna aplikasi Anda adalah sesuatu yang Anda tambahkan ke aplikasi Anda — itu terpisah dari akun Mythex Anda sendiri. Mythex tidak menyediakan produk auth bawaan, jadi Anda membawa library atau penyedia auth beserta kuncinya:

1. Pilih pendekatan — misalnya email dan kata sandi yang disimpan di database Anda sendiri, atau SDK dari penyedia yang di-hosting.
2. Jika Anda menyimpan pengguna sendiri, aplikasi membutuhkan database; minta di chat atau gunakan /database.
3. Simpan kunci penyedia di secret proyek (/secrets atau pengaturan proyek).
4. Gunakan prompt seperti di atas, lalu uji di Preview. Untuk masuk dengan Google, tambahkan redirect URI untuk pratinjau dan alamat yang sudah dipublikasikan.

Lihat Tambahkan login ke aplikasi Anda di dokumentasi. Jika Anda membangun produk berbayar, cara membangun MVP SaaS membahas akun dan penagihan sekaligus.

Pertanyaan