OpenID ve SAML arasındaki fark nedir?

OpenID ve SAML arasındaki fark nedir?

Orijinal OpenID 2.0 vs SAML

Bunlar iki farklı kimlik doğrulama protokolüdür ve teknik düzeyde farklılık gösterirler.

Uzaktan bakıldığında, kullanıcılar kimlik doğrulamasını başlattığında farklılıklar başlar. OpenID ile, bir kullanıcı oturumu genellikle kimlik doğrulamasından sorumlu olan kaynağın bir HTTP adresidir. Öte yandan, SAML, siteniz ile kimlik sağlayıcı arasındaki açık bir güvene dayanmaktadır, bu nedenle bilinmeyen bir siteden gelen kimlik bilgilerini kabul etmek oldukça nadirdir.

OpenID kimliklerinin ağda dolaşması kolaydır. Bir geliştirici olarak, çok farklı OpenID sağlayıcılarından gelen kullanıcıları kabul edebilirsiniz. Öte yandan, bir SAML sağlayıcısının genellikle önceden kodlanması gerekir ve uygulamanızı yalnızca seçilen kimlik sağlayıcılarla birleştirirsiniz. Kabul edilen OpenID kimlik sağlayıcılarının listesini daraltmak mümkündür, ancak bunun genel OpenID konseptine aykırı olacağını düşünüyorum.

OpenID ile rastgele sunuculardan gelen kimlikleri kabul edersiniz. Birisi öyle olduğunu iddia ediyor http://someopenid.provider.com/john.smith. Bunu veritabanınızdaki bir kullanıcıyla nasıl eşleştireceksiniz? Bir şekilde, örneğin bu bilgileri yeni bir hesapla saklayarak ve kullanıcı sitenizi tekrar ziyaret ettiğinde bunu fark ederek. Kullanıcı hakkındaki diğer bilgilere (adı veya e-postası dahil) güvenilemeyeceğini unutmayın!

Öte yandan, uygulamanız ve SAML Kimlik Sağlayıcısı arasında açık bir güven varsa, kullanıcı hakkında ad ve e-posta dahil olmak üzere tüm bilgileri edinebilirsiniz ve bu bilgiler, güven ilişkisi nedeniyle güvenilir olabilir. Bu, Kimlik Sağlayıcının tüm bilgileri bir şekilde doğruladığına inanma eğiliminde olduğunuz ve uygulama düzeyinde buna güvenebileceğiniz anlamına gelir. Kullanıcılar bilinmeyen bir sağlayıcı tarafından verilen SAML belirteçleriyle gelirse, uygulamanız kimlik doğrulamayı reddeder.

OpenID Connect vs SAML

(bölüm 07-2017, genişletilmiş 08-2018)

Bu cevap 2011 yılına tarihlenmektedir ve o sırada OpenID, OpenID 2.0 anlamına gelmektedir . Daha sonra 2012'de bir yerde, OAuth2.0 yayınlandı ve 2014'te OpenID Connect (daha ayrıntılı bir zaman çizelgesi burada ) yayınlandı.

Bugünlerde bunu okuyan herkes için - OpenID Connect, orijinal yanıtın başvurduğu OpenID ile aynı değil, OAuth2.0 için bir dizi uzantı.

İken bu yanıt kavramsal açıdan ışık tutabilir, birisi OAuth2.0 arka plan ile geliyor için çok özlü versiyonu OpenID'yi Bağlan olmasıdır olduğu gerçeği OAuth2.0 içinde ancak standart bir yol ekler kullanıcı bilgisi sorgulama erişim belirteci sonra, kullanılabilir.

Orijinal soruya atıfta bulunursak - OpenID Connect (OAuth2.0) ile SAML arasındaki temel fark nedir, uygulama ile kimlik sağlayıcı arasındaki güven ilişkisinin nasıl kurulduğudur:

• SAML güven ilişkisini dijital bir imza üzerine kurar, kimlik sağlayıcı tarafından verilen SAML belirteçleri imzalı XML'lerdir, uygulama imzanın kendisini ve sunduğu sertifikayı doğrular. Kullanıcı bilgileri, diğer bilgilerin yanı sıra bir SAML belirtecine dahil edilir.

• OAuth2, uygulamadan kimliğe doğrudan bir HTTP çağrısı üzerine güven ilişkisini oluşturur. İstek, erişim belirtecini (protokol akışı sırasında uygulama tarafından elde edilen) içerir ve yanıt, kullanıcı hakkındaki bilgileri içerir.

• OpenID Connect , uygulamadan kimlik sağlayıcıya yapılan çağrıyı içeren bu ekstra adım olmadan kimliğin alınmasını mümkün kılmak için bunu daha da genişletir . Fikir, OpenID Connect sağlayıcılarının gerçekte iki jeton yayınlaması gerçeğine dayanmaktadır, access_tokenaynı OAuth2.0 sorunları ve yeni id_tokenolan, kimlik sağlayıcı tarafından imzalanan bir JWT belirteci . Uygulama , JWT belirtecine dahil edilen taleplere dayalı olarak yerel bir oturum kurmak için kullanabilir, ancak diğer hizmetleri daha fazla sorgulamak için kullanılamaz , üçüncü taraf hizmetlerine yapılan bu tür aramalar yine deid_tokenid_token access_token. OpenID Connect her ikisini de içerdiğinden, OpenID Connect'i SAML2 (imzalı belirteç) ve OAuth2 (erişim belirteci) arasında bir karma olarak düşünebilirsiniz.

OpenID ve SAML2'nin her ikisi de aynı birleşik kimlik kavramına dayanmaktadır. Aralarındaki bazı farklar aşağıdadır.

