OpenID ve OAuth arasındaki fark nedir?

Gerçekten OpenID ve OAuth arasındaki farkı anlamaya çalışıyorum? Belki de tamamen ayrı iki şeydir?

OpenID kimlik doğrulama ile ilgilidir (yani kim olduğunuzu kanıtlamakla), OAuth yetkilendirme ile ilgilidir (yani orijinal kimlik doğrulama ile uğraşmaksızın işlevsellik / veri / vb. Erişim izni vermek).

OAuth, bir kullanıcının yeniden kimliğini doğrulamak zorunda kalmadan korumalı verilere erişim sağlamak için harici iş ortağı sitelerinde kullanılabilir.

" Kullanıcının bakış açısından OAuth'a karşı OpenID " blog yazısı , kullanıcının bakış açısından ikisinin basit bir karşılaştırmasına sahiptir ve " OAuth-OpenID: Aynı Şey Olduğunu Düşünüyorsanız Yanlış Ağacı Barking Edersiniz " daha fazla bilgiye sahiptir hakkında.

OAuth ve OpenID'yi karşılaştırmanın üç yolu vardır:

1. Amaçlar

OpenID, birleşik kimlik doğrulaması için oluşturulmuş, yani üçüncü bir tarafın zaten sahip oldukları hesapları kullanarak kullanıcılarınızı sizin için doğrulamasına izin vermiştir . Burada federasyon terimi kritik öneme sahiptir, çünkü OpenID'nin bütün amacı herhangi bir sağlayıcının kullanılabilmesi (beyaz listeler hariç). Kullanıcıların sahip oldukları diğer hesapları kullanmalarına izin vermek için sağlayıcılarla bir anlaşma seçmeniz veya pazarlık etmeniz gerekmez.

OAuth, kullanıcıların şifrelerini üçüncü taraf uygulamalarla paylaşma ihtiyacını ortadan kaldırmak için oluşturuldu . Aslında bir OpenID sorununu çözmenin bir yolu olarak başladı: Sitenizde OpenID'yi destekliyorsanız, kullanıcıların sitenizde bir parolası olmadığı için bir API sağlamak için HTTP Temel kimlik bilgilerini (kullanıcı adı ve şifre) kullanamazsınız.

Sorun, kimlik doğrulama için OpenID'nin ayrılması ve yetkilendirme için OAuth ile her iki protokolün de aynı şeylerin çoğunu başarabilmesidir. Her biri farklı uygulamalar tarafından istenen farklı özellikler sunar, ancak aslında birbirlerinin yerine kullanılabilirler. Özünde, her iki protokol de bir onaylama doğrulama yöntemidir (OpenID 'ben kimim' iddiasıyla sınırlıdır, OAuth ise bir API aracılığıyla desteklenen herhangi bir onaylama ile değiştirilebilen bir 'erişim belirteci' sağlar).

2. Özellikler

Her iki protokol de bir sitenin bir kullanıcıyı başka bir yere yönlendirmesi ve doğrulanabilir bir iddia ile geri gelmesi için bir yol sağlar. OIDA, daha sonra "OAuth sağlayıcı sorularını sormak" için kullanılabilecek bir erişim belirteci biçiminde daha genelken OpenID bir kimlik iddiası sağlar . Ancak, her biri farklı özellikleri destekler:

OpenID - OpenID'nin en önemli özelliği keşif sürecidir. OpenID, önceden kullanmak istediğiniz her sağlayıcı için sabit kodlama gerektirmez. Keşif kullanarak, kullanıcı kimlik doğrulaması yapmak istediği herhangi bir üçüncü taraf sağlayıcıyı seçebilir. Bu bulma özelliği, OpenID sorunlarının çoğuna da neden olmuştur, çünkü uygulama şekli HTTP URI'lerini çoğu web kullanıcısının alamadığı tanımlayıcılar olarak kullanmaktır. OpenID'nin diğer özellikleri, DH değişimi kullanan geçici istemci kaydı, optimize edilmiş son kullanıcı deneyimi için anında mod ve sağlayıcıya başka bir gidiş dönüş yapmadan iddiaları doğrulamanın bir yoludur.

OAuth - OAuth'un en önemli özelliği, ek istekler yapmak için uzun süreli bir yöntem sağlayan erişim belirtecidir. OpenID'den farklı olarak, OAuth kimlik doğrulamasıyla bitmez ancak aynı üçüncü taraf hizmeti tarafından sağlanan ek kaynaklara erişmek için bir erişim belirteci sağlar. Ancak, OAuth keşfi desteklemediğinden, kullanmaya karar verdiğiniz sağlayıcıların önceden seçilmesini ve kodlanmasını gerektirir. Sitenizi ziyaret eden bir kullanıcı herhangi bir tanımlayıcı kullanamaz, yalnızca sizin tarafınızdan önceden seçilmiş olanları kullanamaz. Ayrıca, OAuth bir kimlik kavramına sahip değildir, bu yüzden giriş için kullanmak, özel bir parametre eklemek (Twitter tarafından yapıldığı gibi) veya şu anda "giriş yapmış" kullanıcıyı almak için başka bir API çağrısı yapmak anlamına gelir.

3. Teknik Uygulamalar

İki protokol, kullanıcı yetkisi almak için yeniden yönlendirmeyi kullanmada ortak bir mimariyi paylaşır. OAuth'da kullanıcı, korunan kaynaklarına ve OpenID'de kimliklerine erişim yetkisi verir. Ama paylaştıkları tek şey bu.

Her protokol, isteğin veya yanıtın gerçekliğini doğrulamak için kullanılan bir imzayı hesaplamanın farklı bir yoluna sahiptir ve her birinin farklı kayıt gereksinimleri vardır.

OpenID (esas olarak) kimlik doğrulama / kimlik doğrulaması içindir, bu yüzden sahip stackoverflow.comolduğumu chris.boyle.name(veya her yerde) ve dolayısıyla chris.boyle.namedün sahip olduğum ve bazı itibar puanları kazandığım aynı kişi olduğumu bilir .

OAuth, sizin adınıza işlem yapma yetkisi vermek üzere tasarlanmıştır, böylece stackoverflow.com(veya her yerde) Twitter şifrenizi bilmeden sizin adınıza otomatik olarak Tweet'e izin isteyebilir.

Birçok kişi hala bunu ziyaret ediyor, bu yüzden açıklamak için çok basit bir diyagram

Vikipedi'nin izniyle

OAuth

authorizationYalnızca yetki verilenler için kullanılır - yani, üçüncü taraf hizmetlere şifre vermeden kişisel verileri kullanma yetkisi verdiğiniz anlamına gelir. Ayrıca OAuth "oturumları" genellikle kullanıcı oturumlarından daha uzun yaşar. OAuth'un yetkilendirmeye izin verecek şekilde tasarlandığı anlamına gelir

Flickr, üçüncü taraf hizmetlerinin titreme kullanıcı adı ve şifresi vermek zorunda kalmadan bir kişi resmini kendi adına yayınlamasına ve düzenlemesine izin vermek için OAuth'u kullanır.

OpenID

İçin kullanılır authenticatetekli oturum açma kimlik. Tüm OpenID'nin yapması gereken bir OpenID sağlayıcısının sizin olduğunuzu kanıtlamasına izin vermektir. Ancak, birçok site yetkilendirme sağlamak için kimlik doğrulaması kullanır (ancak ikisi ayrılabilir)

Yani, havaalanında pasaportlarını, kullandıkları biletin üzerinde bulunan kişinin kimliğini doğrulamak (veya ispatlamak) için gösterir.

Kullanıcılarınız sadece Facebook veya Twitter ile giriş yapmak istiyorsa OAuth'u kullanın. Kullanıcılarınız kendi OpenID sağlayıcılarını çalıştıran boyun sakalıysa OpenID kullanın, çünkü "kimliklerinin başka kimseye sahip olmasını istemezler".

• OpenID , OpenID Foundation tarafından kontrol edilen açık standart ve merkezi olmayan bir kimlik doğrulama protokolüdür.
• OAuth bir olduğunu açık bir standart erişim heyeti için.
• OpenID Connect (OIDC) OpenID ve OAuth özelliklerini birleştirir, yani hem Kimlik Doğrulama hem de Yetkilendirme yapar.

