Apa perbedaan antara OpenID dan SAML?

Apa perbedaan antara OpenID dan SAML?

OpenID 2.0 asli vs SAML

Mereka adalah dua protokol otentikasi yang berbeda dan mereka berbeda pada tingkat teknis.

Dari kejauhan, perbedaan dimulai ketika pengguna memulai otentikasi. Dengan OpenID, login pengguna biasanya merupakan alamat HTTP sumber daya yang bertanggung jawab untuk otentikasi. Di sisi lain, SAML didasarkan pada kepercayaan eksplisit antara situs Anda dan penyedia identitas sehingga agak jarang menerima kredensial dari situs yang tidak dikenal.

Identitas OpenID mudah ditemukan di internet. Sebagai pengembang, Anda dapat menerima pengguna yang berasal dari penyedia OpenID yang sangat berbeda. Di sisi lain, penyedia SAML biasanya harus diberi kode terlebih dahulu dan Anda menggabungkan aplikasi Anda dengan hanya penyedia identitas yang dipilih. Adalah mungkin untuk mempersempit daftar penyedia identitas OpenID yang diterima tetapi saya pikir ini akan bertentangan dengan konsep OpenID umum.

Dengan OpenID Anda menerima identitas yang berasal dari server yang arbitrer. Seseorang mengaku http://someopenid.provider.com/john.smith. Bagaimana Anda akan mencocokkan ini dengan pengguna di basis data Anda? Entah bagaimana, misalnya dengan menyimpan informasi ini dengan akun baru dan mengenali ini ketika pengguna mengunjungi situs Anda lagi. Perhatikan bahwa informasi lain tentang pengguna (termasuk nama atau emailnya) tidak dapat dipercaya!

Di sisi lain, jika ada kepercayaan eksplisit antara aplikasi Anda dan Penyedia Id SAML, Anda bisa mendapatkan informasi lengkap tentang pengguna termasuk nama dan email dan informasi ini dapat dipercaya, hanya karena hubungan kepercayaan. Ini berarti bahwa Anda cenderung percaya bahwa Penyedia Id entah bagaimana memvalidasi semua informasi dan Anda dapat mempercayainya di tingkat aplikasi. Jika pengguna datang dengan token SAML yang dikeluarkan oleh penyedia yang tidak dikenal, aplikasi Anda hanya menolak otentikasi.

OpenID Connect vs SAML

(bagian ditambahkan 07-2017, diperluas 08-2018)

Jawaban ini bertanggal 2011 dan pada saat itu OpenID adalah singkatan dari OpenID 2.0 . Kemudian, di suatu tempat di 2012, OAuth2.0 telah diterbitkan dan pada tahun 2014, OpenID Connect (garis waktu lebih rinci di sini ).

Bagi siapa pun yang membaca ini saat ini - OpenID Connect tidak sama dengan OpenID yang dijawab oleh jawaban asli , melainkan kumpulan ekstensi untuk OAuth2.0.

Sementara jawaban ini dapat titik terang dari sudut pandang konseptual, versi yang sangat singkat untuk seseorang yang datang dengan latar belakang OAuth2.0 adalah bahwa OpenID Connect adalah sebenarnya OAuth2.0 tetapi menambahkan cara standar query info pengguna , setelah token akses tersedia.

Mengacu pada pertanyaan awal - apa perbedaan utama antara OpenID Connect (OAuth2.0) dan SAML adalah bagaimana hubungan kepercayaan dibangun antara aplikasi dan penyedia identitas:

• SAML membangun hubungan kepercayaan pada tanda tangan digital, token SAML yang dikeluarkan oleh penyedia identitas ditandatangani XML, aplikasi memvalidasi tanda tangan itu sendiri dan sertifikat yang dihadirkannya. Informasi pengguna termasuk dalam token SAML, di antara informasi lainnya.

• OAuth2 membangun hubungan kepercayaan pada panggilan HTTP langsung dari aplikasi ke identitas. Permintaan berisi token akses (diperoleh oleh aplikasi selama aliran protokol) dan respons berisi informasi tentang pengguna.

• OpenID Connect selanjutnya memperluas ini untuk memungkinkannya mendapatkan identitas tanpa langkah tambahan yang melibatkan panggilan dari aplikasi ke penyedia identitas. Idenya didasarkan pada fakta bahwa penyedia OpenID Connect sebenarnya mengeluarkan dua token, yang access_token, yang sama persis dengan masalah OAuth2.0 dan yang baru, id_tokenyang merupakan token JWT , ditandatangani oleh penyedia identitas. Aplikasi dapat menggunakan id_tokenuntuk membuat sesi lokal, berdasarkan klaim yang termasuk dalam token JWT tetapi id_token tidak dapat digunakan untuk lebih lanjut meminta layanan lain, panggilan tersebut ke layanan pihak ketiga masih harus menggunakanaccess_token. Anda dapat memikirkan OpenID Connect kemudian sebagai gabungan antara SAML2 (token yang ditandatangani) dan OAuth2 (token akses), karena OpenID Connect hanya melibatkan keduanya.

OpenID dan SAML2 keduanya didasarkan pada konsep identitas gabungan yang sama. Berikut adalah beberapa perbedaan di antara mereka ..

1. SAML2 mendukung keluar tunggal - tetapi OpenID tidak
2. Penyedia layanan SAML2 digabungkan dengan Penyedia Identitas SAML2, tetapi pihak yang mengandalkan OpenID tidak digabungkan dengan Penyedia OpenID. OpenID memiliki protokol penemuan yang secara dinamis menemukan Penyedia OpenID terkait, begitu OpenID diberikan. SAML memiliki protokol penemuan berdasarkan Identity Provider Discovery Service Protocol.
3. Dengan SAML2, pengguna digabungkan ke SAML2 IdP - pengidentifikasi SAML2 Anda hanya berlaku untuk SAML2 IdP yang menerbitkannya. Tetapi dengan OpenID, Anda memiliki pengidentifikasi Anda dan Anda dapat memetakannya ke Penyedia OpenID yang Anda inginkan.
4. SAML2 memiliki binding berbeda sedangkan OpenID yang mengikat hanya memiliki HTTP
5. SAML2 dapat berupa Penyedia Layanan (SP) yang diinisiasi atau Penyedia Identitas (IdP) yang dimulai. Tetapi OpenID selalu memulai SP.
6. SAML 2 didasarkan pada XML sedangkan OpenID tidak.
7. Sebagian besar aplikasi yang dikembangkan dalam 3 tahun terakhir hanya mendukung OpenID Connect.
8. 92% dari permintaan otentikasi 8B + yang diberikan Microsoft Azure AD pada Mei 2018 berasal dari aplikasi yang didukung OpenID Connect.

Mengesampingkan detail teknis, karena sangat terlambat untuk pesta, apa yang saya pahami bahwa perbedaan terbesar antara SAML dan standar auth lainnya (termasuk OpenID) adalah bahwa

SAML mensyaratkan Penyedia Identitas (IDP) dan Penyedia Layanan (SP), untuk saling mengenal sebelumnya, pra-konfigurasi , otentikasi dan otorisasi statis . OpenId (+ Connect) tidak memiliki persyaratan seperti itu.

Ini penting bagi pengungsi yang menginginkan kontrol penuh atas siapa yang mengakses data. Bagian dari standar adalah untuk mengkonfigurasi apa yang disediakan untuk SP tertentu.

Misalnya, bank mungkin tidak ingin penggunanya mengakses layanan apa pun kecuali beberapa yang telah ditentukan sebelumnya (karena peraturan atau aturan keamanan ketat lainnya).

Ini tidak berarti bahwa OpenId IDP, tidak dapat menerapkan pembatasan seperti itu. Seorang pelaksana OpenID dapat mengontrol akses, tetapi itu bukan tujuan dari OpenID.

Selain perbedaan kontrol akses yang telah ditentukan, ketat, statis, konseptual (tidak secara teknis), OpenID Connect dan SAML serupa.

Intinya, jika Anda seorang SP, Anda harus mendukung apa yang pelanggan Anda butuhkan:

1. Jika pelanggan Anda adalah pelanggan pengguna akhir individu (menggunakan id google mereka misalnya), lupakan SAML. Gunakan OpenID Connect.
2. Jika pelanggan Anda adalah bank yang ingin karyawannya menggunakan layanan Anda dan hanya mengekspor daftar data statis yang akan diberikannya ke layanan Anda, bank mungkin akan meminta Anda untuk mendukung SAML. Bank mungkin memiliki implementasi OpenID dengan batasan klien, yang akan menjadi hari keberuntungan Anda :)

SAML dan OpenID dapat bertindak sebagai penyedia identitas (disingkat IdP) yaitu protokol otentikasi terdesentralisasi (identitas akses tunggal).

The S ecurity A ssertion M arkup L anguage ( SAML ) adalah satu set profil untuk bertukar otentikasi dan otorisasi data di domain keamanan. Dalam model domain SAML, penyedia identitas adalah jenis otoritas autentikasi khusus. Secara khusus, penyedia identitas SAML adalah entitas sistem yang mengeluarkan pernyataan otentikasi bersama dengan profil SSO SAML. Pihak yang mengandalkan yang mengkonsumsi pernyataan otentikasi ini disebut penyedia layanan SAML. Sumber

O pena ID C onnect ( OIDC ) adalah lapisan otentikasi di atas OAuth 2.0, kerangka otorisasi. Standar ini dikendalikan oleh OpenID Foundation. OAuth untuk protokol otorisasi, bukan protokol otentikasi dan OpenID yang dirancang khusus sebagai protokol otentikasi. OIDC menggunakan JSON Web Tokens (JWT) sederhana, mereka lebih mudah dikonsumsi oleh JavaScript.

Skenario penggunaan kasus:

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".

Sumber