Azərbaycanca
Беларускі
Dansk
Deutsch
Española
Français
Indonesia
Italiana
日本語
Қазақ
Lietuvos
Nederlands
Português
Русский
සිංහල
แบบไทย
Türkçe
Українська
中國人
United State
Afrikaans
Bu maddenin içeriğinin Türkçeleştirilmesi veya doğrultusunda düzeltilmesi gerekmektedir. Bu maddedeki yazım ve noktalama yanlışları ya da anlatım bozuklukları giderilmelidir. (Yabancı sözcükler yerine Türkçe karşılıklarının kullanılması, karakter hatalarının düzeltilmesi, dilbilgisi hatalarının düzeltilmesi vs.) Düzenleme yapıldıktan sonra bu şablon kaldırılmalıdır. |
OAuth açık standartlı bir yetkilendirme protokolüdür, genellikle internet kullanıcıları tarafından kendi Google, Microsoft, Facebook, Twitter, One Network vb. hesaplarının şifrelerini açığa çıkarmadan web sitelerine erişmek için kullanılır. Genellikle OAuth kaynağın sahibi adına, kullanıcılara sunucu kaynakları için "güvenli temsili erişim" sağlıyor. Kaynak sahipleri için bir süreç başlatıyor. Bu süreçte kaynak sahiplerinin sunucu kaynaklarına herhangi bir kimlik paylaşımı olmadan üçüncü taraf erişim yetkisi sağlanıyor. Spesifik olarak Hypertext Transfer Protocol (HTTP) ile çalışması için tasarlanmış, OAuth temelde yetkili sunucu ile ve kaynak sahibinin onayı ile access tokenslerinin kullanıcılarına verilmesine izin veriyor. Daha sonra , kaynak sunucudaki korumalı kaynaklara erişmek için kullanıyor.
OAuth, OpenID ile bütünleşik ama ondan farklı bir servistir . OAuth aynı zamanda OATH'tan da farklıdır. OATH yetkilendirme için bir standart değil, kimlik doğrulama için referans bir mimaridir. Bununla birlikte kimlik doğrulama katmanı olan OIDC, OAuth 2.0 üzerine yapılandırıldığından beri OAuth direkt olarak OpenID Connect (OIDC) bağlıdır.
Tarihçe
OAuth Kasım 2006'da başladı, Blaine Cook Twitter OpenID uygulamasını geliştiriyordu. Bu sırada, Ma.gnolia OpenID'ye sahip üyelerinin Dashboard Widgets'leri yetkilendirerek kendi servisine erişebilmesi için bir çözüme ihtiyacı vardı. Magnolia'dan Cook, Chris Messina ve Larry Halff, David Recordon ile tanıştılar ve OpenID'yi Twitter and Ma.gnolia APIs ile kullanarak kimlik doğrulamayı devretmeyi görüştüler. API erişim yetkisi için open standards olmadığı sonucuna vardılar. [kaynak belirt]
Açık protokol için bir taslak öneri yazmaları için küçük grup ugulayıcıdan oluşan OAuth Discussion Group Nisan 2007 de oluşturuldu. Google'dan DeWitt Clinton OAuth projesini öğrendi ve projeye duyduğu ilgiyi üzerindeki çalışmaları destekleyerek gösterdi. Temmuz 2007'de ilk tanımlamayı yayınladılar. Eran Hammer joined and coordinated the many OAuth contributions creating a more formal specification. On December 4, 2007, the OAuth Core 1.0 final draft was released.
Kasım 2008 Minneapolis de yapılan 74. Internet Mühendisliği Görev Gücü (IETF) toplantısında düzenlenen OAuth BoF, protokolü IETF'e getirip daha standartlaştırma çalışmaları görüşmek için toplanıldı. Etkinlik katılımı yüksekti ve resmi olarak IETF içindeki OAuth çalışma grubunu kurmak için geniş bir destek geldi.
Nisan 2010 da OAuth 1.0 protokolü, yorumlar için bilgilendirme talebi olan RFC 5849 olarak yayımlandı.
31 Ağustos 2010 dan beri bütün third party Twitter uygulamaları için OAuth kullanımı mecburi oldu.
Ekim 2013'te RFC 6749 olarak OAuth 2.0 ve RFC 6750 olarak Bearer Token Usage yayımlandı. Bu iki standartta Requests for Comments takip ediliyor.
OAuth 2.0
OAuth 2.0, OAuth protokolünün bir sonraki versiyonu ve OAuth 1.0 ile uyumluluğu yok. OAuth 2.0 kullanıcı geliştirici kolaylığına, web uygulamalarına, masaüstü uygulamalarına, cep telefonlarına ve oturma odalarında kullanılan cihazlara spesifik yetki akışları sağlayarak odaklanmış oluyor. IETF OAuth çalışma grubu tarafından ilişkili RFC'ler ve spesifikasyonlar geliştiriliyor; Ekim 2012 de ana framework yayımlanıyor. ('a göre 2010 sonunda bitirilmesi bekleniyordu. Fakat OAuth hakkındaki çelişen incelemeler nedeniyle Hammer çalışma grubundan ayrıldı.)
Facebook Graph API sadece OAuth 2.0 protokolünü destekliyor.Google bütün API'leri için kimlik doğrulama mekanizması olarak önerilen OAuth 2.0'ı destekliyor. 2011'den bu yana da MicrosoftAPI'leri için OAuth 2.0'ı deneysel olarak desteklemeye başladı.
Ekim 2012 de OAuth 2.0 Framework and Bearer Token Usage yayımlandı. Diğer dokümanlar için OAuth çalışma grubunda çalışılmaya halen devam ediliyor.
Güvenlik
Nisan 2009 da 1.0 protokolündeki oturum odaklı güvenlik açığı duyuruldu. Bu açık OAuth Core 1.0 Section 6. Version 1.0'daki OAuth kimlik doğrulama akışını ("3-legged OAuth" olarak da bilinen) etkiliyor. Bu sebeple OAuth Core protokolü bu sorunu ortadan kaldırmak üzere görevlendiriliyor.
OAuth 2.0 de imzalama, şifreleme, channel binding veya kullanıcı doğrulama desteklenmiyor. OAuth 2.0 de gizlilik ve sunucunun kimlik doğrulaması için tamamen TLS'e güveniliyor.
OAuth 2.0 da uygulamaların maruz kaldığı birçok güvenlik açığı vardı. Güvenlik uzmanları tarafından protokol, yapısı gereği emniyetsiz olarak tanımlandı ve spesifikasyona asıl katkı sağlayan, uygulama hatalarının neredeyse kaçınılmaz olduğunu belirtti.
Ocak 2013'te IETF OAuth 2.0 için birkaç tane tehdit modelleri tanımladı. Bunların arasından biri "Open Redirector"; 2014 baharında, Wang Jing tarafından "Covert Redirect" adı altında tanıtıldı.
Muhtemelen OAuth'daki en yıkıcı güvenlik açığı yemleme zafiyeti oldu : OAuth kullanan her web sitesi görsel olarak (teknik olarak değil) kullanıcıların master kimliklerindeki kullanıcı adı ve şifresini soruyor, bu ise sıradan kullanıcıların saldırganın web sitesinde karşılarına çıkacak olan kimlik bilgilerini çalmak için görsel olarak taklit edilmiş yerlere master kimlik bilgilerini vermelerini engelliyor. İki faktörle yapılan kimlik doğrulama bu saldırıya engel olmuyor, çünkü yemleme sitesi onu da çalabilir (ve hemen kullanabilir).
Birlikte İşlemezlik
OAuth 2.0 tanımlanmış bir protokolden çok framework olduğu için, OAuth 2.0 uygulamaları diğer OAuth 2.0 uygulamaları ile doğal olarak birlikte işler olmaları çok olanaklı değildir. Daha ileri ayrıntılı inceleme ve spesifıkasyon birlikte işlerlik için gereklidir.
Kullanım
OAuth yetkilendirme mekanizması olarak güvenli RSS/ATOM feedlerini tüketmek için kulanılır. Kimlik doğrulaması gereken RSS/ATOM feedlerinin tüketimi her zaman bir sorun olmuştur. Örneğin; güvenilir Google Site içindeki RSS feed, Google Reader kullanılarak tüketilemez. Bunun yerine Google sitesindeki RSS feed'e ulaşması için three-legged OAuth Google Reader da yetki verme için kullanılabilir.
OAuth Kullanan OpenID vs. pseudo-authentication
OAuth kimlik doğrulama protokolü yerine bir yetki verme protokolüdür. Kimlik doğrulama metodu olarak sadece OAuth kullanılması pseudo-authentication olarak da anılabilir. Aşağıdaki çizimlerde OpenID (özellikle kimlik doğrulama protokolü olarak tasarlandı) ve kimlik doğrulama için OAuth protokolleri arasındaki farkları belirtilmiştir.
Her iki processteki bağlantı akışı da benzer:
- (çizimde yok) Kullanıcı uygulamadan kaynak veya site girişi için istek yapıyor.
- Site kullanıcının kimliğinin doğrulanmadığını görüyor. Kimlik sağlayıcıya bir istek formüle ediyor, bunu şifreliyor ve bunu kullanıcıya yönlendirilen URL içinde bir kısımda gönderiyor.
- Kullanıcının tarayıcısı, kimlik sağlayıcısı için yönlendirilen URL'in isteğini yapıyor, bu aynı zamanda uygulama isteği
- Eğer gerekli olursa kimlik sağlayıcı kullanıcının doğruluğunu ispatlıyor (muhtemelen bunu kullanıcılara, kullanıcı adı ve şifre soruyor)
- Kimlik sağlayıcı tatmin olduğunda kullanıcının doğruluğu yeterli bir şekilde kanıtlanmış oluyor. Uygulama isteği gönderme, yanıtı formüle etme ve bunu kullanıcıya geri gönderme bununla beraber yönlendirilen URL'in uygulamaya geri gönderilmesi işlemlerini yapıyor.
- Kimlik sağlayıcının cevabı ile beraber, kullanıcının tarayıcısı uygulamaya geri dönen yönlendirilmiş URL için istek yapıyor.
- Uygulama kimlik sağlayıcının cevabını deşifre ediyor ve gereğince işi sürdürüyor.
- (Sadece OAuth için) Uygulama, kimlik sağlayıcının servisine kullanıcı yerine direkt erişim sağlamak için cevabın içinde bulunan access token'ı kullanabilir.
En önemli farklılıkları OpenID'de kimlik doğrulama için kullanım gereklilikleri, kimlik sağlayıcının cevabı kimliğin beyanı; OAuth kullanım gerekliliğinde ise, kimlik sağlayıcı aynı zamanda bir API sağlayıcı ve kimlik sağlayıcının cevabı, kullanıcı yerine kimlik sağlayıcının bazı API 'lerine uygulamada halen devam eden erişimi verebilecek bir access tokendir. Access token uygulamanın, kimlik sağlayıcısına isteklerinde ekleyebileceği bir cüzdan anahtarı("valet key") olarak davranır. Bu ise kullanıcının API 'lere erişim için izni olduğunu kanıtlar.
Kimlik sağlayıcı genellikle (ama her zaman değil) kullanıcının kimlik doğruluğunu OAuth için access token verme işleminin bir parçası olarak ispatlıyor, bu da başarılı bir OAuth token erişim isteğini ayrı bir kimlik doğrulama metodu olabileceğini gösteriyor. Yine de OAuth bu kullanım senaryosu ile tasarlanmadığı için, böyle bir varsayımda bulunmak büyük güvenlik açıklarına sebep olabilir.
Karşıtlık
Temmuz 2012 de OAuh 2.0'daki baş yazar rolünden ayrılarak, IETF'deki çalışma grubundan da çekilip, ismini bu spesifikasyondan çıkardı. Hammer web ve kurumsal kültürler arasındaki bir çelişkinin üzerinde durarak, IETF'yi "tamamen kurumsal kullanım senaryoları" adı altında bir topluluk olduğunu anmıştır, bu "sadeliğe yeteneği yok" demektir. Hammer, Şu an sunulanın yetki verme protokolü için bir taslak olduğunu söylemiş ve "bu kurumsal bir yoldur", ekleyerek devam etmiştir "Danışmanlık servisleri ve entegrasyon çözümlerini satmak için yepyeni sınırdır."
OAuth 2.0 ve 1.0 karşılaştırılırken Hammer "daha karışık, daha az birlikte çalışabilir, daha kullanışsız, daha tamamlanmamış ve en önemlisi daha güvensiz" hale geldiğine parmak basıyor. Hammer, mimari değişimlerin 2.0 versiyonu için kullanıcılardan tokenlerin bağını kopardığını, bütün imzalama ve şifrelemenin protokol seviyesinde kaldırıldığını ve yetkilendirme işlemlerini zorlaştırmadan tokenler iptal edilmeyeceğinden dolayı sona erme süresi olan tokenlerin eklendiğini açıklıyor. Spesifikasyonda birçok öğe açıkça belirtilmemiş ve sınırlanmamış çünkü "bu çalışma grubunun doğası gereği, hiçbir konu tutulacak kadar ya da her bir uygulamada karar verilmesi için açık bırakılacak kadar küçük/önemsiz değildir."
Hammer daha sonra &Yet için kendi görüşlerini detaylandıran bir sunum veriyor.
David Recordon da daha sonradan kendi ismini spesifikasyonlardan belirli olmayan nedenlerden dolayı çıkarıyor. Dick Hardt editör olarak yerine devam ediyor ve framework Ekim 2012 de yayımlanıyor.
Ayrıca bakınız
- List of OAuth providers
- OpenID
- DataPortability
- Mozilla Persona
- SAML
- User-Managed Access
Kaynakça
- ^ "Arşivlenmiş kopya". 24 Nisan 2014 tarihinde kaynağından . Erişim tarihi: 9 Nisan 2016.
- ^ [[rfc:6749|http://tools.ietf.org/html/rfc6749 14 Mayıs 2016 tarihinde Wayback Machine sitesinde .]]
- ^ . 4 Aralık 2007. 25 Kasım 2015 tarihinde kaynağından arşivlendi. Erişim tarihi: 16 Ekim 2014.
- ^ Chris Crum (31 Ağustos 2010). . WebProNews.com. 4 Eylül 2010 tarihinde kaynağından arşivlendi. Erişim tarihi: 14 Mart 2011.
- ^ . . 2 Temmuz 2014 tarihinde kaynağından arşivlendi. Erişim tarihi: 8 Mayıs 2013.
- ^ Eran Hammer (15 Mayıs 2010). . 29 Mart 2014 tarihinde kaynağından arşivlendi. Erişim tarihi: 14 Mart 2011.
- ^ a b c . Eran Hammer. 28 Temmuz 2012. 9 Ağustos 2012 tarihinde kaynağından arşivlendi. Erişim tarihi: 16 Ağustos 2012.
- ^ . developers.facebook.com. 7 Ağustos 2012 tarihinde kaynağından arşivlendi. Erişim tarihi: 9 Nisan 2016.
- ^ . developers.google.com. 25 Mart 2015 tarihinde kaynağından arşivlendi. Erişim tarihi: 9 Nisan 2016.
- ^ Dare Obasanjo (4 Mayıs 2011). . windowsteamblog.com. 20 Ağustos 2012 tarihinde kaynağından arşivlendi. Erişim tarihi: 9 Nisan 2016.
- ^ a b "RFC6749 - The OAuth 2.0 Authorization Framework". Dick Hardt. Ekim 2012. 14 Mayıs 2016 tarihinde kaynağından . Erişim tarihi: 10 Ekim 2012.
- ^ "RFC6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage". Michael Jones, Dick Hardt. Ekim 2012. 1 Aralık 2015 tarihinde kaynağından . Erişim tarihi: 10 Ekim 2012.
- ^ . 23 Nisan 2009. 27 Mayıs 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 23 Nisan 2009.
- ^ . 30 Haziran 2009 tarihinde kaynağından arşivlendi. Erişim tarihi: 9 Nisan 2016.
- ^ . 20 Eylül 2010. 14 Mart 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 21 Eylül 2010.
- ^ . 3 Ağustos 2011. 17 Mayıs 2013 tarihinde kaynağından arşivlendi. Erişim tarihi: 3 Ağustos 2011.
- ^ . 12 Şubat 2013. 23 Nisan 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 6 Mart 2013.
- ^ "Re: OAUTH-WG OAuth2 attack surface..." 28 Şubat 2013. 21 Mayıs 2016 tarihinde kaynağından . Erişim tarihi: 6 Mart 2013.
- ^ . 1 Mart 2013. 30 Nisan 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 6 Mart 2013.
- ^ OAuth 2.0 Threat Model and Security Considerations.
- ^ . OAuth. 4 Mayıs 2014. 21 Kasım 2015 tarihinde kaynağından arşivlendi. Erişim tarihi: 10 Kasım 2014.
- ^ "Serious security flaw in OAuth, OpenID discovered". CNET. 2 Mayıs 2014. 2 Kasım 2015 tarihinde kaynağından . Erişim tarihi: 10 Kasım 2014.
- ^ "Math student detects OAuth, OpenID security vulnerability". Phys.org. 3 Mayıs 2014. 6 Kasım 2015 tarihinde kaynağından . Erişim tarihi: 11 Kasım 2014.
- ^ . Tetraph. 1 Mayıs 2014. 10 Mart 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 10 Kasım 2014.
- ^ "Arşivlenmiş kopya". 20 Nisan 2016 tarihinde kaynağından . Erişim tarihi: 9 Nisan 2016.
- ^ Dick Hardt, ed.
- ^ . OAuth Community Site. 19 Kasım 2015 tarihinde kaynağından arşivlendi. Erişim tarihi: 8 Mart 2016.
- ^ "OAuth 2.0 - Looking Back and Moving On". Eran Hammer. 23 Ekim 2012. 25 Nisan 2016 tarihinde kaynağından . Erişim tarihi: 22 Kasım 2012.
Dış bağlantılar
- The OAuth 1.0 Protocol (RFC 5849)
- The OAuth 2.0 Authorization Framework (RFC 6749)
- The OAuth 2.0 Authorization Framework: Bearer Token Usage (RFC 6750)
- "OAuth.net". 4 Aralık 2015 tarihinde kaynağından . Erişim tarihi: 9 Nisan 2016.
- "OAuth Working Group's Mailing List". 21 Nisan 2016 tarihinde kaynağından . Erişim tarihi: 9 Nisan 2016.
- "OAuth Code Library Support". 3 Haziran 2013 tarihinde kaynağından . Erişim tarihi: 9 Nisan 2016. on Google Groups
- . Hueniverse. 27 Kasım 2015 tarihinde kaynağından arşivlendi. Erişim tarihi: 9 Nisan 2016.Hueniverse.
- "Google OAuth & Federated Login Research". 8 Mart 2016 tarihinde kaynağından . Erişim tarihi: 9 Nisan 2016.
- . 30 Nisan 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 9 Nisan 2016..
- . 26 Nisan 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 9 Nisan 2016.
- . 20 Nisan 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 9 Nisan 2016.
- oAuth End points cheat sheet 31 Mart 2016 tarihinde Wayback Machine sitesinde .
wikipedia, wiki, viki, vikipedia, oku, kitap, kütüphane, kütübhane, ara, ara bul, bul, herşey, ne arasanız burada,hikayeler, makale, kitaplar, öğren, wiki, bilgi, tarih, yukle, izle, telefon için, turk, türk, türkçe, turkce, nasıl yapılır, ne demek, nasıl, yapmak, yapılır, indir, ücretsiz, ücretsiz indir, bedava, bedava indir, mp3, video, mp4, 3gp, jpg, jpeg, gif, png, resim, müzik, şarkı, film, film, oyun, oyunlar, mobil, cep telefonu, telefon, android, ios, apple, samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, pc, web, computer, bilgisayar
Bu maddenin iceriginin Turkcelestirilmesi veya Turkce dilbilgisi ve kurallari dogrultusunda duzeltilmesi gerekmektedir Bu maddedeki yazim ve noktalama yanlislari ya da anlatim bozukluklari giderilmelidir Yabanci sozcukler yerine Turkce karsiliklarinin kullanilmasi karakter hatalarinin duzeltilmesi dilbilgisi hatalarinin duzeltilmesi vs Duzenleme yapildiktan sonra bu sablon kaldirilmalidir OAuthacik standartli bir yetkilendirme protokoludur genellikle internet kullanicilari tarafindan kendi Google Microsoft Facebook Twitter One Network vb hesaplarinin sifrelerini aciga cikarmadan web sitelerine erismek icin kullanilir Genellikle OAuth kaynagin sahibi adina kullanicilara sunucu kaynaklari icin guvenli temsili erisim sagliyor Kaynak sahipleri icin bir surec baslatiyor Bu surecte kaynak sahiplerinin sunucu kaynaklarina herhangi bir kimlik paylasimi olmadan ucuncu taraf erisim yetkisi saglaniyor Spesifik olarak Hypertext Transfer Protocol HTTP ile calismasi icin tasarlanmis OAuth temelde yetkili sunucu ile ve kaynak sahibinin onayi ile access tokenslerinin kullanicilarina verilmesine izin veriyor Daha sonra kaynak sunucudaki korumali kaynaklara erismek icin kullaniyor OAuth logo Chris Messina tarafindan tasarlandi OAuth OpenID ile butunlesik ama ondan farkli bir servistir OAuth ayni zamanda OATH tan da farklidir OATH yetkilendirme icin bir standart degil kimlik dogrulama icin referans bir mimaridir Bununla birlikte kimlik dogrulama katmani olan OIDC OAuth 2 0 uzerine yapilandirildigindan beri OAuth direkt olarak OpenID Connect OIDC baglidir TarihceOAuth Kasim 2006 da basladi Blaine Cook Twitter OpenID uygulamasini gelistiriyordu Bu sirada Ma gnolia OpenID ye sahip uyelerinin Dashboard Widgets leri yetkilendirerek kendi servisine erisebilmesi icin bir cozume ihtiyaci vardi Magnolia dan Cook Chris Messina ve Larry Halff David Recordon ile tanistilar ve OpenID yi Twitter and Ma gnolia APIs ile kullanarak kimlik dogrulamayi devretmeyi gorustuler API erisim yetkisi icin open standards olmadigi sonucuna vardilar kaynak belirt Acik protokol icin bir taslak oneri yazmalari icin kucuk grup ugulayicidan olusan OAuth Discussion Group Nisan 2007 de olusturuldu Google dan DeWitt Clinton OAuth projesini ogrendi ve projeye duydugu ilgiyi uzerindeki calismalari destekleyerek gosterdi Temmuz 2007 de ilk tanimlamayi yayinladilar Eran Hammer joined and coordinated the many OAuth contributions creating a more formal specification On December 4 2007 the OAuth Core 1 0 final draft was released Kasim 2008 Minneapolis de yapilan 74 Internet Muhendisligi Gorev Gucu IETF toplantisinda duzenlenen OAuth BoF protokolu IETF e getirip daha standartlastirma calismalari gorusmek icin toplanildi Etkinlik katilimi yuksekti ve resmi olarak IETF icindeki OAuth calisma grubunu kurmak icin genis bir destek geldi Nisan 2010 da OAuth 1 0 protokolu yorumlar icin bilgilendirme talebi olan RFC 5849 olarak yayimlandi 31 Agustos 2010 dan beri butun third party Twitter uygulamalari icin OAuth kullanimi mecburi oldu Ekim 2013 te RFC 6749 olarak OAuth 2 0 ve RFC 6750 olarak Bearer Token Usage yayimlandi Bu iki standartta Requests for Comments takip ediliyor OAuth 2 0OAuth 2 0 OAuth protokolunun bir sonraki versiyonu ve OAuth 1 0 ile uyumlulugu yok OAuth 2 0 kullanici gelistirici kolayligina web uygulamalarina masaustu uygulamalarina cep telefonlarina ve oturma odalarinda kullanilan cihazlara spesifik yetki akislari saglayarak odaklanmis oluyor IETF OAuth calisma grubu tarafindan iliskili RFC ler ve spesifikasyonlar gelistiriliyor Ekim 2012 de ana framework yayimlaniyor a gore 2010 sonunda bitirilmesi bekleniyordu Fakat OAuth hakkindaki celisen incelemeler nedeniyle Hammer calisma grubundan ayrildi Facebook Graph API sadece OAuth 2 0 protokolunu destekliyor Google butun API leri icin kimlik dogrulama mekanizmasi olarak onerilen OAuth 2 0 i destekliyor 2011 den bu yana da MicrosoftAPI leri icin OAuth 2 0 i deneysel olarak desteklemeye basladi Ekim 2012 de OAuth 2 0 Framework and Bearer Token Usage yayimlandi Diger dokumanlar icin OAuth calisma grubunda calisilmaya halen devam ediliyor GuvenlikNisan 2009 da 1 0 protokolundeki oturum odakli guvenlik acigi duyuruldu Bu acik OAuth Core 1 0 Section 6 Version 1 0 daki OAuth kimlik dogrulama akisini 3 legged OAuth olarak da bilinen etkiliyor Bu sebeple OAuth Core protokolu bu sorunu ortadan kaldirmak uzere gorevlendiriliyor OAuth 2 0 de imzalama sifreleme channel binding veya kullanici dogrulama desteklenmiyor OAuth 2 0 de gizlilik ve sunucunun kimlik dogrulamasi icin tamamen TLS e guveniliyor OAuth 2 0 da uygulamalarin maruz kaldigi bircok guvenlik acigi vardi Guvenlik uzmanlari tarafindan protokol yapisi geregi emniyetsiz olarak tanimlandi ve spesifikasyona asil katki saglayan uygulama hatalarinin neredeyse kacinilmaz oldugunu belirtti Ocak 2013 te IETF OAuth 2 0 icin birkac tane tehdit modelleri tanimladi Bunlarin arasindan biri Open Redirector 2014 baharinda Wang Jing tarafindan Covert Redirect adi altinda tanitildi Muhtemelen OAuth daki en yikici guvenlik acigi yemleme zafiyeti oldu OAuth kullanan her web sitesi gorsel olarak teknik olarak degil kullanicilarin master kimliklerindeki kullanici adi ve sifresini soruyor bu ise siradan kullanicilarin saldirganin web sitesinde karsilarina cikacak olan kimlik bilgilerini calmak icin gorsel olarak taklit edilmis yerlere master kimlik bilgilerini vermelerini engelliyor Iki faktorle yapilan kimlik dogrulama bu saldiriya engel olmuyor cunku yemleme sitesi onu da calabilir ve hemen kullanabilir Birlikte IslemezlikOAuth 2 0 tanimlanmis bir protokolden cok framework oldugu icin OAuth 2 0 uygulamalari diger OAuth 2 0 uygulamalari ile dogal olarak birlikte isler olmalari cok olanakli degildir Daha ileri ayrintili inceleme ve spesifikasyon birlikte islerlik icin gereklidir KullanimOAuth yetkilendirme mekanizmasi olarak guvenli RSS ATOM feedlerini tuketmek icin kulanilir Kimlik dogrulamasi gereken RSS ATOM feedlerinin tuketimi her zaman bir sorun olmustur Ornegin guvenilir Google Site icindeki RSS feed Google Reader kullanilarak tuketilemez Bunun yerine Google sitesindeki RSS feed e ulasmasi icin three legged OAuth Google Reader da yetki verme icin kullanilabilir OAuth Kullanan OpenID vs pseudo authenticationOAuth kimlik dogrulama protokolu yerine bir yetki verme protokoludur Kimlik dogrulama metodu olarak sadece OAuth kullanilmasi pseudo authentication olarak da anilabilir Asagidaki cizimlerde OpenID ozellikle kimlik dogrulama protokolu olarak tasarlandi ve kimlik dogrulama icin OAuth protokolleri arasindaki farklari belirtilmistir Her iki processteki baglanti akisi da benzer cizimde yok Kullanici uygulamadan kaynak veya site girisi icin istek yapiyor Site kullanicinin kimliginin dogrulanmadigini goruyor Kimlik saglayiciya bir istek formule ediyor bunu sifreliyor ve bunu kullaniciya yonlendirilen URL icinde bir kisimda gonderiyor Kullanicinin tarayicisi kimlik saglayicisi icin yonlendirilen URL in istegini yapiyor bu ayni zamanda uygulama istegi Eger gerekli olursa kimlik saglayici kullanicinin dogrulugunu ispatliyor muhtemelen bunu kullanicilara kullanici adi ve sifre soruyor Kimlik saglayici tatmin oldugunda kullanicinin dogrulugu yeterli bir sekilde kanitlanmis oluyor Uygulama istegi gonderme yaniti formule etme ve bunu kullaniciya geri gonderme bununla beraber yonlendirilen URL in uygulamaya geri gonderilmesi islemlerini yapiyor Kimlik saglayicinin cevabi ile beraber kullanicinin tarayicisi uygulamaya geri donen yonlendirilmis URL icin istek yapiyor Uygulama kimlik saglayicinin cevabini desifre ediyor ve geregince isi surduruyor Sadece OAuth icin Uygulama kimlik saglayicinin servisine kullanici yerine direkt erisim saglamak icin cevabin icinde bulunan access token i kullanabilir En onemli farkliliklari OpenID de kimlik dogrulama icin kullanim gereklilikleri kimlik saglayicinin cevabi kimligin beyani OAuth kullanim gerekliliginde ise kimlik saglayici ayni zamanda bir API saglayici ve kimlik saglayicinin cevabi kullanici yerine kimlik saglayicinin bazi API lerine uygulamada halen devam eden erisimi verebilecek bir access tokendir Access token uygulamanin kimlik saglayicisina isteklerinde ekleyebilecegi bir cuzdan anahtari valet key olarak davranir Bu ise kullanicinin API lere erisim icin izni oldugunu kanitlar Kimlik saglayici genellikle ama her zaman degil kullanicinin kimlik dogrulugunu OAuth icin access token verme isleminin bir parcasi olarak ispatliyor bu da basarili bir OAuth token erisim istegini ayri bir kimlik dogrulama metodu olabilecegini gosteriyor Yine de OAuth bu kullanim senaryosu ile tasarlanmadigi icin boyle bir varsayimda bulunmak buyuk guvenlik aciklarina sebep olabilir KarsitlikTemmuz 2012 de OAuh 2 0 daki bas yazar rolunden ayrilarak IETF deki calisma grubundan da cekilip ismini bu spesifikasyondan cikardi Hammer web ve kurumsal kulturler arasindaki bir celiskinin uzerinde durarak IETF yi tamamen kurumsal kullanim senaryolari adi altinda bir topluluk oldugunu anmistir bu sadelige yetenegi yok demektir Hammer Su an sunulanin yetki verme protokolu icin bir taslak oldugunu soylemis ve bu kurumsal bir yoldur ekleyerek devam etmistir Danismanlik servisleri ve entegrasyon cozumlerini satmak icin yepyeni sinirdir OAuth 2 0 ve 1 0 karsilastirilirken Hammer daha karisik daha az birlikte calisabilir daha kullanissiz daha tamamlanmamis ve en onemlisi daha guvensiz hale geldigine parmak basiyor Hammer mimari degisimlerin 2 0 versiyonu icin kullanicilardan tokenlerin bagini kopardigini butun imzalama ve sifrelemenin protokol seviyesinde kaldirildigini ve yetkilendirme islemlerini zorlastirmadan tokenler iptal edilmeyeceginden dolayi sona erme suresi olan tokenlerin eklendigini acikliyor Spesifikasyonda bircok oge acikca belirtilmemis ve sinirlanmamis cunku bu calisma grubunun dogasi geregi hicbir konu tutulacak kadar ya da her bir uygulamada karar verilmesi icin acik birakilacak kadar kucuk onemsiz degildir Hammer daha sonra amp Yet icin kendi goruslerini detaylandiran bir sunum veriyor David Recordon da daha sonradan kendi ismini spesifikasyonlardan belirli olmayan nedenlerden dolayi cikariyor Dick Hardt editor olarak yerine devam ediyor ve framework Ekim 2012 de yayimlaniyor Ayrica bakinizList of OAuth providers OpenID DataPortability Mozilla Persona SAML User Managed AccessKaynakca Arsivlenmis kopya 24 Nisan 2014 tarihinde kaynagindan Erisim tarihi 9 Nisan 2016 rfc 6749 http tools ietf org html rfc6749 14 Mayis 2016 tarihinde Wayback Machine sitesinde 4 Aralik 2007 25 Kasim 2015 tarihinde kaynagindan arsivlendi Erisim tarihi 16 Ekim 2014 Chris Crum 31 Agustos 2010 WebProNews com 4 Eylul 2010 tarihinde kaynagindan arsivlendi Erisim tarihi 14 Mart 2011 2 Temmuz 2014 tarihinde kaynagindan arsivlendi Erisim tarihi 8 Mayis 2013 Eran Hammer 15 Mayis 2010 29 Mart 2014 tarihinde kaynagindan arsivlendi Erisim tarihi 14 Mart 2011 a b c Eran Hammer 28 Temmuz 2012 9 Agustos 2012 tarihinde kaynagindan arsivlendi Erisim tarihi 16 Agustos 2012 developers facebook com 7 Agustos 2012 tarihinde kaynagindan arsivlendi Erisim tarihi 9 Nisan 2016 developers google com 25 Mart 2015 tarihinde kaynagindan arsivlendi Erisim tarihi 9 Nisan 2016 Dare Obasanjo 4 Mayis 2011 windowsteamblog com 20 Agustos 2012 tarihinde kaynagindan arsivlendi Erisim tarihi 9 Nisan 2016 a b RFC6749 The OAuth 2 0 Authorization Framework Dick Hardt Ekim 2012 14 Mayis 2016 tarihinde kaynagindan Erisim tarihi 10 Ekim 2012 RFC6750 The OAuth 2 0 Authorization Framework Bearer Token Usage Michael Jones Dick Hardt Ekim 2012 1 Aralik 2015 tarihinde kaynagindan Erisim tarihi 10 Ekim 2012 23 Nisan 2009 27 Mayis 2016 tarihinde kaynagindan arsivlendi Erisim tarihi 23 Nisan 2009 30 Haziran 2009 tarihinde kaynagindan arsivlendi Erisim tarihi 9 Nisan 2016 20 Eylul 2010 14 Mart 2016 tarihinde kaynagindan arsivlendi Erisim tarihi 21 Eylul 2010 3 Agustos 2011 17 Mayis 2013 tarihinde kaynagindan arsivlendi Erisim tarihi 3 Agustos 2011 12 Subat 2013 23 Nisan 2016 tarihinde kaynagindan arsivlendi Erisim tarihi 6 Mart 2013 Re OAUTH WG OAuth2 attack surface 28 Subat 2013 21 Mayis 2016 tarihinde kaynagindan Erisim tarihi 6 Mart 2013 1 Mart 2013 30 Nisan 2016 tarihinde kaynagindan arsivlendi Erisim tarihi 6 Mart 2013 OAuth 2 0 Threat Model and Security Considerations OAuth 4 Mayis 2014 21 Kasim 2015 tarihinde kaynagindan arsivlendi Erisim tarihi 10 Kasim 2014 Serious security flaw in OAuth OpenID discovered CNET 2 Mayis 2014 2 Kasim 2015 tarihinde kaynagindan Erisim tarihi 10 Kasim 2014 Math student detects OAuth OpenID security vulnerability Phys org 3 Mayis 2014 6 Kasim 2015 tarihinde kaynagindan Erisim tarihi 11 Kasim 2014 Tetraph 1 Mayis 2014 10 Mart 2016 tarihinde kaynagindan arsivlendi Erisim tarihi 10 Kasim 2014 Arsivlenmis kopya 20 Nisan 2016 tarihinde kaynagindan Erisim tarihi 9 Nisan 2016 Dick Hardt ed OAuth Community Site 19 Kasim 2015 tarihinde kaynagindan arsivlendi Erisim tarihi 8 Mart 2016 OAuth 2 0 Looking Back and Moving On Eran Hammer 23 Ekim 2012 25 Nisan 2016 tarihinde kaynagindan Erisim tarihi 22 Kasim 2012 Dis baglantilarThe OAuth 1 0 Protocol RFC 5849 The OAuth 2 0 Authorization Framework RFC 6749 The OAuth 2 0 Authorization Framework Bearer Token Usage RFC 6750 OAuth net 4 Aralik 2015 tarihinde kaynagindan Erisim tarihi 9 Nisan 2016 OAuth Working Group s Mailing List 21 Nisan 2016 tarihinde kaynagindan Erisim tarihi 9 Nisan 2016 OAuth Code Library Support 3 Haziran 2013 tarihinde kaynagindan Erisim tarihi 9 Nisan 2016 on Google Groups Hueniverse 27 Kasim 2015 tarihinde kaynagindan arsivlendi Erisim tarihi 9 Nisan 2016 Hueniverse Google OAuth amp Federated Login Research 8 Mart 2016 tarihinde kaynagindan Erisim tarihi 9 Nisan 2016 30 Nisan 2016 tarihinde kaynagindan arsivlendi Erisim tarihi 9 Nisan 2016 26 Nisan 2016 tarihinde kaynagindan arsivlendi Erisim tarihi 9 Nisan 2016 20 Nisan 2016 tarihinde kaynagindan arsivlendi Erisim tarihi 9 Nisan 2016 oAuth End points cheat sheet 31 Mart 2016 tarihinde Wayback Machine sitesinde