OpenID , bazı "OpenID sağlayıcısı" yani kimlik sağlayıcısı (idP) tarafından yönetilen benzersiz bir URI biçimini alır .

OAuth , sahiplik onayı ve erişim yetkilendirmesi için OAuth'un kullanıldığı XACML ile birlikte kullanılabilirken, yetkilendirme politikalarını tanımlamak için XACML kullanılır.

OIDC , OAuth 2.0 spesifikasyonlarına uygun akışları kullanarak elde edebileceğiniz basit JSON Web Belirteçlerini (JWT) kullanır . OAuth , doğrudan OIDC ile ilişkilidir, çünkü OIDC , OAuth 2.0 üzerine kurulmuş bir kimlik doğrulama katmanıdır .

Örneğin , sen oturum seçerseniz Auth0 Google o zaman kullanılan hesabı kullanarak OIDC . Google ile başarılı bir şekilde kimlik doğrulaması yaptıktan ve Auth0'a bilgilerinize erişmesi için yetki verdiğinizde Google , kullanıcı ve gerçekleştirilen kimlik doğrulaması hakkında Auth0 bilgilerine geri gönderir . Bu bilgiler bir JSON Web Simgesinde (JWT) döndürülür . Bir Erişim Simgesi ve istenirse bir Kimlik Simgesi alırsınız. Jeton Türleri : Kaynak: OpenID Connect

Analoji :
Bir kuruluş kimlik amaçlı kimlik kartı kullanır ve çipleri içerir, Yetkilendirme ile birlikte Kampüs / Kapı / ODC erişimi gibi Çalışan ile ilgili ayrıntıları saklar . Kimlik kartı OIDC , Chip ise OAuth gibi davranır . daha fazla örnek ve form wiki

OpenID ve OAuth, kimlik doğrulama ve / veya yetkilendirme için her bir HTTP tabanlı protokoldür. Her ikisinin de kullanıcılara, kimlik doğrulama bilgileri veya istemcilere veya üçüncü taraflara örtülü izinler vermeden eylemler gerçekleştirmesine izin vermesi amaçlanmıştır. Benzer olsalar ve her ikisini birlikte kullanmak için önerilen standartlar olsa da, bunlar ayrı protokollerdir.

OpenID, birleşik kimlik doğrulaması için tasarlanmıştır. İstemci, herhangi bir sağlayıcıdan kimlik beyanı kabul eder (istemciler beyaz listeye veya kara liste sağlayıcılara ücretsizdir).

OAuth, yetkilendirilmiş yetkilendirme için tasarlanmıştır. Bir müşteri, kullanıcının adına işlem yapmayı kabul edeceği yetkilendirme simgelerini sağlayan bir sağlayıcıya kaydolur.

OAuth şu anda yetkilendirme için daha uygundur, çünkü kimlik doğrulamasından sonra daha fazla etkileşim protokolde yerleşiktir, ancak her iki protokol de gelişmektedir. OpenID ve uzantıları yetkilendirme için kullanılabilir ve OAuth kimlik doğrulama için kullanılabilir; bu işlem, işlem yapılmayan yetkilendirme olarak düşünülebilir.

Yorumlarda da belirtildiği gibi bu soruyu tekrar gözden geçirmenin mantıklı olduğuna inanıyorum, OpenID Connect'in tanıtımı daha fazla karışıklık getirmiş olabilir.

OpenID Connect, OpenID 1.0 / 2.0 gibi bir kimlik doğrulama protokolüdür, ancak aslında OAuth 2.0 üzerine inşa edilmiştir, bu nedenle kimlik doğrulama özellikleriyle birlikte yetkilendirme özellikleri alırsınız. İkisi arasındaki fark bu (nispeten yeni fakat önemli) makalede oldukça iyi açıklanmıştır: http://oauth.net/articles/authentication/

OpenID, OAuth, OpenID Connect arasındaki farkın açıklaması:

