Access Management 2-OpenID OAuth2 OpenID Connect
Access Management 1-XACML Authorization Authentication
Access Management 2-OpenID OAuth2 OpenID Connect
İlk yazımızda Authorization ve Authetication kavramlarından bahsetmiştik. Bir uygulamaya gelen erişim isteğinin ne şekilde işlenerek sonuçlandığından bahsettik. Gündelik yaşamda duymaya aşina olduğumuz bu iki tanımı neredeyse her uygulamada bir arada kullanıyoruz. Sosyal medya hesaplarımızdan mail adreslerimize, forumlardan üye olduğumuz sitelere kadar her yerde bir üyeliğimiz, kullanıcı adımız ve şifremiz, var. Aklımızda tutmamız gereken o kadar kullanıcı adı ve şifremiz var ki bunları saklamak için password manager uygulamaları kullanmamız gerekiyor.
Bu karmaşayı gidermek için 2005 yılında Brad Fitzpatrick tarafından OpenID isimli bir kimlik doğrulama protokolü için çalışıyordu. Aynı şekilde 2006 yılında da Twitter bu konuda çalışmalarını hızlandırmıştı. Yaklaşım şuydu, her üyelik sistemi gerektiren siteye yeni bir kullanıcı adı/şifresi yaratmak yerine OpenID’de yaratılan bir kimlikle tüm diğer sitelerde üyelik ve login gerçekleştirilebilecekti.
Kullanıcı bir foruma üye olmak istediğinde OpenID kimliğiyle üye olacaktı. Kullanıcı sonraki her login isteğinde siteye OpenID ile login olmak istediğini söyleyecek, site kullanıcıyı OpenID’ye yönlendirip oradan doğruladığı kimliğiyle geçerli bir sertifika aracılığıyla tekrar kendisine gelmesini isteyecekti. Böylelikle kullanıcı adı/şifresi kaosu artık yaşanmayacaktı. OpenID bir Federated Authentication örneğidir.
Bu çalışmalar devam ederken 2007 yılında ilgili ilginç bir gelişme yaşanmıştı. Eski PayPal çalışanları Jeremy Stoppelman ve Russel Simmons’un bir girişimi olan Yelp, yerel işletmeler hakkında kullanıcıların deneyimlerini paylaştıkları bir site geliştirdiler. Sitenin kullanımını artırabilmek için önemli bir nokta vardı, insanlar kendi çevresindeki arkadaşlarının yorumlarını daha çok önemsiyorlardı. Bir şekilde üye profillerin kendi arkadaş çevresindeki kişilerle etkileşiminin artırılması gerekiyordu ancak kimin kiminle arkadaş olduğu bilinmiyordu.
O zaman için büyük bir hamle yaparak üyelik sisteminde bir farklılık yarattılar. Yeni üye olacak kişileri halihazırda kullandıkları MSN, Yahoo, Gmail hesap bilgileri üzerinden sisteme üye yapacaklardı. Aldıkları bu bilgilerle gerçekten hedef sistemde, örneğin MSN(Hotmail), bu kullanıcının var olup olmadığını kontrol edecek, hem de kullanıcının arkadaş çevresi bilgilerini öğrenebileceklerdi. Bu şekilde sitedeki üye profilleri arasındaki etkileşim artırılacaktı.
Gerçekten de bütün bu uğraşlar sonuç buldu. Hatta o kadar çok insan sonuçlarını düşünmeden bu sistemi kullandı ki oluşan güvenlik açığı büyük şirketlerin tepkisini çekti. Tehlike şuydu; kullanıcılar authentication amacıyla verdikleri gerçek hesap kullanıcı ve şifreleri ile Yelp uygulamasına sınırsız erişim yetkisi veriyorlardı. Yelp bu bilgilerle kullanıcıların tüm maillerine, konuşma geçmişlerine, iletişim bilgilerine, güvenlik tercihlerine ve daha nicelerine erişim yetkisi elde ediyordu. Aslında ihtiyaç duyulan sadece arkadaş listesine erişebilmek iken kullanıcının tüm tercihlerini değiştirebilecek bir yetkiye sahip olmak doğru kurgulanmamış bir authorization kurgusundan başka bir şey değildi.
Birkaç yıl önce çalışmaları başlatılan OpenID projesi açık bir standart olmadığı sebebiyle 2007 yılında kurulan OAuth Discussion Group açık protokol için taslak bir öneri yazma çalışmalarına başladı. Yelp senaryosuyla karşı karşıya kaldığı zamanlara denk gelen Google, bu çalışmalardan haberdar olduğunda destekleyerek süreci hızlandırdılar. Aynı senenin Aralık ayında OAuth Core 1.0 Protokol Şablonu yayımlandı. İlerleyen süreçte kullanımın kolaylığı ve hedef teknolojilerin çeşitliliği gözetilerek yenilenen OAuth 2.0 Framework’ü 2012 Ekim’de yayımlandı.
OpenID’de boş kalan authorization boşluğunu OAuth Protokolü’nün Token’lı yapısı sayesinde uygulamalar doldurmaya başladı. Artık Yelp’e yeni kullanıcı yaratmak istediğinizde sertifika yerine belirli kapsamda sınırlandırılmış yetkiler için onay alınıyor.
Buradaki farklılık, artık belirli bilgilere erişime kullanıcının onay verdiği sınırlarda geçerli tokenlar ile authorization’ın sağlanması noktasında ortaya çıkıyor. OpenID ile farklılığını aşağıdaki görselden inceleyebilirsiniz.
Zaman içerisinde ihtiyaçlar dahilinde Oauth 2.0 bir framework olarak ortaya koyuldu. Teknolojik çeşitliliğe ve kullanımın kolaylaştırılması odaklı gelişen versiyonda halen amaç aynı. Erişimin ve yetkilendirmenin sitelere direkt olarak kullanıcı adı/şifresi vermeksizin, erişimin bilgilerini barındıran bir token yapısıyla süreçleri yönetebilmek. Bu süreçleri OAuth 2.0 dört adet tanımla ele alıyor.
Senaryoya yine Yelp örneği üzerinden gidelim. Yelp’e Gmail hesabımızla login olmak istiyoruz. Hesap sahibi olan biziz, yani Resource Owner’ız. Yelp bizim Google Account’umuzdaki arkadaş bilgilerimizi almaya çalışan Client Application. Bu bilgiler Google’un Resource Server’larında tutulur. Authorization Server da yine Google’ın ilk yazıda bahsettiğimiz XACML standartlarında olduğunu varsaydığımız Identity Provider’ı olsun.
Kullanıcı browser’ı aracılığıyla Yelp’e login olmak istediğinde Yelp kullanıcının browser’ını Google’ın Authorization Server’ına yönlendirir. Kullanıcı Gmail hesabının bilgilerini girerek doğrulamadan geçerse Authorization Server’ın kendisine verdiği Authorization Code’u browser Yelp’e iletir. Yelp de bu kod ile Authorization Serverdan aldığı Access Token aracılığıyla Gmail’deki arkadaş bilgilerinin bulunduğu Resource server’a giderek bu bilgileri edinir. Bu Delegated Authorization’a bir örnektir. Authorization işlemi Google Resource server tarafından Google Authorization Server’a delege edilmiştir.
Önemli olarak belirtmekte fayda var. Yukarıdaki akış en çok kullanılan OAuth2 akışlarından birisi olan Authorization Code Flow akışı. 3 Farklı flow daha bulunmaktadır. Bunlar, Client Credentials Code Flow, Implicit Code Flow ve Resource Owner Password Credentials Code Flow’dur.
Bütün bu protokollerin, frameworklerin üzerine 2014'te OpenID Connect (OIDC) isimli OpenID Foundation tarafından geliştirilen bir framework ortaya koyuldu. OAuth 2.0'deki akışlar örnek alınarak ve ek adımlar eklenerek Delegated Authorization yerine Federated Authentication’ın kullanıldığı bir framework olarak tanıtıldı. Özetle:
- OpenID kullanıcının kimliğini doğrulayan(authentication)
- OAuth kullanıcının kaynaklarına erişimi kontrol eden(authorization)
- OpenID Connect de yukarıdaki iki maddenin toplamını gerçekleştiren frameworktür.
Sonraki yazımızda aynı OpenID Connect gibi Federated Authentication kullanan diğer bir Access Management standardı olan SAML’a ve çalışma prensiplerine, User Federation, Kerberos, SSO kavramlarına değineceğiz. Yazıya buradan erişebilirsiniz.
En yalın haliyle
Mehmet Cem Yücel
Bu yazılar ilgilinizi çekebilir:
Bir Yazılımcının Bilmesi Gereken 15 Madde
Spring ve Java Hantal Mı — GraalVM ve Quarkus’a Giriş
Mikroservisler-Service Mesh Nedir
12 Factor Nedir Türkçe ve Java Örnekleri
Blockchain teknolojisi ile ilgileniyor iseniz bunlar da hoşunuza gidebilir:
