Apa Itu Authentication? Log Masuk, Sesi dan OAuth Diterangkan

Authentication ialah cara aplikasi mengesahkan siapa pengguna — biasanya dengan menyemak sesuatu yang mereka tahu (kata laluan), sesuatu yang mereka ada (kod yang dihantar ke telefon atau e-mel mereka) atau identiti daripada perkhidmatan dipercayai lain (seperti “Log masuk dengan Google”). Selepas pengguna disahkan, aplikasi mengingati mereka dengan sesi atau token supaya mereka tidak perlu log masuk pada setiap halaman. Memutuskan apa yang pengguna yang diketahui itu dibenarkan lakukan ialah langkah berasingan yang dipanggil authorization.

Mengapa ia penting apabila anda membina dengan AI

Menambah log masuk ialah salah satu permintaan paling biasa kepada pembina AI, dan salah satu yang paling mudah tersilap. Halaman log masuk mudah dijana. Bahagian yang sukar ialah semua yang berada di sekelilingnya:

• Adakah kata laluan disimpan dengan selamat?
• Adakah setiap halaman peribadi dan setiap titik akhir API benar-benar menyemak siapa yang meminta?
• Bolehkah pelanggan yang telah log masuk melihat data pelanggan lain dengan menukar nombor dalam URL?
• Apa yang berlaku apabila seseorang terlupa kata laluan?

Sebuah aplikasi boleh kelihatan sangat selamat sambil gagal dalam semua perkara itu. Memahami bahagian-bahagian yang bergerak membolehkan anda bertanya soalan yang betul dan menguji perkara yang betul.

Analogi harian

Bayangkan anda mendaftar masuk ke hotel.

Di kaunter depan, anda menunjukkan kad pengenalan. Itulah authentication: membuktikan siapa anda. Kemudian penyambut tetamu memberi anda kad kunci. Kad itu ialah sesi anda: sepanjang penginapan, anda tidak perlu menunjukkan kad pengenalan lagi; anda hanya mengimbas kad itu.

Kad itu membuka bilik anda, gim dan lif ke tingkat anda — tetapi bukan bilik tetamu lain atau pejabat kakitangan. Itulah authorization: apa yang identiti anda dibenarkan akses. Jika anda kehilangan kad, hotel boleh menyahaktifkannya di kaunter (membatalkan sesi). Apabila anda daftar keluar, ia berhenti berfungsi (log keluar, atau tamat tempoh).

“Log masuk dengan Google” seperti hotel yang menerima surat daripada rakan kongsi yang dipercayai yang berkata “ini orangnya”, dan bukannya memeriksa kad pengenalan anda sendiri.

Kaedah log masuk utama

Cara kata laluan patut disimpan

Aplikasi yang selamat tidak pernah menyimpan kata laluan sebenar anda. Sebaliknya, ia menyimpan hash: output fungsi sehala yang menukar kata laluan kepada rentetan tetap. Apabila anda log masuk, aplikasi mencincang apa yang anda taip dan membandingkan hasilnya dengan hash yang disimpan.

Dua butiran menjadikan ini selamat:

• Salt (garam) — nilai rawak yang ditambah pada setiap kata laluan sebelum dicincang, supaya dua orang dengan kata laluan sama mendapat hash yang berbeza, dan jadual carian yang telah dikira menjadi tidak berguna.
• Algoritma perlahan yang direka untuk kata laluan — seperti Argon2, bcrypt atau scrypt. Hash tujuan umum seperti MD5 atau SHA-256 terlalu pantas dengan sendirinya; penyerang boleh mencuba berbilion tekaan.

Hashing tidak sama dengan penyulitan. Data yang disulitkan boleh dinyahsulitkan dengan kunci; hash kata laluan direka supaya tidak boleh dibalikkan sama sekali.

Sesi vs token

Selepas log masuk, aplikasi perlu mengenali anda pada setiap permintaan. Terdapat dua pendekatan biasa.

Untuk kuki, tiga tetapan penting: HttpOnly (JavaScript pada halaman tidak boleh membaca kuki), Secure (dihantar hanya melalui HTTPS) dan SameSite (menghadkan penghantarannya pada permintaan dari laman lain). Menyimpan token dalam localStorage pelayar adalah biasa, tetapi ia mendedahkan token kepada mana-mana skrip yang berjalan pada halaman itu.

OAuth dan “Log masuk dengan Google”