OAuth yetkilendirme için iken OpenID kimlik doğrulama protokolüdür. Kimlik doğrulama, konuştuğunuz adamın gerçekten iddia ettiği kişi olduğundan emin olmakla ilgilidir. Yetkilendirme, o adamın ne yapmasına izin verilmesi gerektiğine karar vermekle ilgilidir.

OpenID'de kimlik doğrulama yetkisi verilir: A sunucusu kullanıcı U'nun kimliğini doğrulamak ister, ancak U'nun kimlik bilgileri (örn. U'nun adı ve parolası) A'nın güvendiği başka bir sunucuya (en azından kullanıcıların kimliğini doğrulamak için güvenir) gönderilir. Gerçekten de, sunucu B U'nun gerçekten U olduğundan emin olur ve sonra A'ya "Tamam, bu gerçek U" der.

OAuth'ta yetkilendirme yetkilendirilir: A işletmesi, B işletmesinden A'nın erişim izni verilecek S sunucusuna gösterebileceği bir "erişim hakkı" alır; B böylece A'ya çok fazla güç vermeden geçici, özel erişim anahtarları verebilir. OAuth sunucusunu büyük bir otelin ana ustası olarak hayal edebilirsiniz; çalışanlara girmeleri gereken odaların kapılarını açan anahtarlar verir, ancak her anahtar sınırlıdır (tüm odalara erişim vermez); ayrıca, tuşlar birkaç saat sonra kendini imha eder.

Bir dereceye kadar, yetkilendirme, A varlığı B'den OAuth aracılığıyla bir erişim anahtarı alırsa ve bunu sunucu S'ye gösterirse, sunucu S erişim izni vermeden önce B kimlik doğrulaması A'yı çıkarabilir. tuşuna basın. Bu yüzden bazı insanlar OAuth'u OpenID kullanmaları gereken yerlerde kullanıyor. Bu şema aydınlatıcı olabilir veya olmayabilir; ancak bu sahte kimlik doğrulamanın her şeyden daha kafa karıştırıcı olduğunu düşünüyorum. OpenID Connect tam da bunu yapar: OAuth'u bir kimlik doğrulama protokolüne kötüye kullanır. Otel benzetmesinde: iddia edilen bir çalışanla karşılaşırsam ve o kişi bana odamı açan bir anahtar olduğunu gösterirse, o zaman anahtar ustasının ona bir anahtar vermeyeceği temelinde bunun gerçek bir çalışan olduğunu varsayalım. o olmasaydı odama açılır.

(kaynak)

OpenID Connect'in OpenID 2.0'dan farkı nedir?

OpenID Connect, OpenID 2.0 ile aynı görevlerin çoğunu gerçekleştirir, ancak bunu API dostu ve yerel ve mobil uygulamalar tarafından kullanılabilecek şekilde yapar. OpenID Connect, sağlam imzalama ve şifreleme için isteğe bağlı mekanizmaları tanımlar. OAuth 1.0a ve OpenID 2.0'ın entegrasyonu bir uzantı gerektirirken, OpenID Connect'te OAuth 2.0 özellikleri protokolün kendisine entegre edilmiştir.

(kaynak)

OpenID connect size bir erişim belirteci artı bir kimlik belirteci verir. Kimlik belirteci bir JWT'dir ve kimliği doğrulanmış kullanıcı hakkında bilgi içerir. Kimlik sağlayıcı tarafından imzalanır ve kimlik sağlayıcıya erişmeden okunabilir ve doğrulanabilir.

Buna ek olarak, OpenID connect, oauth2'nin seçime bıraktığı birkaç şeyi standartlaştırır. örneğin kapsamlar, uç nokta keşfi ve istemcilerin dinamik kaydı.

Bu, kullanıcının birden fazla kimlik sağlayıcısı arasında seçim yapmasını sağlayan kod yazmayı kolaylaştırır.

(kaynak)

Google'ın OAuth 2.0

Google'ın OAuth 2.0 API'ları, hem kimlik doğrulama hem de yetkilendirme için kullanılabilir. Bu belgede, OpenID Connect spesifikasyonuna uyan ve OpenID Sertifikalı OAuth 2.0 kimlik doğrulaması uygulamamız açıklanmaktadır. Google API'larına Erişmek için OAuth 2.0'ı Kullanma bölümünde bulunan belgeler de bu hizmet için geçerlidir. Bu protokolü etkileşimli olarak keşfetmek istiyorsanız Google OAuth 2.0 Oyun Alanı'nı öneririz .

