Apa perbedaan antara OpenID dan OAuth?

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

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 mereka harus mengautentikasi ulang pengguna.

Posting blog " OpenID versus OAuth dari sudut pandang pengguna " memiliki perbandingan sederhana dari keduanya dari sudut pandang pengguna dan " OAuth-OpenID: Anda Mengganggu Pohon yang Salah jika Anda Mengira Mereka Sama Dengan Itu " memiliki informasi lebih lanjut tentang itu.

Ada tiga cara untuk membandingkan OAuth dan OpenID:

1. Tujuan

OpenID dibuat untuk autentikasi gabungan, yaitu membiarkan pihak ketiga mengautentikasi pengguna Anda untuk Anda, dengan menggunakan akun yang sudah mereka miliki . Istilah federated sangat penting di sini karena seluruh titik OpenID adalah bahwa penyedia apa pun dapat digunakan (dengan pengecualian daftar putih). Anda tidak perlu memilih 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 mencapai banyak hal yang sama. Mereka masing-masing menyediakan serangkaian fitur yang berbeda yang diinginkan oleh implementasi yang berbeda tetapi pada dasarnya, mereka cukup dipertukarkan. Pada intinya, kedua protokol adalah metode verifikasi pernyataan (OpenID terbatas pada pernyataan 'inilah saya', sementara OAuth menyediakan 'token akses' yang dapat ditukar dengan pernyataan dukungan 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 terpenting dari OpenID adalah proses penemuannya. OpenID tidak memerlukan pengkodean keras, masing-masing penyedia yang ingin Anda gunakan sebelumnya. Menggunakan penemuan, pengguna dapat memilih penyedia pihak ketiga apa pun yang ingin mereka otentikasi. Fitur penemuan ini juga telah menyebabkan sebagian besar masalah OpenID karena cara penerapannya adalah dengan menggunakan HTTP URI sebagai pengidentifikasi yang tidak didapatkan oleh sebagian besar pengguna web. 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 bolak-balik ke penyedia.

OAuth - fitur terpenting OAuth adalah token akses yang menyediakan metode jangka panjang untuk 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 memutuskan untuk menggunakan. Seorang pengguna yang mengunjungi situs Anda tidak dapat menggunakan pengidentifikasi apa pun, hanya yang telah dipilih sebelumnya oleh Anda. 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 itu yang mereka bagikan.

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

OpenID adalah (terutama) untuk identifikasi / otentikasi, sehingga stackoverflow.comtahu bahwa saya memiliki chris.boyle.name(atau di mana pun) dan karena itu saya mungkin orang yang sama dengan yang dimiliki chris.boyle.namekemarin dan mendapatkan beberapa poin reputasi.

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

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

Wikipedia bahasa Inggris

OAuth

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

yaitu Flickr menggunakan OAuth untuk memungkinkan layanan pihak ketiga memposting dan mengedit gambar orang atas nama mereka, tanpa mereka harus memberikan nama pengguna dan kata sandi yang berkedip.

OpenID

Digunakan untuk authenticateidentitas masuk tunggal. Semua yang seharusnya dilakukan oleh OpenID adalah mengizinkan penyedia OpenID untuk membuktikan bahwa Anda mengatakan Anda memang demikian. Namun banyak situs menggunakan otentikasi identitas untuk memberikan otorisasi (namun keduanya dapat dipisahkan)

yaitu Satu menunjukkan paspor mereka di bandara untuk mengotentikasi (atau membuktikan) orang yang namanya ada di tiket yang mereka gunakan adalah mereka.

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

• OpenID adalah protokol otentikasi standar dan desentralisasi terbuka yang dikendalikan oleh OpenID Foundation.
• OAuth adalah standar terbuka untuk delegasi akses.
• OpenID Connect (OIDC) Menggabungkan fitur-fitur OpenID dan OAuth yaitu melakukan Otentikasi dan Otorisasi.

OpenID mengambil bentuk URI unik yang dikelola oleh beberapa "penyedia OpenID" yaitu penyedia identitas (idP).

OAuth dapat digunakan bersama dengan XACML di mana OAuth digunakan untuk persetujuan kepemilikan dan delegasi akses sedangkan XACML digunakan untuk menentukan kebijakan otorisasi.

OIDC menggunakan JSON Web Tokens (JWT) sederhana, yang dapat Anda peroleh dengan menggunakan arus yang sesuai dengan spesifikasi OAuth 2.0 . OAuth secara langsung terkait dengan OIDC karena OIDC adalah lapisan otentikasi yang dibangun di atas OAuth 2.0 .

Misalnya , jika Anda memilih masuk ke Auth0 menggunakan akun Google Anda, maka Anda menggunakan OIDC . Setelah Anda berhasil mengautentikasi dengan Google dan mengotorisasi Auth0 untuk mengakses informasi Anda, Google akan mengirim kembali ke informasi Auth0 tentang pengguna dan otentikasi dilakukan. Informasi ini dikembalikan dalam JSON Web Token (JWT). Anda akan menerima Token Akses dan, jika diminta, Token ID. Jenis Token : Sumber: OpenID Connect

Analogi :
Suatu organisasi menggunakan kartu ID untuk tujuan identifikasi dan berisi chip, menyimpan rincian tentang Karyawan bersama dengan Otorisasi yaitu akses Kampus / Gerbang / ODC. Kartu ID bertindak sebagai OIDC dan Chip bertindak sebagai OAuth . lebih banyak contoh dan bentuk wiki

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

OpenID dimaksudkan untuk autentikasi gabungan. Seorang klien menerima pernyataan identitas dari penyedia mana pun (meskipun klien bebas untuk penyedia daftar putih atau daftar hitam).

OAuth dimaksudkan untuk otorisasi yang didelegasikan. Klien mendaftar dengan penyedia, yang menyediakan 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 tersebut berkembang. OpenID dan ekstensinya dapat digunakan untuk otorisasi, dan OAuth dapat digunakan untuk otentikasi, yang dapat dianggap sebagai otorisasi no-op.

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 cukup rinci dalam artikel (relatif baru, tetapi penting) ini: http://oauth.net/articles/authentication/

Penjelasan tentang perbedaan antara OpenID, OAuth, OpenID Connect:

OpenID adalah protokol untuk otentikasi sementara OAuth untuk otorisasi. Otentikasi adalah memastikan bahwa orang yang Anda ajak bicara memang orang yang ia klaim. Otorisasi adalah tentang memutuskan apa yang harus dilakukan pria itu.

Di OpenID, otentikasi didelegasikan: server A ingin mengautentikasi pengguna U, tetapi kredensial U (mis. Nama dan kata sandi U) dikirim ke server lain, B, yang dipercaya oleh A (setidaknya, kepercayaan untuk otentikasi pengguna). Memang, server B memastikan bahwa U memang U, dan kemudian memberi tahu A: "ok, itu U asli".

Dalam OAuth, otorisasi didelegasikan: entitas A memperoleh dari entitas B suatu "hak akses" yang A dapat tunjukkan ke server S untuk diberikan akses; Dengan demikian B dapat memberikan kunci akses sementara dan spesifik ke A tanpa memberi mereka terlalu banyak daya. Anda dapat membayangkan server OAuth sebagai master kunci di sebuah hotel besar; ia memberikan kunci karyawan yang membuka pintu kamar yang seharusnya mereka masuki, tetapi setiap kunci terbatas (tidak memberikan akses ke semua kamar); selanjutnya, kunci-kunci itu hancur sendiri setelah beberapa jam.

Hingga taraf tertentu, otorisasi dapat disalahgunakan ke dalam beberapa otentikasi semu, dengan dasar bahwa jika entitas A memperoleh dari B kunci akses melalui OAuth, dan menunjukkannya ke server S, maka server S dapat menyimpulkan bahwa B mengotentikasi A sebelum memberikan akses. kunci. Jadi beberapa orang menggunakan OAuth di mana mereka seharusnya menggunakan OpenID. Skema ini mungkin mencerahkan atau tidak; tapi saya pikir otentikasi semu ini lebih membingungkan daripada apa pun. OpenID Connect melakukan hal itu: ia menyalahgunakan OAuth menjadi protokol otentikasi. Dalam analogi hotel: jika saya bertemu dengan karyawan yang mengaku dan orang itu menunjukkan kepada saya bahwa dia memiliki kunci yang membuka kamar saya, maka saya mengira bahwa ini adalah karyawan sejati, dengan dasar bahwa pemimpin kunci tidak akan memberinya kunci yang membuka kamar saya jika tidak.

(sumber)

Apa perbedaan OpenID Connect dengan OpenID 2.0?

OpenID Connect melakukan banyak tugas yang sama seperti OpenID 2.0, tetapi melakukannya dengan cara yang ramah API, dan dapat digunakan oleh aplikasi asli dan seluler. OpenID Connect mendefinisikan mekanisme opsional untuk penandatanganan dan enkripsi yang kuat. Sedangkan integrasi OAuth 1.0a dan OpenID 2.0 memerlukan ekstensi, dalam OpenID Connect, kemampuan OAuth 2.0 terintegrasi dengan protokol itu sendiri.

(sumber)

Koneksi OpenID akan memberi Anda token akses plus token id. Token id adalah JWT dan berisi informasi tentang pengguna yang diautentikasi. Itu ditandatangani oleh penyedia identitas dan dapat dibaca dan diverifikasi tanpa mengakses penyedia identitas.

Selain itu, OpenID connect menstandarisasi beberapa hal yang harus dipilih. misalnya cakupan, penemuan titik akhir, dan pendaftaran klien yang dinamis.

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

(sumber)

Google OAuth 2.0

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

(sumber)

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

Pasti akan mengimplementasikan antarmuka otentikasi nama pengguna / kata sandi dasar khusus aplikasi, tetapi menyadari bahwa bagi semakin banyak pengguna, memikirkan nama pengguna dan kata sandi lain adalah penghalang. Meskipun bukan 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 itu, hanya ingin menawarkan kenyamanan tidak mengharuskan pengguna untuk mengatur kredensial akun baru jika mereka tidak mau. Dari sudut pandang fungsionalitas, sepertinya anak poster untuk OpenID. Tetapi tampaknya baik facebook maupun twitter bukan 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 tanpa-op" yang Saya melihat konfirmasi eksplisit bahwa OAuth cukup baik untuk apa yang ingin saya lakukan.

Bahkan, ketika saya memposting "jawaban" ini, bukan menjadi anggota pada saat itu, saya melihat panjang dan keras di bagian bawah halaman ini pada opsi untuk mengidentifikasi diri saya. Opsi untuk menggunakan login OpenID atau memperolehnya jika saya tidak memilikinya, tetapi tidak ada apa-apa tentang twitter atau facebook, sepertinya menyarankan bahwa OAuth tidak memadai 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 google id saya (yang merupakan OpenID) untuk alasan yang tepat bahwa saya tidak ingin memberikan akses stackoverflow ke daftar teman saya dan hal lain yang suka dibagikan facebook tentang penggunanya - tapi setidaknya itu '

Akan sangat bagus jika seseorang bisa mengirim info atau petunjuk ke info tentang mendukung jenis pengaturan otorisasi multi-bagian 3 ini, dan bagaimana Anda berurusan dengan 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 pengautentikasi pihak ketiga lainnya (mis. Sehingga saya akan dianggap login masuk ke stackoverflow jika saya masuk ke salah satu dari google, facebook, atau twitter ...). Karena situs ini melakukannya, seseorang di sini mungkin memiliki wawasan yang cukup bagus tentang masalah ini. :-)

