OAuth

Vikipedi, özgür ansiklopedi
Şuraya atla: kullan, ara
OAuth logo, Chris Messina tarafından tasarlandı

OAuth açık standartlı bir yetkilendirme protokolüdür, genellikle internet kullanıcıları tarafından kendi Google, Microsoft, Facebook, Twitter, One Network v.b. hesaplarının şifrelerini açığa çıkarmadan third party web sitelerine erişmek için kullanılır.[1] 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 third-party kullanıcılarına verilmesine izin veriyor. Daha sonra third party, kaynak sunucudaki korumalı kaynaklara erişmek için access tokenlarını kullanıyor.[2]

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[değiştir | kaynağı değiştir]

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 veOpenID'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 prolesini öğrendi ve projeye duyduğu ilgiyi üzerindeki eforu destekleyerek gösterdi. In July 2007, the team drafted an initial specification. 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.[3]

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.[4]

Ekim 2013 de 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[değiştir | kaynağı değiştir]

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;[5] Ekim 2012 de ana framework yayımlanıyor.(Eran Hammer'a göre 2010 sonunda bitirilmesi bekleniyordu.[6] Fakat OAuth hakkındaki çelişen incelemeler nedeniyle Hammer çalışma grubundan ayrıldı.[7])

Facebook Graph API sadece OAuth 2.0 protokolünü destekliyor.[8] Google bütün API'leri için kimlik doğrulama mekanizması olarak önerilen OAuth 2.0'ı destekliyor.[9] 2011'den bu yana da Microsoft[10] API'leri için OAuth 2.0'ı deneysel olarak desteklemeye başladı.

Ekim 2012 de OAuth 2.0 Framework [11] and Bearer Token Usage[12] yayımlandı. Diğer dokümanlar için OAuth çalışma grubunda çalışılmaya halen devam ediliyor.

Güvenlik[değiştir | kaynağı değiştir]

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" olarakta bilinen) etkiliyor.[13] Bu sebeple OAuth Core protokolü bu sorunu ortadan kaldırmak üzere görevlendiriliyor.[14]

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.[15][16]

OAuth 2.0 da uygulamaların maruz kaldığı birçok güvenlik açığı vardı.[17] 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.[18][19]

Ocak 2013 de IETF OAuth 2.0 için birkaç tane tehdit modelleri tanımladı.[20] Bunların arasından biri "Open Redirector"; 2014 baharında, Wang Jing tarafından "Covert Redirect" adı altında tanıtıldı.[21][22][23][24]

Muhtemelen OAuth'daki en yıkıcı güvenlik açığı yemleme zafiyeti oldu :[25] 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[değiştir | kaynağı değiştir]

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.[26]

Kullanım[değiştir | kaynağı değiştir]

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[değiştir | kaynağı değiştir]

OAuth kimlik doğrulama protokolü yerine bir yetki verme protokolüdür. Kimlik doğrulama metodu olarak sadece OAuth kullanılması pseudo-authentication olarakda 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:

  1. (çizimde yok) Kullanıcı uygulamadan kaynak veya site girişi için istek yapıyor.
  2. 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.
  3. 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
  4. 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) 
  5. 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.
  6. 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.
  7. Uygulama kimlik sağlayıcının cevabını deşifre ediyor ve gereğince işi sürdürüyor.
  8. (Sadece OAuth için) Uygulama, kimlik sağlayıcının servisine kullanıcı yerine direk 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 herzaman 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.[27]

OpenID vs. pseudo-authentication using OAuth

Karşıtlık[değiştir | kaynağı değiştir]

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."[7]

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."[7]

Hammer daha sonra &Yet için kendi görüşlerini detaylandıran bir sunum veriyor.[28]

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.[11]

Ayrıca bakınız[değiştir | kaynağı değiştir]

  • List of OAuth providers
  • OpenID
  • DataPortability
  • Mozilla Persona
  • SAML
  • User-Managed Access

