SAML vs proses masuk gabungan dengan OAuth

100

Apa perbedaan antara SAML dan login federasi dengan OAuth? Solusi mana yang lebih masuk akal, jika perusahaan ingin menggunakan aplikasi web pihak ketiga, dan juga menginginkan sistem masuk tunggal dan menjadi otoritas autentikasi?

authentication  oauth  saml 
— Chung Wu
sumber

Jawaban:

128

Mereka memecahkan masalah yang berbeda.

SAML adalah seperangkat standar yang telah ditetapkan untuk berbagi informasi tentang siapa pengguna, apa set atributnya, dan memberi Anda cara untuk memberikan / menolak akses ke sesuatu atau bahkan meminta otentikasi.

OAuth lebih tentang mendelegasikan akses ke sesuatu. Anda pada dasarnya mengizinkan seseorang untuk "bertindak" sebagai Anda. Ini paling sering digunakan untuk memberikan api akses yang dapat melakukan sesuatu atas nama Anda.

Mereka adalah dua hal yang sangat berbeda.

Beberapa contoh yang mungkin membantu.

OAuth memikirkan sebuah twitter. Katakanlah Anda menggunakan Google Buzz dan Twitter, dan Anda ingin membuat aplikasi agar keduanya tetap sinkron. Pada dasarnya Anda dapat membangun kepercayaan antara aplikasi dan twitter Anda. Pertama kali Anda pergi untuk menautkan aplikasi ke twitter, Anda melakukan perintah klasik untuk masuk ke twitter, dan kemudian kotak konfirmasi itu muncul dan bertanya "Apakah Anda ingin memberikan akses ke« nama aplikasi Anda »?" setelah Anda mengklik "ya", kepercayaan telah terbentuk, dan sekarang aplikasi Anda dapat bertindak sebagai Anda di Twitter. Itu dapat membaca posting Anda, serta membuat yang baru.

SAML - Untuk SAML pikirkan beberapa jenis "perjanjian" antara dua sistem keanggotaan yang tidak terkait. Dalam kasus kami, kami dapat menggunakan US Airways dan Hertz. Tidak ada kumpulan kredensial bersama yang dapat membawa Anda dari satu situs ke situs lain, tetapi katakanlah Hertz ingin menawarkan "kesepakatan" kepada US Airways. (Memang saya tahu ini adalah contoh ekstrim, tapi bersabarlah). Setelah membeli penerbangan, mereka akan menawarkan mobil sewaan gratis kepada anggota Ketua. US Airways dan Hertz akan menyiapkan beberapa bentuk kepercayaan, dan beberapa cara untuk mengidentifikasi pengguna. Dalam kasus kami, "id federasi" kami adalah alamat email, dan ini akan menjadi salah satu cara yang dipercaya Hertz bahwa penyedia identitas US Airways akan mengirimkan token yang akurat dan aman. Setelah memesan penerbangan, penyedia identitas US Airways akan membuat token dan mengisi cara mereka mengautentikasi pengguna, serta "atribut" tentang orang tersebut, dalam kasus kami, atribut yang paling penting adalah tingkat statusnya di US Airways. Setelah token diisi, ia meneruskannya melalui beberapa jenis referensi, atau dikodekan dalam url dan begitu kita sampai di Hertz, ia melihat token tersebut, memvalidasinya dan sekarang dapat mengizinkan mobil sewaan gratis.

Masalah dengan contoh SAML ini adalah hanya satu kasus penggunaan khusus dari banyak kasus. SAML adalah standar dan ada terlalu banyak cara untuk menerapkannya.

Atau, jika Anda tidak peduli dengan otorisasi, Anda hampir dapat membantah bahwa menegaskan otentikasi melalui SAML dan OpenID .