(kaynak)

Sorunun cevabından çok bir uzantısı, ancak yukarıdaki harika teknik cevaplara bir bakış açısı ekleyebilir. Ben birkaç alanda deneyimli bir programcıyım, ama web için programlama için tam bir çaylak. Şimdi Zend Framework kullanarak web tabanlı bir uygulama oluşturmaya çalışıyorum.

Kesinlikle bir uygulamaya özgü temel kullanıcı adı / şifre kimlik doğrulama arayüzü uygulayacaktır, ancak artan sayıda kullanıcı için başka bir kullanıcı adı ve şifre düşüncesinin caydırıcı olduğunu kabul edin. Tam olarak sosyal ağ olmasa da, uygulamanın potansiyel kullanıcılarının çok büyük bir yüzdesinin zaten facebook veya twitter hesapları olduğunu biliyorum. Uygulama gerçekten bu sitelerden kullanıcının hesabıyla ilgili bilgilere erişmek istemiyor veya buna ihtiyaç duymuyor, sadece kullanıcının istemiyorsa yeni hesap kimlik bilgileri ayarlamasını istememe kolaylığı sunmak istiyor. İşlevsel açıdan bakıldığında, bu OpenID için bir poster alt öğesi gibi görünür. Ancak, ne facebook ne de twitter'ın OpenID sağlayıcıları olmadığı anlaşılıyor, ancak kullanıcı verilerine erişmek için OAuth kimlik doğrulamasını desteklemiyorlar.

İkisi ve nasıl farklılıklar hakkında okuduğum tüm makalelerde, Karl Anderson'ın yukarıdaki gözlemini görene kadar, "OAuth kimlik doğrulama için kullanılabilir, ki bu bir op-olmayan yetkilendirme olarak düşünülebilir" OAuth'un yapmak istediğim şey için yeterince iyi olduğuna dair açık bir onay gördüm.

Aslında, bu "cevabı" göndermeye gittiğimde, o sırada üye olamadım, kendimi belirleme seçeneklerinde bu sayfanın alt kısmında uzun ve sert görünüyordum. OpenID girişi kullanma veya bir tane yoksa bir tane alma seçeneği, ancak twitter veya facebook hakkında hiçbir şey, OAuth'un iş için yeterli olmadığını düşündürüyordu. Ama sonra başka bir pencere açtım ve stackoverflow için genel kayıt işlemini aradım - ve facebook ve twitter dahil olmak üzere bir dizi 3. taraf kimlik doğrulama seçeneği var. Sonunda tam olarak arkadaşlar listeme ve facebook'un kullanıcıları hakkında paylaşmaktan hoşlandığı başka bir şey için stackoverflow erişimi vermek istemediğim için google kimliğimi (bir OpenID olan) kullanmaya karar verdim.

Birisi, bu tür çoklu 3. bölüm yetkilendirme kurulumunu destekleme ve yetkilendirmeyi iptal eden veya üçüncü taraf sitelerine erişimini kaybeden kullanıcılarla nasıl başa çıkacağınız hakkında bilgi veya işaretçi gönderebilirse gerçekten harika olurdu. Ayrıca, burada kullanıcı adımın ayarlamak istersem temel kimlik doğrulamasıyla erişebileceğim benzersiz bir yığın akışı hesabını tanımladığı izlenimini edindim ve aynı hesaba diğer 3. taraf kimlik doğrulayıcıları aracılığıyla da eriştim (ör. Google, facebook veya twitter'da oturum açtıysam stackoverflow'a giriş yapın.). Bu site bunu yaptığı için, buradaki birisi muhtemelen konuyla ilgili oldukça iyi bir kavrayışa sahiptir. :-)

Üzgünüm, bu çok uzun ve bir cevaptan daha çok bir soruydu - ama Karl'ın sözleri, OAuth ve OpenID'deki iş parçacıklarının hacminin ortasında yayınlamak için en uygun yer gibi görünüyordu. Bunun için bulamadığım daha iyi bir yer varsa, önceden özür dilerim, denedim.