1. SAML2 tek oturum kapatmayı destekler, ancak OpenID desteklemez
2. SAML2 hizmet sağlayıcıları, SAML2 Kimlik Sağlayıcıları ile birleştirilir, ancak OpenID'ye bağlı taraflar, OpenID Sağlayıcıları ile birleştirilmez. OpenID, bir OpenID verildiğinde ilgili OpenID Sağlayıcısını dinamik olarak keşfeden bir keşif protokolüne sahiptir. SAML, Identity Provider Discovery Service Protocol'e dayalı bir keşif protokolüne sahiptir.
3. SAML2 ile, kullanıcı SAML2 IdP'ye bağlanır - SAML2 tanımlayıcınız yalnızca onu veren SAML2 IdP için geçerlidir. Ancak OpenID ile tanımlayıcınızın sahibi olursunuz ve bunu istediğiniz herhangi bir OpenID Sağlayıcısı ile eşleyebilirsiniz.
4. SAML2 farklı bağlamalara sahipken OpenID'nin sahip olduğu tek bağlama HTTP'dir
5. SAML2, Servis Sağlayıcı (SP) tarafından başlatılmış veya Kimlik Sağlayıcı (IdP) tarafından başlatılmış olabilir. Ancak OpenID her zaman SP başlattı.
6. SAML 2 XML'e dayanır, ancak OpenID değildir.
7. Son 3 yılda geliştirilen uygulamaların çoğu yalnızca OpenID Connect'i destekliyordu.
8. Mayıs 2018'de Microsoft Azure AD verilen 8B + kimlik doğrulama isteklerinin% 92'si OpenID Connect etkin uygulamalardan geldi.

Teknik ayrıntıları bir kenara koyarsak, parti için oldukça geç kaldığım için, SAML ile diğer kimlik doğrulama standartları (OpenID dahil) arasındaki en büyük farkın,

SAML , Kimlik Sağlayıcının (IDP) ve Hizmet Sağlayıcının (SP) önceden birbirlerini tanımasını, önceden yapılandırılmış , statik kimlik doğrulaması ve yetkilendirmeyi gerektirir. OpenId (+ Connect) böyle bir gereksinime sahip değildir.

Bu, verilere kimin eriştiği üzerinde tam kontrol sahibi olmak isteyen ÜİYOK'ler için önemlidir. Standardın bir kısmı, belirli SP'lere sağlananları yapılandırmaktır.

Örneğin, bir banka, kullanıcılarının önceden tanımlanmış bazı hizmetler dışında herhangi bir hizmete erişmesini istemeyebilir (düzenlemeler veya diğer katı güvenlik kuralları nedeniyle).

Bu, bir OpenId IDP'nin böyle bir kısıtlamayı uygulayamayacağı anlamına gelmez. Bir OpenID uygulayıcısı erişimi kontrol edebilir, ancak OpenID'nin amacı bu değildir.

Önceden tanımlanmış, katı, statik, erişim denetimi farkı dışında kavramsal olarak (teknik olarak değil), OpenID Connect ve SAML benzerdir.

Sonuç olarak, bir SP iseniz, müşterilerinizin ihtiyaç duyduğu şeyi desteklemelisiniz:

1. Müşteriniz bireysel bir son kullanıcı müşterisiyse (örneğin, google kimliklerini kullanarak), SAML'yi unutun. OpenID Connect'i kullanın.
2. Müşteriniz, çalışanlarının hizmetinizi kullanmasını ve hizmetinize sağlayacağı yalnızca statik verilerin listesini dışa aktarmasını isteyen bir bankaysa, banka muhtemelen SAML'yi desteklemenizi isteyecektir. Banka, müşteri kısıtlaması olan bir OpenID uygulamasına sahip olabilir, bu sizin şanslı gününüz olacak :)

Hem SAML hem de OpenID, kimlik sağlayıcı (kısaltılmış IdP), yani merkezi olmayan kimlik doğrulama protokolü (tek oturum açma kimliği) olarak işlev görebilir.

S ecurity bir ssertion M arkup L anguage ( SAML ) güvenlik alanları arasında bir kimlik doğrulama ve yetkilendirme veri alışverişi için profillerin bir dizi. SAML etki alanı modelinde, kimlik sağlayıcı, özel bir kimlik doğrulama yetkisi türüdür. Spesifik olarak, bir SAML kimlik sağlayıcısı, SAML'nin bir SSO profiliyle bağlantılı olarak kimlik doğrulama iddiaları yayınlayan bir sistem varlığıdır. Bu kimlik doğrulama iddialarını kullanan bağlı tarafa SAML hizmet sağlayıcısı adı verilir. Kaynak

O kalem İD Cı taşıyıcılarına bağlanması ( OIDC ) OAuth 2.0, bir yetkilendirme çerçevesinin üzerine bir kimlik doğrulama tabakasıdır. Standart, OpenID Vakfı tarafından kontrol edilmektedir. OAuth, bir kimlik doğrulama protokolü ve bir kimlik doğrulama protokolü olarak özel olarak tasarlanmış OpenID yerine yetkilendirme protokolü içindir. OIDC, basit JSON Web Jetonları (JWT) kullanır, JavaScript tarafından tüketilmeleri daha kolaydır.

Kullanım durumu Senaryosu:

Kullanıcılarınız Facebook veya Twitter ile oturum açmak istiyorsa OAuth kullanın. Kullanıcılarınız "kendi kimliklerine başkasının sahip olmasını istemedikleri için" kendi OpenID sağlayıcılarını çalıştıran boyun sakallarıysa OpenID'yi kullanın.

Kaynak