SAML ve OAuth ile birleşik giriş karşılaştırması

SAML ile OAuth ile federe giriş arasındaki fark nedir? Bir şirket üçüncü taraf bir web uygulamasını kullanmak ve aynı zamanda tek oturum açma ve kimlik doğrulama yetkilisi olmak istiyorsa hangi çözüm daha mantıklıdır?

Farklı sorunları çözerler.

SAML , bir kullanıcının kim olduğu, özniteliklerinin neler olduğu hakkında bilgi paylaşmak ve size bir şeye erişim izni verme / reddetme ve hatta kimlik doğrulama talebinde bulunma yolu sunan bir dizi standarttır.

OAuth daha çok bir şeye erişim yetkisi vermekle ilgilidir . Temelde birisinin sizin gibi "hareket etmesine" izin veriyorsunuz. En yaygın olarak sizin adınıza bir şeyler yapabilen erişim API'leri vermek için kullanılır.

Tamamen farklı iki şeydir.

Yardımcı olabilecek bazı örnekler.

OAuth bir twitter düşün. Diyelim ki Google Buzz ve Twitter kullanıyorsunuz ve ikisini senkronize tutabilmek için bir uygulama yazmak istiyorsunuz. Temel olarak uygulamanız ve twitter arasında güven oluşturabilirsiniz. Uygulamayı twitter'a bağlamaya ilk kez gittiğinizde, Twitter'da oturum açmak için klasik komut istemini yaparsınız ve ardından bu onay kutusu açılır ve "Uygulamanızın adına erişim izni vermek ister misiniz?" Diye sorar. "evet" i tıkladığınızda, güven sağlanmıştır ve artık uygulamanız Twitter'da sizin gibi davranabilir. Gönderilerinizi okuyabilir ve yenilerini yapabilir.

SAML - SAML için, iki alakasız üyelik sistemi arasında bir tür "anlaşma" düşünün. Bizim durumumuzda US Airways ve Hertz kullanabiliriz. Sizi bir siteden diğerine götürebilecek paylaşılan bir kimlik bilgisi seti yoktur, ancak Hertz'in US Airways'e bir "anlaşma" teklif etmek istediğini söyleyelim. (Bunun aşırı bir örnek olduğunu bildiğimi kabul ediyorum, ancak bana katlanın). Bir uçuş satın aldıktan sonra, Başkan üyelerine ücretsiz bir kiralık araba sunacaklar. US Airways ve Hertz, bir çeşit güven ve kullanıcıyı tanımlamanın bir yolunu kuracaktı. Bizim durumumuzda "federe kimliğimiz" e-posta adresi olacaktır ve bu, Hertz'in US Airways kimlik sağlayıcısının doğru ve güvenli bir şekilde bir belirteç teslim edeceğine güvendiği tek yol güveni olacaktır. Uçuş rezervasyonunu yaptıktan sonra US Airways kimlik sağlayıcısı, bir token oluşturacak ve kullanıcıyı nasıl doğruladıklarını ve ayrıca bizim durumumuzda kişi hakkındaki "öznitelikleri" dolduracaktır. Jeton doldurulduktan sonra, onu bir tür referans yoluyla iletir veya bir url'de kodlanır ve Hertz'e ulaştığımızda, jetona bakar, onu doğrular ve şimdi ücretsiz kiralık arabaya izin verebilir.

Bu SAML örneğindeki sorun, birçok kullanımdan yalnızca birinin özel kullanım durumudur. SAML bir standarttır ve onu uygulayabileceğiniz neredeyse pek çok yol vardır.

Alternatif olarak, yetkilendirmeyi önemsemiyorsanız, SAML ve OpenID aracılığıyla kimlik doğrulamayı neredeyse iddia edebilirsiniz .

Burada özetlenen bu basit açıklamaya bir göz atın :

SAML, OpenID ve OAuth arasındaki farklar pek çok insanın kafası karışık, ama aslında çok basit. Bir miktar örtüşme olsa da, burada üçünü birbirinden ayırmanın çok basit bir yolu var.

OpenID - tüketiciler için tek oturum açma

SAML - kurumsal kullanıcılar için tek oturum açma

OAuth - Uygulamalar arasında API yetkilendirmesi

OO tasarım modellerinde rahat olan kişiler için, sarmalayıcı modellerinin güzel bir sonucu olduğunu düşünüyorum . Cephe , Dekoratör ve Proxy modellerini düşünün . Temelde bu ... onlar sadece sarmalayıcılarını konum hepsi aynı farktır niyeti her desen .