OpenID kim olduğunuzu kanıtlar.

OAuth , yetkilendiren tarafın sağladığı özelliklere erişim izni verir.

Şu anda OAuth 2.0 ve OpenID connect spec üzerinde çalışıyorum. İşte benim anlayışım: Daha önce onlar:

1. OpenID, Google'ın tescilli bir uygulamasıydı ve gazete web siteleri gibi google'ı kullanarak giriş yapabileceğiniz ve bir makaleye yorum yapabileceğiniz ve diğer kullanımları gibi üçüncü taraf uygulamalarına izin verdi. Yani aslında, gazete web sitesinde parola paylaşımı yok. Buraya bir tanım koyalım, işletme yaklaşımındaki bu yaklaşıma Federasyon denir. Federasyonda, kimlik doğrulaması yaptığınız ve yetkilendirdiğiniz bir sunucunuz (IDP, Kimlik Sağlayıcısı olarak adlandırılır) ve genellikle Kullanıcı kimlik bilgilerinin koruyucunuz vardır. işiniz olan istemci uygulamasına SP veya Servis Sağlayıcı denir. Aynı gazete web sitesi örneğine dönersek, gazete web sitesi burada SP ve Google IDP'dir. İşletmelerde bu sorun daha önce SAML kullanılarak çözülmüştü. o zaman XML yazılım endüstrisini yönetmek için kullanılır. Web servislerinden yapılandırmaya kadar, her şey XML'e gidiyordu, bu yüzden SAML'ye sahibiz,

2. OAuth: OAuth, bu tür tescilli yaklaşımlara bakan bir standart olarak ortaya çıktığını gördü ve bu yüzden standart olarak OAuth 1.o'ya sahiptik, ancak sadece yetkilendirmeyi ele aldık. Pek fazla insan fark etmedi ama bir şekilde almaya başladı. Daha sonra 2012'de OAuth 2.0 vardı. CTO'lar, Mimarlar, dünya Cloud computing'e doğru ilerlerken ve mobil cihazlara ve benzeri diğer cihazlara doğru hareket eden bilgisayar cihazlarıyla gerçekten dikkat etmeye başladı. OAuth, yazılım müşterilerinin bir şirkete IDP Hizmeti verebileceği ve satış gücü, SAP, vb. O halde OAuth 2.o'yu keşfedelim. Ohh, Google'ın bu süre zarfında OAuth'un aslında yapmadığını hissettiği önemli bir noktayı kaçırdı.

   a. OAuth 2.o, müşteri kaydının nasıl olacağını açıkça söylemez b. SP (Kaynak Sunucu) ve istemci uygulaması (veri sağlayan Analytics Sunucusu Kaynak Sunucu ve bu verileri İstemci gösteren uygulama gibi) arasındaki etkileşimden bahsetmez.

Teknik olarak burada verilen harika cevaplar var, kısa evrim perspektifi vermeyi düşündüm

OpenId, kimlik doğrulamasıyla başa çıkmak için OAuth kullanır.

Benzer şekilde, .NET'in Windows API'sine dayandığı gibi. Doğrudan Windows API'yı çağırabilirsiniz, ancak çok geniş, karmaşık ve yöntem argümanları çok geniş, kolayca hatalar / hatalar / güvenlik sorunu yapabilirsiniz.

OpenId / OAuth ile aynı. OpenId, Kimlik Doğrulamayı yönetmek için OAuth'a dayanır ancak belirli bir Jeton (Id_token), dijital imza ve belirli akışlar tanımlar.

Bu yorumda ele alındığı gibi, bu sorunun belirli bir yönünü ele almak istiyorum:

OAuth: bazı özelliklere erişim izni vermeden önce kimlik doğrulama yapılmalıdır, değil mi? Öyleyse OAuth = + hangi özelliklere sahip OpenId veriyor? - Hassan Makarov 21 Haziran, 1:57

Evet ve hayır. Cevap ince, bu yüzden bana katlan.

