Apa Itu OAuth? “Sign in with Google” dan Akses Diwakilkan Dijelaskan

OAuth ialah standard terbuka yang membolehkan pengguna memberikan satu aplikasi akses terhad kepada akaunnya pada perkhidmatan lain, tanpa menyerahkan kata laluannya. Apabila anda klik “Connect Google Calendar” dan melihat skrin yang bertanya “Benarkan aplikasi ini melihat acara anda?”, itulah OAuth. Aplikasi menerima token untuk apa yang tepat anda luluskan, yang boleh anda batalkan bila-bila masa. Mekanisme yang sama, dengan lapisan tambahan yang dipanggil OpenID Connect, menggerakkan “Sign in with Google” dan butang serupa.

Mengapa OAuth penting apabila membina dengan AI

OAuth muncul dalam dua situasi biasa apabila anda membina aplikasi:

1. Log masuk sosial. Anda mahu pengguna anda “Sign in with Google” (atau Apple, Microsoft, GitHub) dan bukannya mencipta kata laluan lain. Lihat cara menambah log masuk pada aplikasi anda.
2. Menyambung ke akaun pengguna pada perkhidmatan lain. Aplikasi anda perlu membaca kalendar pengguna, menghantar ke akaun media sosial mereka, mengambil fail daripada pemacu awan mereka atau menyegerakkan data perakaunan mereka.

Dalam kedua-dua kes, pembina AI anda boleh menulis kod, tetapi ada langkah tertentu yang hanya anda boleh lakukan: mencipta aplikasi pembangun dengan pembekal, mendapatkan client ID dan client secret, mendaftarkan URL panggil balik dan, untuk sesetengah kebenaran, melepasi semakan pembekal. Mengetahui cara OAuth berfungsi menjadikan langkah-langkah itu — dan ralat yang dihasilkannya — kurang misteri. Untuk gambaran yang lebih luas tentang log masuk, lihat apa itu pengesahan.

Analogi harian

Fikirkan kad kunci hotel. Semasa daftar masuk, kaunter depan mengesahkan siapa anda, kemudian memberi anda kad yang membuka bilik anda dan gim — bukan bilik lain, bukan kawasan kakitangan — dan berhenti berfungsi apabila anda daftar keluar. Kad itu tidak mengandungi pasport anda. Jika anda hilang, kaunter membatalkannya dan mengeluarkan yang baharu.

• Kaunter depan ialah pelayan kebenaran (halaman log masuk Google).
• Pemeriksaan ID anda ialah anda log masuk ke Google.
• Kad kunci ialah token akses.
• “Bilik dan gim sahaja” ialah skop yang anda luluskan.
• Daftar keluar ialah token tamat tempoh, atau anda membatalkan akses.

Aplikasi yang anda gunakan tidak pernah melihat kata laluan Google anda, hanya kad kunci itu.

Cara OAuth berfungsi, langkah demi langkah

Aliran yang paling lazim untuk aplikasi web ialah aliran kod kebenaran (authorization code flow). Inilah yang berlaku apabila pengguna menyambungkan Google Calendar mereka ke aplikasi penjadualan:

1. Klik. Pengguna klik “Connect Google Calendar.”
2. Ubah hala ke pembekal. Aplikasi menghantar pelayar ke Google dengan client ID-nya, skop yang diinginkannya (baca acara kalendar) dan URI ubah hala tempat Google perlu menghantar pengguna kembali.
3. Log masuk dan persetujuan. Pengguna log masuk ke Google (jika belum) dan melihat skrin persetujuan yang menyenaraikan apa yang diminta aplikasi. Mereka klik Benarkan.
4. Kembali dengan kod. Google mengubah hala pelayar ke URI ubah hala aplikasi dengan kod kebenaran yang pendek dan sekali guna.
5. Tukar di pelayan. Pelayan aplikasi menghantar kod itu, bersama rahsia pelanggannya, terus kepada Google dan menerima token akses (dan selalunya token segar).
6. Gunakan API. Pelayan memanggil API Google Calendar dengan token akses dan mendapat acara pengguna.

