Apa Itu Autentikasi? Login, Sesi, dan OAuth Dijelaskan

Autentikasi adalah cara aplikasi memastikan siapa penggunanya, biasanya dengan memeriksa sesuatu yang diketahui pengguna (password), sesuatu yang dimiliki pengguna (kode yang dikirim ke ponsel atau email mereka), atau identitas dari layanan tepercaya lain (seperti "Sign in with Google"). Setelah pengguna terautentikasi, aplikasi mengingatnya dengan sesi atau token supaya ia tidak perlu login di setiap halaman. Menentukan apa yang boleh dilakukan pengguna yang sudah dikenal itu adalah langkah terpisah yang disebut otorisasi.

Mengapa ini penting saat membangun dengan AI

Menambahkan login adalah salah satu permintaan paling umum kepada AI builder, dan salah satu yang paling mudah keliru secara halus. Halaman login sederhana untuk dibuat. Bagian yang sulit adalah semua yang ada di sekitarnya:

• Apakah password disimpan dengan aman?
• Apakah setiap halaman privat dan setiap endpoint API benar-benar memeriksa siapa yang meminta?
• Bisakah customer yang sudah login melihat data customer lain dengan mengubah angka di URL?
• Apa yang terjadi ketika seseorang lupa password?

Aplikasi bisa tampak sangat aman padahal gagal di semua poin itu. Memahami bagian-bagian yang bergerak membantumu mengajukan pertanyaan yang tepat dan menguji hal yang tepat.

Analogi sehari-hari

Bayangkan saat check-in di hotel.

Di meja resepsionis kamu menunjukkan KTP. Itulah autentikasi: membuktikan siapa kamu. Resepsionis lalu memberimu kartu akses. Kartu itu adalah sesi-mu: selama menginap kamu tidak perlu menunjukkan KTP lagi; kamu cukup menempelkan kartu.

Kartu itu membuka kamarmu, gym, dan lift ke lantai kamu, tetapi tidak membuka kamar tamu lain atau ruang staf. Itulah otorisasi: apa yang boleh diakses identitasmu. Jika kartu hilang, hotel bisa menonaktifkannya di meja resepsionis (mencabut sesi). Saat check-out, kartu berhenti berfungsi (logout, atau kedaluwarsa).

"Sign in with Google" seperti hotel yang menerima surat dari mitra tepercaya yang menyatakan "ini orangnya", alih-alih memeriksa KTP kamu sendiri.

Metode login utama

Cara password seharusnya disimpan

Aplikasi yang aman tidak pernah menyimpan password aslimu. Sebagai gantinya, ia menyimpan hash: hasil dari fungsi satu arah yang mengubah password menjadi string tetap. Saat kamu login, aplikasi meng-hash apa yang kamu ketik lalu membandingkan hasilnya dengan hash yang tersimpan.

Dua detail membuat cara ini aman:

• Salt: nilai acak yang ditambahkan ke setiap password sebelum di-hash, sehingga dua orang dengan password yang sama mendapat hash yang berbeda, dan tabel pencarian yang sudah dihitung sebelumnya menjadi tidak berguna.
• Algoritma lambat yang dibuat khusus untuk password, seperti Argon2, bcrypt, atau scrypt. Hash tujuan umum seperti MD5 atau SHA-256 terlalu cepat jika berdiri sendiri; penyerang bisa mencoba miliaran tebakan.

Hashing tidak sama dengan enkripsi. Data terenkripsi bisa didekripsi dengan kunci; hash password dirancang agar tidak bisa dibalik sama sekali.

Sesi vs token

Setelah login, aplikasi perlu mengenalimu pada setiap permintaan. Ada dua pendekatan umum.

Untuk cookie, tiga pengaturan penting: HttpOnly (JavaScript di halaman tidak bisa membaca cookie), Secure (hanya dikirim lewat HTTPS), dan SameSite (membatasi pengiriman pada permintaan dari situs lain). Menyimpan token di localStorage browser itu umum, tetapi membuatnya terbuka bagi script apa pun yang berjalan di halaman.

OAuth dan "Sign in with Google"