OAuth akışı bir hedef hizmetinin (olan OAuth sağlayıcı,) yönlendirir, bu ise bir belirteç istemci uygulaması / hizmete elle geri dönecek önce bu hizmetin ile kimlik doğrulaması gerekir muhtemelen. Ortaya çıkan simge daha sonra istemci uygulamasının belirli bir kullanıcı adına istekte bulunmasına izin verir.

Son cümlenin genelliğine dikkat edin: özellikle, " sizin adınıza" değil, " belirli bir kullanıcı adına" yazdım . "Belirli bir kullanıcının sahip olduğu bir kaynakla etkileşim kurma yeteneğine sahip olmanın" sizin ve hedef kaynakların sahibinin aynı olduğunu ima ettiğini "varsaymak yaygın bir hatadır.

Bu hatayı yapma.

Eğer müşteri gerektiği karşılığında ne elde edecek, (belki kullanıcı adı ve şifre veya SSL istemci certs veya başka araçlar tarafından, diyelim ki) OAuth sağlayıcısı ile kimlik doğrulaması doğru olsa değil mutlaka kimlik kanıtı olarak alınabilir. Bir örnek, başka bir kullanıcının kaynaklarına erişimin size (ve proxy tarafından OAuth istemcisine) devredildiği bir akış olabilir . Yetkilendirme, kimlik doğrulaması anlamına gelmez.

Kimlik doğrulamasını işlemek için, temelde OAuth 2.0 tarafından ayarlanan temelin üstünde başka bir katman olan OpenID Connect'e bakmak isteyeceksiniz. İşte (bence) OpenID Connect ile ilgili en dikkat çekici noktaları yakalayan bir alıntı ( https://oauth.net/articles/authentication/ adresinden ):

OpenID Connect, 2014'ün başında yayınlanan ve kullanıcı kimlik doğrulaması yapmak için OAuth 2.0'ı kullanmanın birlikte çalışabilir bir yolunu tanımlayan açık bir standarttır. Özünde, çok sayıda uzman tarafından denenmiş ve test edilmiş çikolatalı şekerleme için yaygın olarak yayınlanan bir reçetedir. Her potansiyel kimlik sağlayıcısına farklı bir protokol oluşturmak yerine, bir uygulama çalışmak istedikleri kadar sağlayıcıya bir protokol konuşabilir. Açık bir standart olduğundan, OpenID Connect herhangi bir kısıtlama veya fikri mülkiyet kaygısı olmadan herkes tarafından uygulanabilir.

OpenID Connect doğrudan OAuth 2.0 üzerine kuruludur ve çoğu durumda bir OAuth altyapısıyla birlikte (veya üstüne) dağıtılır. OpenID Connect, imzalanmış ve şifrelenmiş bilgileri farklı yerlerde taşımak için JSON Nesne İmzalama ve Şifreleme (JOSE) özellik paketini de kullanır. Aslında, JOSE özellikli OAuth 2.0 dağıtımı, tamamen uyumlu bir OpenID Connect sistemini tanımlamak için zaten uzun bir yoldur ve ikisi arasındaki delta nispeten küçüktür. Ancak bu delta büyük bir fark yaratıyor ve OpenID Connect, OAuth tabanına birkaç temel bileşen ekleyerek yukarıda tartışılan tuzakların çoğundan kaçınmayı başarıyor: [...]