Maaf ini sangat panjang, dan lebih merupakan pertanyaan daripada jawaban - tetapi komentar Karl membuatnya tampak sebagai tempat yang paling tepat untuk memposting di tengah volume utas tentang OAuth dan OpenID. Jika ada tempat yang lebih baik untuk ini yang tidak saya temukan, saya minta maaf sebelumnya, saya sudah mencoba.

OpenID membuktikan siapa Anda.

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

Saat ini saya sedang mengerjakan spec OAuth 2.0 dan OpenID connect. Jadi, inilah pemahaman saya: Sebelumnya mereka:

1. OpenID adalah implementasi eksklusif Google yang memungkinkan aplikasi pihak ketiga seperti untuk situs web surat kabar yang dapat Anda masuki menggunakan google dan mengomentari sebuah artikel dan sebagainya. Jadi intinya, tidak ada pembagian kata sandi ke situs web surat kabar. Biarkan saya membuat definisi di sini, pendekatan dalam pendekatan perusahaan ini disebut Federasi. Di Federasi, Anda memiliki server tempat Anda mengotentikasi dan mengotorisasi (disebut IDP, Penyedia Identitas) dan umumnya menjaga kredensial Pengguna. aplikasi klien di mana Anda memiliki bisnis disebut SP atau Penyedia Layanan. Jika kita kembali ke contoh situs web surat kabar yang sama maka situs web surat kabar adalah SP di sini dan Google adalah IDP. Di perusahaan masalah ini sebelumnya diselesaikan dengan menggunakan SAML. waktu itu XML digunakan untuk memerintah industri perangkat lunak. Jadi dari layanan web ke konfigurasi, semuanya digunakan untuk pergi ke XML sehingga kita memiliki SAML,