Panggil balik dalam langkah 4 kelihatan seperti ini:

https://yourapp.com/auth/google/callback?code=4/0Adeu5B...&state=x7Kq9

Dan respons token dalam langkah 5 ialah JSON seperti:

{
  "access_token": "ya29.a0Af...",
  "expires_in": 3599,
  "refresh_token": "1//0gL...",
  "scope": "https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

Poin reka bentuk yang penting: pertukaran token berlaku antara pelayan dengan pelayan, jadi rahsia pelanggan dan token tidak perlu melalui pelayar.

OAuth vs OpenID Connect vs log masuk anda sendiri

Banyak aplikasi menggabungkannya: log masuk e-mel-dan-kata-laluan, ditambah “Sign in with Google” melalui OIDC, ditambah sambungan OAuth berasingan ke perkhidmatan lain.

Istilah utama

Salah faham lazim

• “OAuth ialah sistem log masuk.” OAuth biasa memberikan akses; OpenID Connect mengendalikan identiti. Menggunakan token akses semata-mata sebagai bukti siapa seseorang pernah menyebabkan pepijat keselamatan yang sebenar.
• “Aplikasi itu mendapat kata laluan saya.” Ia tidak pernah berbuat begitu. Itulah tujuannya.
• “Meminta lebih banyak skop itu tidak memudaratkan.” Pengguna lebih berhati-hati dengan permintaan yang luas, dan pembekal seperti Google mungkin memerlukan semakan aplikasi untuk skop yang sensitif atau terhad. Minta hanya apa yang anda perlukan.
• “Rahsia pelanggan boleh diletakkan di bahagian hadapan.” Apa sahaja dalam kod pelayar adalah awam. Simpan dalam rahsia pelayan.
• “Ia berfungsi dalam ujian, jadi ia akan berfungsi dalam pengeluaran.” Pembekal sering mengehadkan aplikasi yang belum disahkan — contohnya, kepada pengguna ujian yang disenaraikan — dan URI ubah hala untuk domain langsung anda mesti didaftarkan secara berasingan.
• “Token berlanjutan selamanya.” Token akses tamat tempoh dengan cepat, dan pengguna boleh membatalkan akses. Aplikasi anda perlu mengendalikan kedua-duanya dengan baik.

Apa yang perlu diminta kepada pembina AI anda

• “Tambahkan ‘Sign in with Google’ menggunakan OpenID Connect dengan pustaka auth yang diselenggara dengan baik — jangan tulis sendiri aliran OAuth.”
• “Gunakan aliran kod kebenaran dengan PKCE dan semak parameter state.”
• “Baca client ID dan client secret daripada pembolehubah persekitaran di pelayan.”
• “Minta hanya skop yang kita perlukan: akses kalendar baca sahaja.”
• “Beritahu saya setiap URL ubah hala yang perlu didaftarkan dalam konsol pembekal, untuk pratonton, URL yang diterbitkan dan domain tersuai saya.”
• “Simpan token segar yang disulitkan dalam pangkalan data, dan kendalikan token yang tamat tempoh atau dibatalkan dengan meminta pengguna menyambung semula.”
• “Benarkan pengguna memutuskan sambungan integrasi daripada halaman tetapan mereka.”

OAuth dan Mythex

Mythex tidak mempunyai log masuk pengguna terbina dalam untuk aplikasi yang anda bina; dokumentasinya menerangkan pendekatan bawa-sendiri — anda memilih pustaka auth atau pembekal yang dihoskan, menyimpan kuncinya sebagai rahsia projek, dan ejen menulis kodnya. Resipi tambah pengesahan mempunyai gesaan permulaan untuk ini. Anda juga akan berjumpa OAuth dalam Mythex itu sendiri: anda boleh mendaftar dengan Google, menyambungkan GitHub untuk penyegerakan repositori menggunakan OAuth GitHub, dan pembantu AI yang menyambung ke Mythex melalui MCP melalui halaman persetujuan OAuth. Untuk maklumat lanjut, lihat apa itu pengesahan dan apa itu pengesahan dua faktor.

Soalan lazim