OAuth 2.0 ialah standard untuk delegated authorization: ia membolehkan aplikasi mendapat akses terhad kepada akaun anda di perkhidmatan lain — contohnya membaca Kalendar Google anda — tanpa pernah melihat kata laluan Google anda. Anda dihantar ke Google, anda meluluskan kebenaran tertentu (dipanggil scopes), dan Google memberi aplikasi itu token untuk kebenaran tersebut sahaja.

OAuth sahaja direka untuk memberi akses, bukan untuk memberitahu siapa anda. OpenID Connect (OIDC) ialah lapisan di atas OAuth 2.0 yang menambah identiti, dan itulah yang digunakan oleh “Log masuk dengan Google” atau “Log masuk dengan Apple”. Untuk menyediakannya, anda mendaftarkan aplikasi dengan pembekal dan mendapat client ID serta client secret; secret itu kekal di pelayan anda.

Contoh kerja: log masuk untuk portal pelanggan

Katakan anda sedang membina portal tempat pelanggan sebuah agensi reka bentuk melihat projek dan invois mereka.

• Authentication: pelanggan log masuk dengan e-mel dan pautan ajaib, jadi tiada kata laluan untuk diurus. Kakitangan agensi log masuk dengan akaun Google Workspace.
• Peranan: setiap pengguna mempunyai peranan — client atau staff.
• Peraturan authorization:

• Di mana ia dikuatkuasakan: di pelayan, untuk setiap permintaan. Pelayan mencari pengguna yang log masuk, kemudian hanya memulangkan projek yang project.company_id-nya sepadan dengan syarikat pengguna. Menyembunyikan butang “Tandakan dibayar” tidak mencukupi — titik akhir itu sendiri mesti menolak.

Istilah biasa dijelaskan

Kesilapan dan salah faham yang biasa

• Menyemak kebenaran hanya di halaman. Jika pelayar menyembunyikan butang tetapi API tidak menyemak, sesiapa sahaja boleh memanggil API secara langsung.
• Mempercayai ID daripada URL. /invoices/1042 mesti menyemak bahawa invois 1042 tergolong kepada pengguna yang log masuk.
• Mencipta kriptografi sendiri. Gunakan pustaka atau pembekal yang terkenal; jangan biarkan AI mereka-reka skema cincang sendiri.
• Tetapan semula kata laluan yang lemah. Pautan tetapan semula patut sekali guna, tamat tempoh dengan cepat dan tidak mendedahkan sama ada e-mel mempunyai akaun.
• Mengelirukan log masuk anda dengan log masuk pembina anda. Pengguna aplikasi anda berasingan daripada akaun anda di alat yang anda gunakan untuk membina.
• Tiada had kadar (rate limiting) pada log masuk. Tanpanya, penyerang boleh mencuba kata laluan tanpa henti.

Apa nak minta daripada pembina AI anda

• “Tambah pendaftaran dan log masuk menggunakan [pustaka atau pembekal yang terkenal]. Jangan tulis cincang kata laluan sendiri.”
• “Simpan kata laluan yang dicincang dengan bcrypt atau Argon2.”
• “Gunakan kuki sesi HttpOnly dan Secure.”
• “Tambah peranan: admin dan member. Senaraikan setiap titik akhir dan peranan mana yang boleh memanggilnya.”
• “Kuatkuasakan di pelayan bahawa pengguna hanya boleh membaca dan mengedit rekod mereka sendiri. Kemudian tunjukkan cara anda menyemaknya.”
• “Tambah tetapan semula kata laluan dengan pautan sekali guna yang tamat tempoh dalam satu jam.”
• “Hadkan kadar percubaan log masuk.”

Kemudian uji sendiri: cipta dua akaun dan cuba capai data satu akaun semasa log masuk sebagai akaun yang lain. Panduan kami cara menambah log masuk dan senarai semak keselamatan memberi butiran lanjut.

Authentication dalam Mythex

Mythex tidak menyediakan produk auth terbina dalam untuk pengguna aplikasi anda; anda memilih pendekatan — e-mel dan kata laluan yang disimpan dalam pangkalan data projek anda, atau SDK pembekal yang dihoskan — dan meminta ejen menambahkannya. Kunci pembekal diletakkan dalam rahsia projek, bukan dalam sembang. Ini berasingan daripada cara anda log masuk ke Mythex itu sendiri. Resipi dokumen mengenai menambah log masuk pada aplikasi anda mempunyai arahan permulaan yang boleh anda sesuaikan, dan apa itu API menerangkan di mana semakan pelayan tersebut berada.

Soalan lazim