Kaynakça[değiştir | kaynağı değiştir]

  1. ^ http://lifehacker.com/5918086/understanding-oauth-what-happens-when-you-log-into-a-site-with-google-twitter-or-facebook
  2. ^ http://tools.ietf.org/html/rfc6749
  3. ^ "OAuth Core 1.0". December 4, 2007. 25 Kasım 2015 tarihinde kaynağından arşivlendi. http://web.archive.org/web/20151125184848/http://oauth.net:80/core/1.0/. Erişim tarihi: October 16, 2014. 
  4. ^ Chris Crum (2010-08-31). "Twitter Apps Go OAuth Today". WebProNews.com. 4 Eylül 2010 tarihinde kaynağından arşivlendi. http://web.archive.org/web/20100904044407/http://www.webpronews.com:80/topnews/2010/08/31/twitter-apps-go-oauth-today. Erişim tarihi: 2011-03-14. 
  5. ^ "Web Authorization Protocol (oauth)". IETF. 2 Temmuz 2014 tarihinde kaynağından arşivlendi. http://web.archive.org/web/20140702044119/http://datatracker.ietf.org/wg/oauth/. Erişim tarihi: May 8, 2013. 
  6. ^ Eran Hammer (2010-05-15). "Introducing OAuth 2.0". 29 Mart 2014 tarihinde kaynağından arşivlendi. http://web.archive.org/web/20140329032033/http://hueniverse.com/2010/05/introducing-oauth-2-0/. Erişim tarihi: 2011-03-14. 
  7. 7,0 7,1 7,2 "OAuth 2.0 and the Road to Hell". Eran Hammer. 28 July 2012. 9 Ağustos 2012 tarihinde kaynağından arşivlendi. http://web.archive.org/web/20120809004016/http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/. Erişim tarihi: 16 August 2012. 
  8. ^ "Authentication - Facebook Developers". developers.facebook.com. 7 Ağustos 2012 tarihinde kaynağından arşivlendi. http://web.archive.org/web/20120807203619/https://developers.facebook.com/docs/authentication/. 
  9. ^ "Google Accounts Authentication and Authorization". developers.google.com. 25 Mart 2015 tarihinde kaynağından arşivlendi. http://web.archive.org/web/20150325231030/https://developers.google.com/accounts/docs/GettingStarted. 
  10. ^ Dare Obasanjo (2011-05-04). "Announcing Support for OAuth 2.0". windowsteamblog.com. 20 Ağustos 2012 tarihinde kaynağından arşivlendi. http://web.archive.org/web/20120820142933/http://windowsteamblog.com:80/windows_live/b/developer/archive/2011/05/04/announcing-support-for-oauth-2-0.aspx. 
  11. 11,0 11,1 "RFC6749 - The OAuth 2.0 Authorization Framework". Dick Hardt. October 2012. 14 Mayıs 2016 tarihinde kaynağından arşivlendi. http://web.archive.org/web/20160514070302/http://tools.ietf.org/html/rfc6749. Erişim tarihi: 10 October 2012. 
  12. ^ "RFC6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage". Michael Jones, Dick Hardt. October 2012. 1 Aralık 2015 tarihinde kaynağından arşivlendi. http://web.archive.org/web/20151201005459/http://tools.ietf.org:80/html/rfc6750. Erişim tarihi: 10 October 2012. 
  13. ^ "OAuth Security Advisory: 2009.1". 2009-04-23. 27 Mayıs 2016 tarihinde kaynağından arşivlendi. http://web.archive.org/web/20160527002938/http://oauth.net/advisories/2009-1/. Erişim tarihi: 2009-04-23. 
  14. ^ OAuth Core 1.0a
  15. ^ "Is OAuth 2.0 Bad for the Web?". 2010-09-20. 14 Mart 2016 tarihinde kaynağından arşivlendi. http://web.archive.org/web/20160314163844/http://www.infoq.com/news/2010/09/oauth2-bad-for-web. Erişim tarihi: 2010-09-21. 
  16. ^ "an unwarranted bashing of Twitter’s oAuth". 2011-08-03. 17 Mayıs 2013 tarihinde kaynağından arşivlendi. http://web.archive.org/web/20130517101748/http://benlog.com/articles/2010/09/02/an-unwarranted-bashing-of-twitters-oauth/. Erişim tarihi: 2011-08-03. 
  17. ^ "Hacking Facebook with OAuth 2.0 and Chrome". 2013-02-12. 23 Nisan 2016 tarihinde kaynağından arşivlendi. http://web.archive.org/web/20160423083324/http://homakov.blogspot.co.uk/2013/02/hacking-facebook-with-oauth2-and-chrome.html. Erişim tarihi: 2013-03-06. 
  18. ^ "Re: OAUTH-WG OAuth2 attack surface....". 2013-02-28. 21 Mayıs 2016 tarihinde kaynağından arşivlendi. http://web.archive.org/web/20160521191640/http://www.ietf.org/mail-archive/web/oauth/current/msg11076.html. Erişim tarihi: 2013-03-06. 
  19. ^ "OAuth1, OAuth2, OAuth...?". 2013-03-01. 30 Nisan 2016 tarihinde kaynağından arşivlendi. http://web.archive.org/web/20160430033529/http://homakov.blogspot.jp/2013/03/oauth1-oauth2-oauth.html. Erişim tarihi: 2013-03-06. 
  20. ^ OAuth 2.0 Threat Model and Security Considerations.
  21. ^ "OAuth Security Advisory: 2014.1 "Covert Redirect"". OAuth. 4 May 2014. 21 Kasım 2015 tarihinde kaynağından arşivlendi. http://web.archive.org/web/20151121111134/http://oauth.net:80/advisories/2014-1-covert-redirect/. Erişim tarihi: 10 November 2014. 
  22. ^ "Serious security flaw in OAuth, OpenID discovered". CNET. 2 May 2014. 2 Kasım 2015 tarihinde kaynağından arşivlendi. http://web.archive.org/web/20151102002904/http://www.cnet.com:80/news/serious-security-flaw-in-oauth-and-openid-discovered/. Erişim tarihi: 10 November 2014. 
  23. ^ "Math student detects OAuth, OpenID security vulnerability". Phys.org. 3 May 2014. 6 Kasım 2015 tarihinde kaynağından arşivlendi. http://web.archive.org/web/20151106024436/http://phys.org/news/2014-05-math-student-oauth-openid-vulnerability.html. Erişim tarihi: 11 November 2014. 
  24. ^ "Covert Redirect". Tetraph. 1 May 2014. 10 Mart 2016 tarihinde kaynağından arşivlendi. http://web.archive.org/web/20160310005903/http://tetraph.com/covert_redirect/. Erişim tarihi: 10 November 2014. 
  25. ^ [1]
  26. ^ Dick Hardt, ed.
  27. ^ "End User Authentication with OAuth 2.0". 19 Kasım 2015 tarihinde kaynağından arşivlendi. http://web.archive.org/web/20151119133521/http://oauth.net:80/articles/authentication/. Erişim tarihi: 8 March 2016. 
  28. ^ "OAuth 2.0 - Looking Back and Moving On". Eran Hammer. 23 October 2012. 25 Nisan 2016 tarihinde kaynağından arşivlendi. http://web.archive.org/web/20160425055540/https://vimeo.com/52882780. Erişim tarihi: 22 November 2012. 

Dış bağlantılar[değiştir | kaynağı değiştir]