— Nix
sumber
4
Saya masih tidak mengerti perbedaannya. "berikan / tolak akses" dan "berikan akses ke api" terdengar seperti hal yang sama bagi saya. Bisakah Anda memberikan 2 contoh yang lebih mirip, jadi saya bisa melihat perbedaannya? Misalnya, mengapa kami tidak dapat menggunakan SAML untuk membangun kepercayaan antara aplikasi Anda dan Twitter? Atau mengapa Anda tidak dapat menggunakan OAuth untuk Hertz untuk memberi tahu USAirways tentang penawaran khusus?
— Tim Cooper
3
Saya agak mengerti, tetapi saya selalu dapat melakukan SSO dengan OAuth (dengan meminta akses ke API yang memberikan identitas). Apakah itu berarti OAuth dapat melakukan semua hal yang dapat dilakukan SAML dan banyak lagi?
— Dirk
@Dirk Anda hampir benar, yaitu kami bisa mendapatkan identitas pengguna menggunakan OAuth serta seperti banyak aplikasi yang meminta login melalui Google, Facebook, GitHub untuk mendapatkan identitas pengguna dan atribut lainnya agar mereka dapat masuk ke aplikasi mereka. Namun memang benar bahwa kita dapat mencapai lebih dari sekadar mendapatkan identitas menggunakan OAuth.
— chirag soni
39

Simak penjelasan sederhana yang dirangkum di sini:

Banyak orang bingung tentang perbedaan antara SAML, OpenID dan OAuth, tetapi sebenarnya sangat sederhana. Meskipun ada beberapa tumpang tindih, berikut ini cara yang sangat sederhana untuk membedakan ketiganya.

OpenID - sistem masuk tunggal untuk konsumen

SAML - sistem masuk tunggal untuk pengguna perusahaan

OAuth - Otorisasi API antar aplikasi

Untuk orang yang nyaman dengan pola desain OO, saya pikir ada konsekuensi yang bagus untuk pola pembungkus . Pikirkan pola Fasad , Dekorator , dan Proxy . Pada dasarnya ini semua sama, mereka hanya pembungkus ... Perbedaannya adalah tujuan dari setiap pola .

Demikian pula, SAML, OAuth, dan OpenID semuanya memfasilitasi maksud yang berbeda melalui mekanisme dasar yang umum , yaitu pengalihan ke penyedia layanan / otoritas identitas untuk beberapa interaksi pribadi, diikuti dengan pengalihan ke aplikasi pihak ketiga asal.

Melihat sekeliling di internet Anda akan menemukan tumpang tindih antara kemampuan protokol. Otentikasi melalui OAuth sangat wajar. SSO melalui OAuth mungkin tidak terlalu masuk akal karena SAML dan OpenID secara khusus ditujukan untuk identitas gabungan.

Untuk pertanyaan itu sendiri, dalam konteks perusahaan SAML terdengar lebih sesuai daripada OAuth untuk SSO . Saya berani bertaruh jika Anda melihat aplikasi pihak ketiga yang ingin Anda integrasikan dengan identitas perusahaan Anda, Anda akan menemukan bahwa mereka sudah dirancang untuk diintegrasikan dengan SAML / LDAP / Radius dll. IMO OAuth lebih sesuai untuk interaksi Internet antara aplikasi atau mungkin aplikasi yang terdiri dari Arsitektur Berorientasi Layanan di lingkungan perusahaan besar.

Aturan otorisasi juga dapat ditentukan di lingkungan perusahaan dengan cara lain. LDAP adalah alat umum untuk ini. Mengorganisir pengguna ke dalam grup dan mengaitkan hak aplikasi dengan keanggotaan grup adalah pendekatan yang tersebar luas. Kebetulan LDAP juga dapat digunakan untuk otentikasi. Active Directory adalah contoh yang bagus, meskipun saya lebih suka OpenLDAP.