Belge daha sonra (diğer şeylerin yanı sıra) simge kimliklerini ve bir UserInfo uç noktasını açıklamaya devam eder. Birincisi bir dizi hak talebinde bulunur (kime, jeton verildiğinde, vb.) Ve muhtemelen , yukarı akış hizmetini sormak zorunda kalmadan, yayınlanan bir ortak anahtar aracılığıyla jetonun gerçekliğini doğrulamak için bir imza sağlar ve ikincisi, örneğin standart bir şekilde kullanıcının adını / soyadını, e-postasını ve benzer bilgi parçalarını isteme (insanların OpenID Connect standartlaştırılmış şeylerinden önce kullandıkları OAuth'a yönelik geçici uzantıların aksine).

Her iki protokol de farklı nedenlerle oluşturulmuştur. OAuth, üçüncü taraflara kaynaklara erişme yetkisi vermek için oluşturuldu. OpenID, kimlik doğrulamasını merkezi olmayan hale getirmek için oluşturuldu. Bu web sitesi aşağıdakileri belirtir:

OAuth, bir son kullanıcının kimliğini doğrulamak ve üçüncü bir tarafa izin vermek için tasarlanmış bir protokoldür. Bu doğrulama bir jetonla sonuçlanır. Üçüncü taraf, bu belirteci kullanıcının adına kaynaklara erişmek için kullanabilir. Jetonların bir kapsamı vardır. Kapsam, bir kaynağın bir kullanıcı tarafından erişilebilir olup olmadığını doğrulamak için kullanılır

OpenID, merkezi olmayan kimlik doğrulama için kullanılan bir protokoldür. Kimlik doğrulaması kimlikle ilgilidir; Kullanıcıyı kurmak aslında iddia ettiği kişidir. Merkeziyetçilikten uzaklaştırılması, bu hizmetin korunması gereken kaynakların veya uygulamaların varlığından habersiz olduğu anlamına gelir. OAuth ve OpenID arasındaki temel fark budur.

OpenID Connect, OAuth 2.0 yetkilendirme protokolünü, kimlik doğrulama protokolü olarak kullanılacak şekilde genişletir, böylece OAuth kullanarak tek oturum açma yapabilirsiniz. OpenID Connect, istemcinin kullanıcının kimliğini doğrulamasını sağlayan bir güvenlik belirteci olan bir kimlik belirteci kavramını sunar

OAuth 2.0 bir Güvenlik protokolüdür. Bu bir Yetkilendirme protokolü OLMAYAN BİR DOĞRULADIR.

Tanıma göre kimlik doğrulaması iki soruyu cevaplar.

1. Kullanıcı kim?
2. Kullanıcı şu anda sistemde mevcut mu?

OAuth 2.0 aşağıdaki hibe türlerine sahiptir

• client_credentials: Bir uygulamanın başka bir uygulamayla etkileşim kurması ve birden çok kullanıcının verilerini değiştirmesi gerektiğinde.
• authorization_code: Kullanıcı, Yetkilendirme sunucusunu, istemcinin korumalı kaynağa erişmek için kullanabileceği bir erişim_konusu yayınlaması için yetkilendirir
• refresh_token: access_token sona erdiğinde, yeni bir access_token almak için yenileme jetonundan yararlanılabilir
• password: Kullanıcı, Yetkilendirme sunucusunu çağıran ve bir erişim_konusu alan bir istemciye oturum açma kimlik bilgilerini sağlar

Tüm 4'ün ortak bir yanı var: access_token, korumalı kaynağa erişmek için kullanılabilecek bir eser.

Access_token, bir "Kimlik Doğrulama" protokolünün cevaplaması gereken 2 soruya cevap vermez.

Bir örnekOauth 2.0'ı açıklamak için (kredi: OAuth 2 Eylemde, Manning yayınları)

Çikolata hakkında konuşalım. Çikolata, dondurma ve kek dahil olmak üzere çikolatadan birçok şekerleme yapabiliriz. Ancak, bunların hiçbiri çikolataya eşitlenemez, çünkü çikolata, ana bileşen gibi görünse bile, şekerleme yapmak için krem ​​ve ekmek gibi birçok başka bileşene ihtiyaç vardır. Benzer şekilde, OAuth 2.0 çikolata ve çerezler, TLS altyapısı, Kimlik Sağlayıcılar "Kimlik Doğrulama" işlevselliğini sağlamak için gereken diğer bileşenlerdir.

Kimlik Doğrulaması istiyorsanız, her kimlik doğrulama protokolünün yanıtlaması gereken soruları yanıtlayan access_token dışında bir "id_token" sağlayan OpenID Connect'e gidebilirsiniz.

OAuth, yetkilendirme üzerine kimlik doğrulaması oluşturur: Kullanıcı uygulamaya kimliklerine erişim yetkisi verir, bu da kimlik API'sinin bir tüketicisi olur, böylece istemciyi ilk etapta kimin yetkilendirdiğini öğrenir http://oauth.net/ haberler / doğrulama /