Builder Toolkit · 11 / 11

Asas OAuth

Fahami apa yang "Sign in with Google" sebenarnya serahkan, cara redirect URL berfungsi, dan kenapa kebanyakan setup gagal.

Asas OAuth

Apa ini

OAuth ialah sistem di sebalik "Sign in with Google" dan butang seumpamanya.

Daripada app anda menyimpan password, provider mengesahkan siapa orang itu dan menyerahkan token kepada app anda yang menyatakan begitu.

Satu idea utama

App anda tidak pernah nampak password. Ia terima bukti identiti daripada pihak yang pengguna sudah percaya.

Kenapa penting

Menyimpan password dengan selamat memang susah, dan tersilap ialah masalah serius untuk pengguna sebenar. Menyerahkan tugas itu membuang beban tersebut sepenuhnya.

Ia juga setup yang paling kerap beginner tinggalkan, hampir selalu atas sebab yang sama: satu redirect URL tidak sepadan, menghasilkan error yang tidak menerangkan apa-apa.

Apa nak buat

Ikut alirannya

Copy

User clicks sign in
  → sent to the provider
  → user approves
  → provider redirects back with a code
  → your app exchanges the code for a session

Kegagalan hampir selalu pada anak panah keempat. Provider hanya akan redirect ke alamat yang anda daftarkan lebih awal, tepat seperti yang ditulis.

Daftarkan setiap redirect URL

Anda perlukan satu untuk setiap tempat app anda berjalan:

Environment	Contoh
Local development	`http://localhost:3000/auth/callback`
Production	`https://yourdomain.com/auth/callback`

Kedua-duanya mesti didaftarkan sebelum mana-mana satu berfungsi. Ia dipadankan aksara demi aksara. Slash di hujung, http dan bukan https, atau www yang ada pada satu dan tiada pada satu lagi, semuanya dikira berbeza.

Error mismatch memang sengaja kabur

Provider sengaja kekalkan mesej ini umum, supaya penyerang tidak belajar apa-apa. Bila anda nampak redirect mismatch, banding dua string itu aksara demi aksara, jangan cari dalam teks error.

Setup

Buat OAuth credential dalam developer console provider.
Daftarkan setiap redirect URL, local dan production.
Salin client ID dan client secret.
Letak dalam environment variable anda, ikut Environment Variables.
Hidupkan provider dalam perkhidmatan auth anda, seperti Supabase Auth.
Uji di local dahulu, kemudian pada site yang sudah deploy.

Client secret ialah server-only. Ia tidak pernah dapat prefix public dan tidak pernah muncul dalam code browser.

Buat sekarang

Tulis dua redirect URL anda atas kertas, tepat seperti app anda akan hantar. Kebanyakan kegagalan setup sudah kelihatan pada langkah ini, sebelum anda sentuh console.

Check sendiri

Saya boleh terangkan apa yang app saya terima sebagai ganti password.
Saya sudah daftar redirect URL local dan production.
Client secret saya server-only dan tidak pernah dalam code browser.
Saya sudah uji sign in di local sebelum deploy.
Saya tahu error mismatch bermakna string berbeza, bukan code rosak.

Tahu apa yang anda minta

Provider benarkan anda minta scope: benda khusus yang anda mahu akses. Minta yang minimum. Minta senarai kenalan pengguna untuk jalankan skrin login adalah tidak perlu dan menjadi sebab orang batalkan pendaftaran.

Kalau login jalan di local tetapi tidak live

Redirect URL production hilang, salah eja, atau didaftar dengan protokol berbeza. Semak itu sebelum ubah mana-mana code.

Common mistakes

Daftar redirect URL local sahaja, kemudian dapati login rosak selepas deploy.
Beza protokol atau slash hujung antara URL yang didaftar dengan yang sebenar.
Letak client secret dalam environment variable public.
Minta jauh lebih banyak scope daripada keperluan app.
Tambah login pada project yang belum ada apa-apa di sebaliknya.
Uji dalam browser yang sudah login sahaja, jadi laluan belum-login tidak pernah disemak.

Next step

Anda sudah ada asasnya. Bawa balik ke build anda dalam Build Dalam Workspace Anda.