2. OAuth: OAuth melihat kemunculannya sebagai standar yang melihat semua jenis pendekatan kepemilikan ini dan jadi kami memiliki OAuth 1.o sebagai standar tetapi hanya menangani otorisasi. Tidak banyak orang yang memperhatikan, tetapi itu mulai terasa. Kemudian kami memiliki OAuth 2.0 pada tahun 2012. CTO, Architects benar-benar mulai memperhatikan ketika dunia bergerak menuju Cloud computing dan dengan perangkat komputasi yang bergerak ke arah perangkat mobile dan lainnya. Jenis OAuth dipandang sebagai pemecahan masalah utama di mana pelanggan perangkat lunak mungkin memberikan Layanan IDP ke satu perusahaan dan memiliki banyak layanan dari vendor yang berbeda seperti tenaga penjualan, SAP, dll. Jadi integrasi di sini benar-benar tampak seperti skenario federasi yang merupakan satu masalah besar, menggunakan SAML mahal. jadi mari kita jelajahi OAuth 2.o. Ohh, melewatkan satu poin penting yang selama ini, Google merasakan bahwa OAuth sebenarnya tidak

   Sebuah. OAuth 2.o tidak dengan jelas mengatakan, bagaimana pendaftaran klien akan terjadi b. itu tidak menyebutkan apa pun tentang interaksi antara SP (Resource Server) dan aplikasi klien (seperti Analytics Server yang menyediakan data adalah Resource Server dan aplikasi yang menampilkan data itu adalah Klien)