OAuth 2.0 adalah standar untuk otorisasi yang didelegasikan: standar ini memungkinkan aplikasi mendapatkan akses terbatas ke akunmu di layanan lain, misalnya membaca Google Calendar-mu, tanpa pernah melihat password Google kamu. Kamu diarahkan ke Google, menyetujui izin tertentu (disebut scope), dan Google memberi aplikasi token hanya untuk izin tersebut.

OAuth sendiri dirancang untuk memberi akses, bukan untuk menyatakan siapa kamu. OpenID Connect (OIDC) adalah lapisan di atas OAuth 2.0 yang menambahkan identitas, dan inilah yang dipakai "Sign in with Google" atau "Sign in with Apple". Untuk menyiapkannya, kamu mendaftarkan aplikasi ke penyedia dan mendapatkan client ID serta client secret; secret tetap berada di server kamu.

Contoh nyata: login untuk portal klien

Anggaplah kamu membangun portal tempat klien sebuah agensi desain melihat project dan invoice mereka.

• Autentikasi: klien login dengan email dan magic link, sehingga tidak ada password yang perlu dikelola. Staf agensi login dengan akun Google Workspace.
• Peran: setiap pengguna punya peran, yaitu client atau staff.
• Aturan otorisasi:

• Tempat penegakannya: di server, untuk setiap permintaan. Server mencari pengguna yang sedang login, lalu hanya mengembalikan project di mana project.company_id cocok dengan perusahaan pengguna tersebut. Menyembunyikan tombol "Tandai lunas" saja tidak cukup; endpoint-nya sendiri harus menolak.

Istilah penting

Kesalahan dan kesalahpahaman umum

• Memeriksa izin hanya di halaman. Jika browser menyembunyikan tombol tetapi API tidak memeriksa, siapa pun bisa memanggil API secara langsung.
• Mempercayai ID dari URL. /invoices/1042 harus memeriksa bahwa invoice 1042 milik pengguna yang sedang login.
• Membuat kriptografi sendiri. Gunakan library atau penyedia yang sudah dikenal; jangan biarkan AI menciptakan skema hashing sendiri.
• Reset password yang lemah. Tautan reset sebaiknya sekali pakai, cepat kedaluwarsa, dan tidak mengungkapkan apakah sebuah email punya akun.
• Mencampuradukkan login aplikasimu dengan login builder-mu. Pengguna aplikasimu terpisah dari akunmu di alat yang kamu pakai untuk membangun.
• Tidak ada pembatasan laju pada login. Tanpa itu, penyerang bisa terus mencoba password.

Yang bisa kamu minta dari AI builder

• "Tambahkan sign-up dan login menggunakan [library atau penyedia yang sudah dikenal]. Jangan tulis hashing password sendiri."
• "Simpan password dalam bentuk hash dengan bcrypt atau Argon2."
• "Gunakan cookie HttpOnly dan Secure untuk sesi."
• "Tambahkan peran: admin dan member. Daftarkan setiap endpoint dan peran mana yang boleh memanggilnya."
• "Pastikan di server bahwa pengguna hanya bisa membaca dan mengubah data miliknya sendiri. Lalu tunjukkan bagaimana kamu memeriksanya."
• "Tambahkan reset password dengan tautan sekali pakai yang kedaluwarsa dalam satu jam."
• "Batasi laju percobaan login."

Lalu uji sendiri: buat dua akun dan coba akses data salah satu akun saat login sebagai akun lainnya. Panduan kami tentang menambahkan login dan checklist keamanan membahas lebih jauh.

Autentikasi di Mythex

Mythex tidak menyediakan produk autentikasi bawaan untuk pengguna aplikasimu; kamu memilih pendekatannya, yaitu email dan password yang disimpan di database project, atau SDK dari penyedia hosted, lalu meminta agent untuk menambahkannya. Key penyedia disimpan sebagai secret project, bukan di chat. Ini terpisah dari cara kamu login ke Mythex itu sendiri. Resep dokumentasi tentang menambahkan login ke aplikasi memiliki starter prompt yang bisa kamu sesuaikan, dan apa itu API menjelaskan di mana pemeriksaan sisi server tersebut berada.

Pertanyaan