Setiap kali anda klik 'Log masuk dengan Google' or 'Berhubung dengan Microsoft', Anda menggunakan OAuth. Tetapi apakah itu OAuth? OAuth ialah rangka kerja kebenaran standard terbuka yang membolehkan anda memberikan kebenaran kepada satu aplikasi untuk mengakses maklumat anda pada perkhidmatan lain, tanpa perlu berkongsi kata laluan anda. Itulah OAuth yang berfungsi. Ia mengesahkan siapa anda tanpa berkongsi kata laluan anda, hanya memberikan maklumat terhad kepada aplikasi, cukup untuk mengesahkan bahawa anda sah. Ia merupakan jabat tangan senyap yang memperkasakan log masuk moden yang selamat.
Hari ini, di mana hampir setiap pekerja mengakses aplikasi awan daripada peranti peribadi atau luar tapak, log masuk tradisional tidak lagi berfungsi. Pengesahan OAuth menyelesaikan masalah ini dengan membenarkan pengguna memberikan akses terhad kepada aplikasi tanpa berkongsi kata laluan. Daripada kelayakan, aplikasi mendapat token berskop. Ini bermakna kawalan yang lebih baik, kurang risiko dan kurang titik kegagalan.
Jadi, apakah yang dilakukan oleh pengesahan OAuth secara berbeza? Ia memisahkan identiti daripada akses dan memberikan pasukan IT keterlihatan dan kawalan tanpa menambah gesekan kepada pengguna.
Panduan ini menghuraikan maksud OAuth, cara ia berfungsi dan cara menggunakannya untuk menjamin akses merentasi organisasi anda, serta satu atau dua contoh OAuth yang praktikal untuk menghidupkannya.
Apakah itu OAuth?
Pada terasnya, OAuth ialah satu protokol. Ia membenarkan aplikasi meminta akses terhad kepada data pengguna yang dihoskan oleh perkhidmatan lain (seperti Google, Microsoft atau GitHub). Pengguna meluluskan atau menolak permintaan ini.
Secara ringkasnya, pengesahan OAuth ialah cara yang selamat untuk pengguna membenarkan aplikasi mengakses data mereka tanpa mendedahkan kata laluan mereka. Pengguna meluluskan akses melalui token dan bukannya menyerahkan kelayakan log masuk penuh. Token tersebut bertindak seperti slip kebenaran, terhad kepada tindakan dan data tertentu.
Inilah idea mudah di sebaliknya: Anda memberikan akses, bukan kelayakan anda.
Bagaimanakah OAuth Berfungsi?
OAuth dalam praktiknya? Pengguna boleh membiarkan aplikasi kecergasan membaca langkah mereka daripada akaun Apple Health mereka, tanpa membiarkan aplikasi tersebut mengubah apa-apa atau mengakses data yang tidak berkaitan.
Ideanya kedengaran mudah: benarkan aplikasi mengakses data tanpa perlu memberikan kata laluan. Tetapi bagaimana pengesahan OAuth berfungsi secara tersembunyi?
Berikut ialah contoh OAuth langkah demi langkah menggunakan kes biasa, log masuk ke aplikasi pihak ketiga dengan Google:
1. Aplikasi ini meminta aksesPengguna membuka aplikasi dan mengklik “Log masuk dengan Google.” Aplikasi tersebut mengalihkan pengguna ke Google dengan permintaan akses kepada data tertentu (seperti e-mel atau kenalan).
2. Pengguna memberikan kebenaranGoogle menunjukkan kepada pengguna apa yang diminta oleh aplikasi. Pengguna bersetuju. Tiada kata laluan dikongsi dengan aplikasi.
3. Aplikasi ini mendapat tokenSetelah diluluskan, Google akan menghantar token selamat kepada aplikasi. Token ini bertindak sebagai bukti bahawa aplikasi mempunyai kebenaran untuk mengakses data.
4. Token digunakan untuk aksesAplikasi ini menggunakan token untuk mengambil data pengguna daripada Google. Token ini mempunyai skop, had masa dan boleh dibatalkan.
Ini ialah pengesahan OAuth dalam tindakan, mudah untuk pengguna, berkuasa untuk keselamatan.
Mengapa OAuth penting untuk Keselamatan dan Kawalan Akses
Fikirkanlah, kata laluan tidak berubah. Sebaik sahaja ia keluar, penyerang terus masuk.
Tetapi OAuth? Ia bukan sekadar kaedah log masuk yang lain.
Ia merupakan cara yang lebih bijak untuk mengendalikan kepercayaan, akses dan kawalan semasa sesuatu berlaku, dalam masa nyata. Ini bukan sekadar untuk memudahkan hidup; ia merupakan peningkatan sepenuhnya kepada aspek keselamatan anda.
Inilah sebabnya pengesahan OAuth penting:
1. Penguatkuasaan masa nyata
Sistem akses tradisional tidak dapat menangani ancaman yang bergerak pantas. OAuth membolehkan anda membatalkan akses serta-merta. Jika token kelihatan mencurigakan atau peranan pengguna berubah, anda akan menutup pintu dalam masa nyata, tiada tetapan semula kata laluan, tiada kelewatan.
2. Konfigurasi jauh
Dengan OAuth, kebenaran tidak dikodkan secara tetap. Ia dikonfigurasikan dan dihantar oleh pelayan kebenaran, yang bermaksud anda boleh melaraskan skop, menetapkan tamat tempoh dan mengemas kini dasar secara berpusat. IT tidak perlu menyentuh titik akhir untuk menukar akses.
3. Penapisan peka lokasi
OAuth berfungsi dengan lancar dengan alatan keselamatan berasaskan lokasi. Jika permintaan akses datang daripada kawasan berisiko tinggi atau IP yang tidak diketahui, anda boleh menolak atau mengehadkan pengeluaran token. Ia merupakan lapisan kawalan kontekstual tambahan yang terbina dalam aliran.
4. Skalabiliti
Apabila persekitaran anda berkembang, model akses statik akan mengalami gangguan. OAuth diskalakan dengan mudah merentasi aplikasi, peranti dan pengguna. Satu identiti boleh membenarkan banyak perkhidmatan dan dasar digunakan secara konsisten di seluruh platform, tanpa menambah pergeseran untuk IT atau pengguna akhir.
Faedah Utama OAuth
OAuth lebih daripada sekadar kaedah log masuk. Ia merupakan cara yang fleksibel dan selamat untuk mengurus akses merentasi pengguna, aplikasi dan sistem. Inilah sebabnya ia menjadi standard untuk kebenaran yang selamat dan fleksibel dalam persekitaran IT hibrid masa kini.
- Kawalan akses berbutir: Tentukan dengan tepat apa yang boleh diakses oleh pengguna atau aplikasi. Jadi, aplikasi boleh membaca kalendar anda, tetapi bukan e-mel anda.
- Lebih sedikit kata laluan, UX yang lebih baik: Pengguna memberikan kebenaran sekali sahaja. OAuth mengendalikan akses selamat, jadi tiada log masuk berulang atau kelayakan kongsi.
- Dibina untuk sifar kepercayaan: Menyokong semakan token masa nyata, akses berasaskan konteks dan pembatalan.
- Penyingkiran mudah: Batalkan akses serta-merta tanpa menyentuh rekod identiti. Paling sesuai untuk mengurus vendor, kontraktor dan aplikasi sementara.
- Bekerja dengan penyedia identiti: Berintegrasi dengan kemas dengan Entra ID, Google, Okta dan lain-lain; menjadikannya mudah untuk dilapiskan ke dalam tindanan sedia ada anda.
Kes Penggunaan OAuth Biasa
1. Akses BYOD untuk pasukan jarak jauhSeorang pekerja jarak jauh mengakses aplikasi syarikat daripada peranti peribadi.
Aliran OAuth:
- Log masuk menggunakan penyedia identiti syarikat (cth., Google Workspace atau Entra ID)
- Meluluskan akses khusus aplikasi kepada e-mel dan kalendar
- Token dikeluarkan dengan skop yang ditetapkan (tiada kata laluan disimpan)
Digunakan untuk: Akses selamat dan berskop kepada alatan kerja pada peranti BYOD.
2. Integrasi SaaS pihak ketigaPasukan pemasaran memautkan alat projek kepada CRM mereka.
Aliran OAuth:
- Permintaan OAuth dihantar ke CRM (cth., Salesforce)
- Pengguna memberikan akses baca sahaja kepada data bakal pelanggan
- Token dikeluarkan; aplikasi tidak pernah melihat kelayakan
Digunakan untuk: Memberikan akses terhad kepada aplikasi pihak ketiga tanpa risiko perkongsian kata laluan.
3. Kawalan akses yang peka konteks: Pengguna log masuk daripada rangkaian terhad pada peranti yang tidak diurus.
Tingkah laku OAuth:
- Permintaan akses dinilai dalam masa nyata
- Peranti gagal mematuhi peraturan; akses disekat
- Tindakan direkodkan untuk audit
Digunakan untuk: Menguatkuasakan dasar Sifar Kepercayaan dan kawalan pematuhan.
4. Log masuk vendor atau kontraktorVendor luaran memerlukan akses kepada alatan dalaman buat sementara waktu.
Proses OAuth:
- Token berskop dikeluarkan dengan akses terhad masa
- Tiada perubahan dibuat pada direktori teras
- Akses boleh dibatalkan serta-merta
Digunakan untuk: Akses sementara yang selamat tanpa perlu mengaktifkan sistem dalaman.
OAuth 1.0 vs OAuth 2.0: Apa yang Berubah, dan mengapa ia Penting
Apabila orang ramai bercakap tentang pengesahan OAuth hari ini, mereka hampir selalu bermaksud OAuth 2.0. Tetapi protokol itu tidak bermula di situ, dan memahami apa yang berubah daripada OAuth 1.0 membantu menjelaskan mengapa OAuth 2.0 menjadi pilihan utama untuk akses yang selamat dan boleh diskala dalam aplikasi moden.
Let's break it down.
OAuth 1.0: selamat tetapi tegar
OAuth 1.0, yang diperkenalkan pada tahun 2007, direka bentuk untuk membolehkan aplikasi mengakses data pengguna pada perkhidmatan lain tanpa perlu menyimpan nama pengguna atau kata laluan. Idea terasnya, iaitu mewakilkan akses melalui token, masih mentakrifkan maksud OAuth hari ini.
Tetapi spesifikasi asal mempunyai beberapa ciri utama:
- Setiap permintaan perlu ditandatangani secara kriptografi. Ini menambah overhed dan kerumitan, terutamanya untuk aplikasi mudah alih atau berasaskan pelayar.
- Aliran itu tersusun rapi. Pelaksanaan OAuth 1.0 diperlukan selepas jabat tangan berbilang langkah yang tegar yang sukar untuk disesuaikan dengan platform yang berbeza.
- Tiada sokongan terbina dalam untuk keperluan pengalaman pengguna moden. Tiada cara bersih untuk menyokong perkara seperti token mudah alih, akses jangka pendek atau pihak ketiga pembekal identiti.
Siapakah yang masih menggunakan OAuth 1.0? Kebanyakannya sistem legasi yang belum beralih. Jika anda membina sesuatu yang baharu, ia jarang sekali relevan.
OAuth 2.0 menjadikan akses selamat lebih mudah, lebih pintar dan lebih berskala
OAuth 2.0 telah dikeluarkan pada tahun 2012 sebagai penulisan semula lengkap, bukan semakan semula, spesifikasi asal. Ia menangani banyak cabaran yang diperkenalkan oleh OAuth 1.0 dengan memberi tumpuan kepada:
- Perlaksanaan yang dipermudahkanTiada lagi tandatangan kriptografi. OAuth 2.0 bergantung pada HTTPS untuk keselamatan pengangkutan dan menggunakan token pembawa untuk akses.
- Aliran kebenaran fleksibelOAuth 2.0 memperkenalkan pelbagai "jenis geran" untuk menyokong pelbagai kes penggunaan:
- Kod Pengesahan (untuk aplikasi sisi pelayan)
- Tersirat (untuk aplikasi berasaskan pelayar)
- Kelayakan Pelanggan (untuk mesin-ke-mesin)
- Kata Laluan Pemilik Sumber (kini tidak lagi digunakan)
- Seni bina berasaskan token: OAuth 2.0 menggunakan token akses jangka pendek dan token penyegaran untuk meningkatkan keselamatan dan menyokong sesi jangka panjang tanpa log masuk berulang.
- KeluasanOAuth 2.0 mudah disepadukan dengan penyedia identiti, aplikasi mudah alih dan perkhidmatan awan. Ia juga meletakkan asas untuk Sambungan OpenID (OIDC), yang menambah pengesahan di atas kebenaran.
OAuth lawan SAML lawan OIDC lawan FIDO2
Moden pengurusan identiti dan akses Bukan tentang memilih satu protokol; ia tentang menggunakan alat yang betul untuk tugas yang betul. Beginilah perbandingan pengesahan OAuth dengan SAML, OIDC dan FIDO2, dan apa yang ditawarkan (atau tidak ditawarkan) oleh setiap protokol dalam persekitaran IT dunia sebenar.
Untuk perbandingan tertumpu antara peranan mereka yang berbeza, terokai SAML lwn. OAuth panduan.
OAuth vs. SAML: Akses Diwakilkan vs. Identiti Berpusat
SAML (Security Assertion Markup Language) ialah protokol berasaskan XML yang membolehkan pengguna log masuk sekali sahaja melalui SSO Web dan mengakses pelbagai aplikasi web. SAML telah diguna pakai secara meluas pada awal tahun 2000-an oleh perusahaan yang menjalankan sistem IT tradisional.
Sebaliknya, OAuth ialah rangka kerja berasaskan token yang membolehkan aplikasi mengakses data pengguna terhad daripada perkhidmatan lain, tanpa mendedahkan kata laluan.
| Ciri | OAuth | SAML |
|---|---|---|
| Tujuan | kebenaran | Pengesahan + SSO |
| Format Data | JSON (ringan) | XML (berat, bertele-tele) |
| Jenis Token | Token Akses/Segarkan Semula | Pernyataan SAML |
| Pengalaman Pembangun | Mudah, berasaskan REST | Kompleks, berasaskan SOAP |
| Padanan Pelaksanaan | Natif awan, mesra mudah alih | Aplikasi web, portal perusahaan |
| scalability | Tinggi | Terhad dalam persekitaran mudah alih/API-dahulukan |
Insight: SAML sesuai dengan portal legasi. OAuth memperkasakan aplikasi moden. Ia memberikan akses berasaskan token yang selamat, dibina untuk mudah alih, API dan perkhidmatan seperti Google Workspace atau Microsoft Graph.
OAuth lwn. OpenID Connect (OIDC): Akses lwn. Identiti
OAuth 2.0 hanyalah protokol kebenaran. Ia tidak mengesahkan identiti pengguna—ia hanya membenarkan aplikasi mengakses data bagi pihak pengguna. OIDC (OpenID Connect) ialah lapisan yang dibina di atas OAuth 2.0 yang menambah pengesahan, jadi aplikasi bukan sahaja mendapat kebenaran untuk bertindak, tetapi juga mengetahui siapa pengguna tersebut.
| Ciri | OAuth 2.0 | OIDC |
|---|---|---|
| Tujuan | Kebenaran sahaja | Pengesahan + Kebenaran |
| Maklumat Identiti | Tidak termasuk | Token ID dengan tuntutan pengguna |
| Sokongan Log Masuk | Tidak terbina dalam | Pengesahan terbina dalam |
| Tokens | Akses & Segarkan Semula | Akses, Segarkan Semula, Token ID |
| Solusi | Kawalan akses, API | Log masuk, SSO, identiti bersekutu |
Insight: Anggap OIDC sebagai OAuth 2.0 + identiti. Anda menggunakan OAuth apabila anda mahu aplikasi mengakses sumber pengguna. Anda menggunakan OIDC apabila aplikasi juga perlu mengetahui siapa pengguna tersebut; satu keperluan biasa dalam SSO aliran kerja.
OAuth vs. FIDO2: Akses Token vs. Log Masuk Tanpa Kata Laluan
FIDO2 adalah kategori yang sama sekali berbeza. Ia memberi tumpuan kepada pengesahan tanpa kata laluan, menggunakan kriptografi kunci awam-persendirian dan keselamatan yang disokong perkakasan (seperti biometrik atau kunci keselamatan). Ia bukan pengganti untuk OAuth, ia adalah pelengkap.
| Ciri | OAuth | FIDO2 |
|---|---|---|
| Kluster | kebenaran | Pengesahan |
| Model Keselamatan | berasaskan token | Kriptografi kunci awam |
| Pengalaman Pengguna | Aplikasi memberikan akses kepada data pengguna | Pengguna mengesahkan identiti melalui peranti |
| Ideal Untuk | Kawalan akses, kebenaran aplikasi | Log masuk tanpa kata laluan, rintangan pancingan data |
| Bekerja dengan | OAuth, OIDC, SAML | Boleh disepadukan dengan OAuth/OIDC untuk aliran akses |
Insight: FIDO2 membantu anda masuk dengan selamat. OAuth membantu mengawal apa yang boleh anda lakukan sebaik sahaja anda masuk. Gabungkan kedua-duanya untuk aliran hujung ke hujung yang lebih kukuh: FIDO2 untuk pengesahan, OAuth untuk akses berskop dan boleh batal.
Bila hendak menggunakan setiap protokol
- OAuth mendayakan kawalan akses berasaskan token yang selamat untuk aplikasi dan API, tetapi tidak mengesahkan identiti.
- OIDC menambah identiti di atas OAuth, gunakannya apabila aplikasi anda memerlukan log masuk dan akses.
- SAML berkesan untuk persekitaran SSO yang lebih lama, tetapi kurang sesuai untuk aliran kerja API-first dan mudah alih.
- FIDO2 menggantikan kata laluan, bukan kebenaran. Pasangkannya dengan OAuth atau OIDC untuk keselamatan menyeluruh yang kukuh.
| Solusi | Sesuai Terbaik |
|---|---|
| Memberikan akses kepada data pengguna kepada aplikasi | OAuth 2.0 |
| Melog masuk pengguna dengan selamat dengan maklumat identiti | OIDC |
| SSO perusahaan legasi (berasaskan pelayar) | SAML |
| Log masuk tanpa kata laluan dengan pengikatan peranti yang kuat | FIDO2 |
Memilih protokol yang betul untuk tujuan yang betul selalunya bermaksud menggunakan OAuth bersama-sama dengan protokol lain untuk membina sistem akses yang selamat, boleh diskala dan mesra pengguna.
Salah Tanggapan Biasa tentang Pengesahan OAuth
- OAuth adalah untuk log masuk.
Realiti: OAuth mengendalikan kebenaran, bukan pengesahan. Ia membolehkan aplikasi mengakses data, bukan mengesahkan siapa pengguna. - OAuth dan SSO adalah sama.
Realiti: SSO mengesahkan identiti; OAuth memberikan akses. Mereka sering bekerjasama, tetapi mempunyai tujuan yang berbeza. - OAuth menggantikan MFA.
Realiti: OAuth tidak mengesahkan pengguna atau menambah lapisan keselamatan tambahan. Ia boleh menyokong MFA, tetapi tidak menyediakannya. - OAuth bertindak sama merentasi platform.
Realiti: Setiap penyedia melaksanakannya sedikit berbeza. Skop, aliran dan pengendalian token berbeza antara sistem. - OAuth selamat secara lalai.
Realiti: Konfigurasi yang salah menjadikannya berisiko. Token yang lemah atau skop yang luas boleh mendedahkan data jika tidak disediakan dengan betul.
Menyatukan semuanya: OAuth, konteks dan kawalan dengan Scalefusion OneIdP
OAuth menetapkan asas untuk pengesahan berasaskan piawaian moden. Tetapi ia tidak menentukan sama ada peranti selamat, rangkaian dipercayai atau tingkah laku pengguna sejajar dengan dasar. Scalefusion OneIdP menambah konteks tersebut pada lapisan dalam postur keselamatan anda.
OAuth mengurus akses. Dasar sifar kepercayaan menentukan sama ada akses harus berlaku.
Dengan menilai setiap permintaan token terhadap isyarat konteks langsung seperti:
- Kesihatan peranti dan pematuhan MDM
- Reputasi IP dan geolokasi
- Corak tingkah laku berasaskan peranan
Pendekatan yang peka konteks ini membolehkan OneIdP untuk membenarkan, menyekat atau membatalkan akses, walaupun selepas pengesahan berjaya.
Dengan mengikat token OAuth kepada persekitaran yang disahkan dan mematuhi dasar, OneIdP menguatkuasakan akses bersyarat tanpa menambah geseran. Ia memudahkan konfigurasi yang kompleks dan menghapuskan pergantungan pada kaedah pengesahan yang ketinggalan zaman.
Jika persediaan OAuth semasa anda berhenti semasa log masuk, ia bukanlah Sifar Kepercayaan. OneIdP menutup jurang tersebut dengan ketepatan, skala dan keselamatan terbina dalam.
Langkah Seterusnya
Soalan Lazim
1. Bilakah perlu menggunakan OAuth?
Gunakan OAuth apabila anda memerlukan akses yang diwakilkan dengan selamat kepada sumber pengguna tanpa berkongsi kata laluan. Ia sesuai untuk membenarkan aplikasi pihak ketiga, klien mudah alih atau web dan API untuk mengakses data bagi pihak pengguna. Pengesahan OAuth memastikan kawalan kebenaran yang terperinci, meminimumkan pendedahan kelayakan dan menyokong aliran kerja moden seperti daftar masuk tunggal dan akses BYOD.
2. Apakah OAuth dalam API rest?
OAuth dalam REST API ialah protokol yang memberikan akses terhad dan selamat kepada sumber API melalui token dan bukannya kata laluan. Pengesahan OAuth membolehkan REST API mengesahkan kebenaran klien sebelum membenarkan akses data. Ini bermakna aplikasi boleh berinteraksi dengan API bagi pihak pengguna dengan selamat, menggunakan token akses yang mengawal skop dan tamat tempoh.
3. Apakah OAuth vs SAML?
OAuth dan SAML kedua-duanya merupakan rangka kerja kebenaran, tetapi OAuth menumpukan pada akses yang diwakilkan (kebenaran) terutamanya untuk API dan aplikasi mudah alih. SAML ialah protokol berasaskan XML terutamanya untuk Daftar Masuk Tunggal (pengesahan) dalam aplikasi web perusahaan. OAuth tidak menyediakan penegasan identiti, manakala SAML memberikan pengesahan pengguna dan maklumat atribut.
4. Apakah perbezaan antara OAuth dan JWT?
OAuth ialah protokol pengesahan yang mengeluarkan token untuk akses yang diwakilkan, manakala JWT (JSON Web Token) ialah format token padat yang sering digunakan dalam OAuth. JWT membawa maklumat yang dikodkan seperti identiti pengguna dan skop token. OAuth boleh menggunakan JWT sebagai token akses atau ID, tetapi JWT itu sendiri bukanlah protokol pengesahan atau kebenaran.