Benzer şekilde, SAML, OAuth ve OpenID'nin tümü , bazı özel etkileşim için bir hizmet sağlayıcıya / kimlik otoritesine yeniden yönlendirme ve ardından kaynak üçüncü taraf uygulamasına yeniden yönlendirme olan ortak bir temel mekanizma aracılığıyla farklı niyetleri kolaylaştırır .

Ağda etrafa bakınca, protokollerin yetenekleri arasında örtüşme olduğunu göreceksiniz. OAuth aracılığıyla kimlik doğrulama son derece makul. OAuth üzerinden SSO çok anlamlı olmayabilir, ancak SAML ve OpenID özellikle federe kimliğe yöneliktir.

Sorunun kendisine, kurumsal bağlamda SAML, SSO için OAuth'tan daha uygun görünmektedir . Kurumsal kimliklerinizle entegre etmek istediğiniz üçüncü taraf uygulamalarına bakarsanız bahse girerim, bunların SAML / LDAP / Radius vb. İle entegre olacak şekilde tasarlandığını göreceksiniz. IMO OAuth İnternet etkileşimi için daha uygundur. uygulamalar arasında veya belki de büyük bir şirket ortamında bir Servis Odaklı Mimari içeren uygulamalar arasında.

Yetki kuralları başka şekillerde de kurumsal bir ortamda belirtilebilir. LDAP bunun için yaygın bir araçtır. Kullanıcıları gruplar halinde organize etmek ve uygulama ayrıcalıklarını grup üyeliğine göre ilişkilendirmek yaygın bir yaklaşımdır. Aynen böyle olur LDAP, kimlik doğrulama için de kullanılabilir. Active Directory harika bir örnek, ancak OpenLDAP'yi tercih etmeme rağmen.

İnce bir kullanım durumunu ele alıyorlar

• SAML - Bir kullanıcının kimlik bilgilerini (ör. SSO) çeşitli hizmet sağlayıcılarla (ör. Web veya web hizmeti) paylaşma
• OAuth - Bir Uygulamayı kendi adına bir kaynağa erişmesi için yetkilendiren bir Kullanıcı

Burada iyi makale bulundu

SAML (Güvenlik Onayı Biçimlendirme Dili), Tek Oturum Açma (SSO), Federasyon ve Kimlik Yönetimi sağlamak için bir dizi standarttır.

Örnek : Bir kullanıcı (asıl), servis rezervasyon web sitesi Shuttler (servis sağlayıcı) ile SAML üzerinden SSO yapılandırılmış bir uçuş rezervasyon web sitesi, AirFlyer (kimlik sağlayıcı) ile kimlik doğrulaması yapar. Flyer'da kimlik doğrulaması yapıldığında, kullanıcı kimlik doğrulama gerektirmeden Shuttler'da servis rezervasyonu yapabilir

OAuth (Açık Yetkilendirme), kaynakların yetkilendirilmesi için bir standarttır. Kimlik doğrulama ile ilgilenmez.

Örnek : Kullanıcıların Instagram hesaplarından (OAuth sağlayıcı) fotoğrafları içe aktarmalarına olanak tanıyan ve fotoğraf paylaşım uygulamasına birkaç saat sonra sona eren geçici bir erişim jetonu veya anahtarı gönderen bir fotoğraf paylaşım mobil uygulaması (OAuth tüketicisi).

SAML, diğer kullanıcıların sitenize "giriş yapmasına" olanak tanıyan çeşitli "profillere" sahiptir. SAML-P veya SAML Passive çok yaygındır ve kurulumu oldukça basittir. WS-Trust benzerdir ve web siteleri arasında federasyona da izin verir.

OAuth, yetkilendirme için tasarlanmıştır. Daha fazlasını buradan okuyabilirsiniz:

OpenID ve OAuth arasındaki fark nedir?

SAMLkimlik doğrulama içindir - çoğunlukla Tek Oturum Açma senaryosunda kullanılır. OAuthkaynak temsillerinin yetkilendirilmesi içindir.

JSON Web Belirteci (JWT) , SAML XML Belirteçleri için bir alternatiftir. JWT, OAuth ile kullanılabilir

SAML ve OAuth karşılaştırması iyi bir referans : Hangisini Kullanmalıyım?

Federasyon terimleri gerçekten sistemler arasında bağlantı kimlikleri anlamına gelir. SSO ile ilgili ancak tamamen aynı değiller. Bu blog gönderisini federasyonun gerçekte ne anlama geldiği açısından gerçekten yararlı buldum.