— quickshiftin
sumber
1
Terima kasih telah memperbarui tautan @Sundeep
— quickshiftin
Tautan diperbarui, namun ringkasan yang sudah ada di jawabannya sama.
— quickshiftin
OpenID dibuat hanya di oAuth. oAuth tidak mendukung antarmuka pengguna itu sendiri. OpenId melakukannya untuk kami. Tidak ada perbedaan lain antara oAuth dan OpenID
— Ini jebakan
@ Itatrap tidak benar; OpenID tentang otentikasi, OAuth adalah tentang otorisasi, namun mereka berbagi mekanisme (pengalihan browser) yang serupa. Tidak banyak hubungannya dengan UI ... Lihat jawaban ini juga. Anda juga bisa melihat di sini . Anda juga bisa membaca kembali jawaban saya untuk penjelasan lebih lanjut haha.
— quickshiftin
1
@ It'satrap Anda mungkin ingin melihat OpenId Spec " otentikasi dibangun di atas OAuth 2.0"; dan juga Spesifikasi OAuth 2.0 "Kerangka otorisasi OAuth 2.0 " ... Sekali lagi, satu dirancang untuk autentikasi , yang lainnya untuk otorisasi . Memanfaatkan yang terakhir untuk yang pertama tidak apa-apa karena mereka memiliki paradigma dasar yang sama (untuk ketiga atau keempat kalinya saya mengatakannya lol). Semua diringkas dalam jawaban saya yang tidak berubah. Kamu harus belajar cara membaca bro.
— quickshiftin
3

Menemukan artikel Bagus di sini

masukkan deskripsi gambar di sini

SAML (Security Assertion Markup Language) ditetapkan sebagai standar untuk mencapai Single Sign On (SSO), Federation and Identity Management.

Contoh : Pengguna (kepala sekolah) mengautentikasi dengan situs web pemesanan penerbangan, AirFlyer (penyedia identitas) yang telah dikonfigurasi SSO melalui SAML dengan situs web pemesanan antar-jemput, Shuttler (penyedia layanan). Setelah diautentikasi ke Flyer, pengguna dapat memesan angkutan di Shuttler tanpa memerlukan otentikasi

OAuth (Open Authorization) adalah standar untuk otorisasi sumber daya. Ini tidak berhubungan dengan otentikasi.

Contoh : Aplikasi seluler berbagi foto (konsumen OAuth) yang memungkinkan pengguna mengimpor foto dari akun Instagram mereka (penyedia OAuth) yang mengirimkan token atau kunci akses sementara ke aplikasi berbagi foto yang kedaluwarsa setelah beberapa jam.

— pk_code
sumber
2

SAML memiliki berbagai "profil" untuk dipilih, memungkinkan pengguna lain untuk "masuk" ke situs Anda. SAML-P atau SAML Passive sangat umum dan cukup mudah disiapkan. WS-Trust serupa dan juga memungkinkan untuk federasi antar situs web.

OAuth dirancang untuk otorisasi. Anda dapat membaca lebih lanjut di sini:

Apa perbedaan antara OpenID dan OAuth?

— goodguys_activate
sumber
Saya kesulitan memahami perbedaan antara "login" dan "otorisasi". Dapatkah Anda memberikan contoh yang menggambarkan perbedaan tersebut?
— Tim Cooper
@TimCooper "login" adalah terminologi longgar untuk otentikasi sedangkan "otorisasi" adalah otorisasi yang baik ... Contoh sesuai permintaan Anda
— quickshiftin
1
@quickshiftin Oke, saya mengerti perbedaan itu. Jawaban Anda sepertinya menyiratkan bahwa SAML melakukan autentikasi sedangkan OAuth melakukan otorisasi. Apakah itu benar? Atau apakah mereka berdua melakukan keduanya - (dalam hal ini saya masih tidak tahu apa perbedaannya).
— Tim Cooper
1
@TimCooper Protokol memiliki beberapa kemampuan yang tumpang tindih. OAuth ditargetkan pada otorisasi, tetapi juga mendukung otentikasi . SSO dalam konteks perusahaan adalah sesuatu yang dibuat untuk SAML. Di sisi lain, SAML juga mendukung otorisasi. The konteks adalah faktor yang paling penting ketika memutuskan teknologi yang digunakan. Tahun lalu saya menulis ekstensi untuk Expression Engine yang menggunakan SimpleSAMLPhp untuk mengotentikasi pengguna terhadap backend Kerberos, lalu mencari aturan otorisasi dari sistem LDAP. Dunia gila di luar sana!
— quickshiftin
2

Mereka menangani kasus penggunaan yang halus

  • SAML - Berbagi kredensial (mis., SSO) pengguna ke berbagai penyedia layanan (mis., Web atau layanan web)
  • OAuth - Pengguna yang mendelegasikan Aplikasi untuk mengakses sumber daya atas namanya
— yudis
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.