Pertanyaan Apa perbedaan antara OpenID dan OAuth?


Saya benar-benar mencoba memahami perbedaan antara OpenID dan OAuth? Mungkin mereka dua hal yang benar-benar terpisah?


812
2017-07-06 13:40


asal


Jawaban:


OpenID adalah tentang otentikasi (mis. membuktikan siapa Anda), OAuth adalah tentang otorisasi (mis. untuk memberikan akses ke fungsionalitas / data / dll. tanpa harus berurusan dengan otentikasi asli).

OAuth dapat digunakan di situs mitra eksternal untuk memungkinkan akses ke data yang dilindungi tanpa harus mengautentikasi ulang pengguna.

Pos blog "OpenID versus OAuth dari perspektif pengguna"memiliki perbandingan sederhana dari keduanya dari perspektif pengguna dan"OAuth-OpenID: Anda Menggosok Pohon Salah Jika Anda Pikirkan Mereka Adalah Hal yang Sama"memiliki lebih banyak informasi tentang itu.


701
2017-07-06 13:47



Ada tiga cara untuk membandingkan OAuth dan OpenID:

1. Tujuan

OpenID dibuat untuk otentikasi federasi, yaitu membiarkan pihak ketiga mengotentikasi pengguna Anda untuk Anda, dengan menggunakan akun yang sudah mereka miliki. Istilah federasi sangat penting di sini karena seluruh titik OpenID adalah setiap penyedia dapat digunakan (dengan pengecualian daftar-putih). Anda tidak perlu memilih di awal atau menegosiasikan kesepakatan dengan penyedia untuk memungkinkan pengguna menggunakan akun lain yang mereka miliki.

OAuth dibuat untuk menghapus kebutuhan pengguna untuk membagikan kata sandi mereka dengan aplikasi pihak ketiga. Ini sebenarnya dimulai sebagai cara untuk memecahkan masalah OpenID: jika Anda mendukung OpenID di situs Anda, Anda tidak dapat menggunakan kredensial HTTP Basic (nama pengguna dan kata sandi) untuk menyediakan API karena pengguna tidak memiliki kata sandi di situs Anda.

Masalahnya adalah dengan pemisahan OpenID untuk otentikasi dan OAuth untuk otorisasi adalah bahwa kedua protokol dapat menyelesaikan banyak hal yang sama. Mereka masing-masing menyediakan seperangkat fitur yang berbeda yang diinginkan oleh berbagai penerapan tetapi pada dasarnya, mereka sangat dapat dipertukarkan. Pada intinya, kedua protokol adalah metode verifikasi pernyataan (OpenID terbatas pada 'ini adalah pernyataan siapa saya', sementara OAuth menyediakan 'token akses' yang dapat ditukar dengan pernyataan yang didukung melalui API).

2. Fitur

Kedua protokol menyediakan cara bagi situs untuk mengarahkan ulang pengguna di tempat lain dan kembali dengan pernyataan yang dapat diverifikasi. OpenID memberikan pernyataan identitas sementara OAuth lebih umum dalam bentuk token akses yang kemudian dapat digunakan untuk "menanyakan pertanyaan penyedia OAuth". Namun, mereka masing-masing mendukung fitur yang berbeda:

OpenID - fitur yang paling penting dari OpenID adalah proses penemuannya. OpenID tidak memerlukan hard coding setiap penyedia yang ingin Anda gunakan sebelumnya. Dengan menggunakan penemuan, pengguna dapat memilih penyedia pihak ketiga yang ingin mereka autentikasi. Fitur penemuan ini juga telah menyebabkan sebagian besar masalah OpenID karena cara penerapannya adalah dengan menggunakan HTTP URI sebagai pengidentifikasi yang sebagian besar pengguna web tidak dapatkan. Fitur lain yang dimiliki OpenID adalah dukungannya untuk pendaftaran klien ad-hoc menggunakan pertukaran DH, mode langsung untuk pengalaman pengguna akhir yang dioptimalkan, dan cara untuk memverifikasi pernyataan tanpa melakukan perjalanan pulang-pergi ke penyedia.

OAuth- fitur yang paling penting dari OAuth adalah token akses yang menyediakan metode tahan lama dalam membuat permintaan tambahan. Tidak seperti OpenID, OAuth tidak berakhir dengan otentikasi tetapi menyediakan token akses untuk mendapatkan akses ke sumber daya tambahan yang disediakan oleh layanan pihak ketiga yang sama. Namun, karena OAuth tidak mendukung penemuan, itu membutuhkan pra-pemilihan dan pengkodean-keras penyedia yang Anda putuskan untuk digunakan. Pengguna yang mengunjungi situs Anda tidak dapat menggunakan pengenal apa pun, hanya yang telah Anda pilih sebelumnya. Selain itu, OAuth tidak memiliki konsep identitas sehingga menggunakannya untuk masuk berarti menambahkan parameter khusus (seperti yang dilakukan oleh Twitter) atau membuat panggilan API lain untuk mendapatkan pengguna yang "masuk" saat ini.