Sudah ada jawaban bagus yang diberikan di sini secara teknis, saya berpikir untuk memberikan perspektif evolusi singkat

OpenId menggunakan OAuth untuk menangani otentikasi.

Secara analogi, ini seperti .NET bergantung pada Windows API. Anda bisa langsung memanggil Windows API tetapi argumennya begitu luas, kompleks dan metode begitu luas, Anda bisa dengan mudah membuat kesalahan / bug / masalah keamanan.

Sama dengan OpenId / OAuth. OpenId mengandalkan OAuth untuk mengelola Otentikasi tetapi mendefinisikan Token tertentu (Id_token), tanda tangan digital dan aliran tertentu.

Saya ingin membahas aspek tertentu dari pertanyaan ini, sebagaimana ditangkap dalam komentar ini:

OAuth: sebelum memberikan akses ke beberapa fitur, otentikasi harus dilakukan, bukan? jadi OAuth = apa yang dilakukan OpenId + memberikan akses ke beberapa fitur? - Hassan Makarov 21 Jun jam 1:57

Iya dan tidak. Jawabannya halus, jadi bersabarlah.

Ketika aliran OAuth mengarahkan Anda ke layanan sasaran (penyedia OAuth, yaitu), itu adalah mungkin bahwa Anda akan perlu untuk mengotentikasi dengan layanan yang sebelum token akan diserahkan kembali ke aplikasi client / jasa. Token yang dihasilkan kemudian memungkinkan aplikasi klien untuk membuat permintaan atas nama pengguna yang diberikan.