3. Implementasi Teknis

Kedua protokol berbagi arsitektur umum dalam menggunakan pengalihan untuk mendapatkan otorisasi pengguna. Di OAuth, pengguna memberi otorisasi akses ke sumber daya yang dilindungi dan di OpenID, ke identitas mereka. Tapi hanya itulah yang mereka bagikan.

Setiap protokol memiliki cara berbeda dalam menghitung tanda tangan yang digunakan untuk memverifikasi keaslian permintaan atau tanggapan, dan masing-masing memiliki persyaratan pendaftaran yang berbeda.


318
2017-07-06 13:45



OpenID (terutama) untuk identifikasi / otentikasi, sehingga stackoverflow.com tahu aku memilikinya chris.boyle.name (atau dimanapun) dan oleh karena itu saya mungkin orang yang sama yang dimiliki chris.boyle.name kemarin dan mendapat beberapa poin reputasi.

OAuth dirancang untuk otorisasi untuk mengambil tindakan atas nama Anda, sehingga stackoverflow.com (atau di mana saja) dapat meminta izin untuk, katakanlah, Tweet atas nama Anda secara otomatis, tanpa mengetahui kata sandi Twitter Anda.


93
2018-05-19 08:37



Banyak orang masih mengunjungi ini jadi inilah diagram yang sangat sederhana untuk menjelaskannya

OpenID_vs._pseudo-authentication_using_OAuth

Courtesy Wikipedia


78
2017-07-06 20:15



OAuth 

Digunakan untuk didelegasikan authorization hanya - artinya Anda memberi otorisasi akses layanan pihak ketiga untuk menggunakan data pribadi, tanpa memberikan kata sandi. Juga "sesi" OAuth umumnya hidup lebih lama daripada sesi pengguna. Artinya OAuth dirancang untuk memungkinkan otorisasi

yaitu Flickr menggunakan OAuth untuk mengizinkan layanan pihak ketiga untuk memposting dan mengedit gambar orang atas nama mereka, tanpa harus mengeluarkan nama pengguna dan kata sandi flicker mereka.

OpenID

Biasanya authenticate single sign-on identity. Semua OpenID seharusnya dilakukan adalah mengijinkan penyedia OpenID untuk membuktikan bahwa Anda mengatakan Anda. Namun banyak situs menggunakan otentikasi identitas untuk memberikan otorisasi (namun keduanya dapat dipisahkan)

Misalnya, menunjukkan paspor mereka di bandara untuk mengautentikasi (atau membuktikan) siapa nama orang tersebut pada tiket yang mereka gunakan adalah mereka.


39
2018-03-20 19:37



Gunakan OAuth jika pengguna Anda mungkin ingin masuk dengan Facebook atau Twitter. Gunakan OpenID jika pengguna Anda adalah neckbeards yang menjalankan penyedia OpenID mereka sendiri karena mereka "tidak ingin orang lain memiliki identitas mereka".


30
2017-08-27 23:27



OpenID dan OAuth masing-masing protokol berbasis HTTP untuk otentikasi dan / atau otorisasi. Keduanya dimaksudkan untuk memungkinkan pengguna melakukan tindakan tanpa memberikan kredensial otentikasi atau izin blanket kepada klien atau pihak ketiga. Meskipun mereka serupa, dan ada standar yang diusulkan untuk menggunakannya bersama-sama, keduanya merupakan protokol yang terpisah.

OpenID ditujukan untuk otentikasi federasi. Klien menerima pernyataan identitas dari penyedia mana pun (meskipun klien bebas untuk penyedia daftar putih atau daftar hitam).

OAuth ditujukan untuk otorisasi yang didelegasikan. Klien mendaftar dengan penyedia, yang memberikan token otorisasi yang akan diterima untuk melakukan tindakan atas nama pengguna.

OAuth saat ini lebih cocok untuk otorisasi, karena interaksi lebih lanjut setelah otentikasi dibangun ke dalam protokol, tetapi kedua protokol sedang berkembang. OpenID dan ekstensinya dapat digunakan untuk otorisasi, dan OAuth dapat digunakan untuk otentikasi, yang dapat dianggap sebagai otorisasi no-op.


17
2018-01-12 11:18



Saya percaya masuk akal untuk meninjau kembali pertanyaan ini sebagaimana juga ditunjukkan dalam komentar, pengenalan OpenID Connect mungkin telah membawa lebih banyak kebingungan.

OpenID Connect adalah protokol otentikasi seperti OpenID 1.0 / 2.0 tetapi sebenarnya dibangun di atas OAuth 2.0, sehingga Anda akan mendapatkan fitur otorisasi bersama dengan fitur otentikasi. Perbedaan antara keduanya dijelaskan dengan sangat baik secara rinci dalam artikel ini (yang relatif baru, tetapi penting): http://oauth.net/articles/authentication/


13
2017-10-06 06:41



Lebih banyak ekstensi untuk pertanyaan daripada jawaban, tetapi mungkin menambah beberapa perspektif untuk jawaban teknis yang bagus di atas. Saya seorang programmer yang berpengalaman di sejumlah bidang, tetapi total noob untuk pemrograman untuk web. Sekarang mencoba membangun aplikasi berbasis web menggunakan Zend Framework.

Tentunya akan mengimplementasikan antarmuka otentikasi nama pengguna / sandi dasar aplikasi-spesifik, tetapi mengenali bahwa untuk semakin banyak pengguna, pemikiran tentang nama pengguna dan kata sandi yang lain adalah penghalang. Meskipun tidak persis jejaring sosial, saya tahu bahwa persentase yang sangat besar dari pengguna potensial aplikasi sudah memiliki akun facebook atau twitter. Aplikasi tidak benar-benar ingin atau perlu mengakses informasi tentang akun pengguna dari situs-situs tersebut, itu hanya ingin menawarkan kenyamanan karena tidak mengharuskan pengguna untuk mengatur kredensial akun baru jika mereka tidak mau. Dari sudut pandang fungsi, itu akan tampak seperti poster untuk OpenID. Namun tampaknya baik facebook maupun twitter adalah penyedia OpenID, meskipun mereka mendukung otentikasi OAuth untuk mengakses data pengguna mereka.

Dalam semua artikel yang saya baca tentang keduanya dan bagaimana mereka berbeda, tidak akan sampai saya melihat pengamatan Karl Anderson di atas, bahwa "OAuth dapat digunakan untuk otentikasi, yang dapat dianggap sebagai otorisasi no-op" yang Saya melihat konfirmasi eksplisit bahwa OAuth cukup baik untuk apa yang ingin saya lakukan.

Bahkan, ketika saya memposting "jawaban" ini, tidak menjadi anggota pada saat itu, saya melihat panjang dan keras di bagian bawah halaman ini pada pilihan untuk mengidentifikasi diri saya sendiri. Pilihan untuk menggunakan login OpenID atau mendapatkan satu jika saya tidak memiliki satu, tapi tidak ada tentang twitter atau facebook, sepertinya menyarankan bahwa OAuth tidak cukup untuk pekerjaan itu. Tapi kemudian saya membuka jendela lain dan mencari proses pendaftaran umum untuk stackoverflow - dan lihatlah ada banyak pilihan otentikasi pihak ketiga termasuk facebook dan twitter. Pada akhirnya saya memutuskan untuk menggunakan id google saya (yang merupakan OpenID) untuk alasan persis mengapa saya tidak ingin memberikan akses stackoverflow ke daftar teman saya dan apa pun yang suka facebook bagikan tentang penggunanya - tapi setidaknya itu adalah bukti bahwa OAuth memadai untuk penggunaan yang ada dalam pikiran saya.

Akan sangat bagus jika seseorang dapat mengeposkan info atau petunjuk untuk info tentang mendukung pengaturan otorisasi tiga bagian yang terdiri dari beberapa bagian ini, dan bagaimana Anda menangani pengguna yang mencabut otorisasi atau kehilangan akses ke situs pihak ke-3 mereka. Saya juga mendapat kesan bahwa nama pengguna saya di sini mengidentifikasi akun stackoverflow unik yang dapat saya akses dengan otentikasi dasar jika saya ingin mengaturnya, dan juga mengakses akun yang sama ini melalui autentikator pihak ke-3 lainnya (misalnya agar saya dianggap masuk masuk ke stackoverflow jika saya masuk ke salah satu google, facebook, atau twitter ...). Karena situs ini melakukannya, seseorang di sini mungkin memiliki beberapa wawasan yang cukup bagus tentang hal ini. :-)

Maaf, ini sangat panjang, dan lebih banyak pertanyaan daripada jawaban - tetapi ucapan Karl membuatnya tampak seperti tempat paling tepat untuk memposting di tengah volume utas pada OAuth dan OpenID. Jika ada tempat yang lebih baik untuk ini yang tidak saya temukan, saya mohon maaf sebelumnya, saya memang mencoba.