Perhatikan umum kalimat terakhir itu: secara khusus, saya menulis "atas nama pengguna yang diberikan", bukan "atas nama Anda ". Adalah kesalahan umum untuk menganggap bahwa "memiliki kemampuan untuk berinteraksi dengan sumber daya yang dimiliki oleh pengguna tertentu" menyiratkan "Anda dan pemilik sumber daya target adalah satu yang sama".

Jangan membuat kesalahan ini.

Meskipun benar bahwa Anda mengautentikasi dengan penyedia OAuth (katakanlah, dengan nama pengguna dan kata sandi, atau mungkin sertifikat klien SSL, atau beberapa cara lain), apa yang diterima oleh klien tidak harus dianggap sebagai bukti identitas. Contohnya adalah aliran di mana akses ke sumber daya pengguna lain didelegasikan kepada Anda (dan dengan proxy, klien OAuth). Otorisasi tidak menyiratkan otentikasi.

Untuk menangani otentikasi, Anda mungkin ingin melihat ke OpenID Connect, yang pada dasarnya adalah lapisan lain di atas fondasi yang ditetapkan oleh OAuth 2.0. Berikut adalah kutipan yang menangkap (menurut saya) poin paling menonjol mengenai OpenID Connect (dari https://oauth.net/articles/authentication/ ):

OpenID Connect adalah standar terbuka yang diterbitkan pada awal 2014 yang mendefinisikan cara yang dapat dioperasikan untuk menggunakan OAuth 2.0 untuk melakukan otentikasi pengguna. Pada dasarnya, ini adalah resep fudge cokelat yang dipublikasikan secara luas yang telah dicoba dan diuji oleh sejumlah besar dan berbagai ahli. Alih-alih membangun protokol yang berbeda untuk setiap penyedia identitas potensial, suatu aplikasi dapat berbicara satu protokol kepada sebanyak mungkin penyedia yang ingin mereka gunakan. Karena ini merupakan standar terbuka, OpenID Connect dapat diterapkan oleh siapa saja tanpa batasan atau masalah kekayaan intelektual.

OpenID Connect dibangun langsung di OAuth 2.0 dan dalam banyak kasus digunakan tepat bersama (atau di atas) infrastruktur OAuth. OpenID Connect juga menggunakan paket spesifikasi dan penandaan objek JSON (JOSE) untuk membawa informasi yang ditandatangani dan dienkripsi di berbagai tempat yang berbeda. Bahkan, penyebaran OAuth 2.0 dengan kemampuan JOSE sudah jauh untuk mendefinisikan sistem OpenID Connect yang sepenuhnya sesuai, dan delta antara keduanya relatif kecil. Tapi delta itu membuat perbedaan besar, dan OpenID Connect berhasil menghindari banyak jebakan yang dibahas di atas dengan menambahkan beberapa komponen utama ke basis OAuth: [...]

Dokumen kemudian melanjutkan untuk menggambarkan (antara lain) ID token dan titik akhir UserInfo. Yang pertama menyediakan serangkaian klaim (siapa Anda, ketika token dikeluarkan, dll, dan mungkin tanda tangan untuk memverifikasi keaslian token melalui kunci publik yang diterbitkan tanpa harus meminta layanan hulu), dan yang terakhir menyediakan sarana misalnya menanyakan nama depan / belakang pengguna, email, dan bit info serupa, semuanya dengan cara terstandarisasi (sebagai lawan dari ekstensi ad-hoc ke OAuth yang digunakan orang sebelum OpenID Connect hal-hal terstandarisasi).

Kedua protokol dibuat untuk alasan yang berbeda. OAuth dibuat untuk mengotorisasi pihak ketiga untuk mengakses sumber daya. OpenID dibuat untuk melakukan validasi identitas desentralisasi. Situs web ini menyatakan sebagai berikut:

OAuth adalah protokol yang dirancang untuk memverifikasi identitas pengguna akhir dan untuk memberikan izin kepada pihak ketiga. Verifikasi ini menghasilkan token. Pihak ketiga dapat menggunakan token ini untuk mengakses sumber daya atas nama pengguna. Token memiliki cakupan. Ruang lingkup digunakan untuk memverifikasi apakah sumber daya dapat diakses oleh pengguna, atau tidak

OpenID adalah protokol yang digunakan untuk otentikasi terdesentralisasi. Otentikasi adalah tentang identitas; Menetapkan pengguna sebenarnya adalah orang yang dia klaim. Desentralisasi itu, berarti layanan ini tidak menyadari keberadaan sumber daya atau aplikasi apa pun yang perlu dilindungi. Itulah perbedaan utama antara OAuth dan OpenID.

OpenID Connect memperluas protokol otorisasi OAuth 2.0 untuk digunakan sebagai protokol otentikasi, sehingga Anda dapat melakukan sistem masuk tunggal menggunakan OAuth. OpenID Connect memperkenalkan konsep token ID, yang merupakan token keamanan yang memungkinkan klien untuk memverifikasi identitas pengguna

OAuth 2.0 adalah protokol Keamanan. Ini BUKAN Otentikasi atau protokol Otorisasi.

Otentikasi menurut definisi menjawab dua pertanyaan.

1. Siapa pengguna itu?
2. Apakah pengguna saat ini hadir di sistem?

OAuth 2.0 memiliki jenis hibah berikut

• client_credentials: Ketika satu aplikasi perlu berinteraksi dengan aplikasi lain dan memodifikasi data beberapa pengguna.
• authorization_code: Pengguna mendelegasikan server Otorisasi untuk mengeluarkan access_token yang dapat digunakan klien untuk mengakses sumber daya yang dilindungi
• refresh_token: Ketika access_token berakhir, token refresh dapat dimanfaatkan untuk mendapatkan access_token segar
• kata sandi: Pengguna memberikan kredensial masuk mereka ke klien yang memanggil server Otorisasi dan menerima access_token

Semua 4 memiliki satu kesamaan, access_token, artefak yang dapat digunakan untuk mengakses sumber daya yang dilindungi.

Access_token tidak memberikan jawaban atas 2 pertanyaan yang harus dijawab oleh protokol "Otentikasi".

Sebuah contoh untuk menjelaskan Oauth 2,0 (kredit: OAuth 2 in Action, Manning publikasi)

Mari kita bicara tentang cokelat. Kita bisa membuat banyak permen dari cokelat termasuk, fudge, es krim, dan kue. Tapi, tidak ada yang bisa disamakan dengan cokelat karena beberapa bahan lain seperti krim dan roti diperlukan untuk membuat konpeksi, meskipun cokelat terdengar seperti bahan utama. Demikian pula, OAuth 2.0 adalah cokelat, dan cookie, infrastruktur TLS, Penyedia Identitas adalah bahan lain yang diperlukan untuk menyediakan fungsionalitas "Otentikasi".

Jika Anda menginginkan Otentikasi, Anda dapat menggunakan OpenID Connect, yang menyediakan "id_token", selain dari access_token, yang menjawab pertanyaan yang harus dijawab oleh setiap protokol otentikasi.

OAuth membangun otentikasi di atas otorisasi: Pengguna mendelegasikan akses ke identitas mereka ke aplikasi, yang, kemudian, menjadi konsumen API identitas, dengan demikian menemukan siapa yang mengotorisasi klien di tempat pertama http://oauth.net/ artikel / otentikasi /