11
2017-10-30 20:38



Penjelasan tentang perbedaan antara OpenID, OAuth, OpenID Connect:

OpenID adalah protokol untuk otentikasi sementara OAuth untuk   otorisasi. Otentikasi adalah tentang memastikan bahwa pria itu adalah Anda   berbicara dengan memang orang yang dia klaim. Otorisasi adalah tentang   memutuskan apa yang seharusnya dilakukan pria itu.

Di OpenID, otentikasi didelegasikan: server A ingin mengautentikasi   pengguna U, tetapi kredensial U (misalnya nama dan kata sandi U) dikirim ke   server lain, B, yang dipercayai (setidaknya, kepercayaan untuk mengautentikasi   pengguna). Memang, server B memastikan bahwa U benar-benar U, dan kemudian memberitahu   to A: "ok, itu asli U".

Di OAuth, otorisasi didelegasikan: entitas A memperoleh dari entitas B   "hak akses" yang A dapat tunjukkan ke server S untuk diberikan akses; B   sehingga dapat memberikan kunci akses khusus sementara ke A tanpa memberi   mereka terlalu banyak kekuatan. Anda dapat membayangkan server OAuth sebagai master kunci   di hotel besar; dia memberikan kunci karyawan yang membuka pintu   ruangan yang seharusnya dimasukkan, tetapi setiap tombol terbatas (itu   tidak memberikan akses ke semua kamar); selanjutnya, kuncinya   menghancurkan diri sendiri setelah beberapa jam.

Sampai batas tertentu, otorisasi dapat disalahgunakan menjadi beberapa   pseudo-authentication, atas dasar bahwa jika entitas A memperoleh dari B an   mengakses kunci melalui OAuth, dan menunjukkannya ke server S, maka server S mungkin   menyimpulkan bahwa B mengotentikasi A sebelum memberikan kunci akses. Jadi sebagian   orang menggunakan OAuth di mana mereka harus menggunakan OpenID. Skema ini dapat atau   mungkin tidak mencerahkan; tapi saya pikir pseudo-authentication ini   lebih membingungkan dari apapun. OpenID Connect tidak hanya itu: itu pelanggaran   OAuth menjadi protokol otentikasi. Dalam analogi hotel: jika saya   bertemu dengan karyawan yang diakui dan orang itu menunjukkan kepada saya bahwa dia memiliki   kunci yang membuka kamarku, maka kurasa ini adalah karyawan sejati,   atas dasar bahwa master kunci tidak akan memberinya kunci yang   membuka kamarku jika dia tidak.

(sumber)

Bagaimana OpenID Connect berbeda dari OpenID 2.0?

OpenID Connect melakukan banyak tugas yang sama dengan OpenID 2.0, tetapi tidak   jadi dengan cara yang ramah API, dan dapat digunakan oleh penduduk asli dan seluler   aplikasi. OpenID Connect mendefinisikan mekanisme opsional untuk robust   penandatanganan dan enkripsi. Sedangkan integrasi OAuth 1.0a dan OpenID   2.0 membutuhkan ekstensi, di OpenID Connect, kemampuan OAuth 2.0 terintegrasi dengan protokol itu sendiri.

(sumber)

Sambungan OpenID akan memberi Anda token akses plus token id. Identitas   Token adalah JWT dan berisi informasi tentang pengguna yang diotentikasi.   Ini ditandatangani oleh penyedia identitas dan dapat dibaca dan diverifikasi   tanpa mengakses penyedia identitas.

Selain itu, OpenID menghubungkan standarisasi beberapa hal itu   oauth2 menyisakan pilihan. misalnya lingkup, penemuan titik akhir,   dan pendaftaran klien yang dinamis.

Ini membuatnya lebih mudah menulis kode yang memungkinkan pengguna memilih di antara keduanya   beberapa penyedia identitas.

(sumber)

Google OAuth 2.0

Google OAuth 2.0 API dapat digunakan untuk otentikasi dan   otorisasi. Dokumen ini menjelaskan penerapan OAuth 2.0 kami   untuk otentikasi, yang sesuai dengan OpenID Connect   spesifikasi, dan Bersertifikasi OpenID. Dokumentasi ditemukan di    Menggunakan OAuth 2.0 untuk Mengakses Google API juga berlaku untuk layanan ini. Jika   Anda ingin menjelajahi protokol ini secara interaktif, kami merekomendasikan    Google OAuth 2.0 Playground.

(sumber)


10
2017-12-26 11:41



OpenID membuktikan siapa dirimu.

OAuth memberikan akses ke fitur yang disediakan oleh pihak yang berwenang.


3
2018-03-16 19:16