Selamun aleyküm arkadaşlar, bu konumda kabaca OAuth 2.0 Autorisierung (Yetkilendirme)'yi ve Google ve Co'nun nasıl kullandıklarını anlatmaya çalışacağım. 2 parçadan oluşacak 1.kısmı yani bu kısım örnekler ile OAuth 2.0'ın nasıl çalıştığını ve Autorisierung(Yetkilendirme) ne olduğunu anlatmaya çalışacağım.

Annem tatildeydi. Antalyada bir buçuk hafta. Ama bir sorunu vardı! Çiçekleriyle ilgilenecek kimse yoktu. Nergis ve orkide. Kimse ilgilenmediği takdirde 1,5 hafta sonra yaşama ihtimalleri SIFIRın altında. O'nun yardıma ihtiyacı vardı! Yokluğunda bitkileriyle ilgilenecek biri. Güvenebileceği daire anahtarını kaygısız verebileceği. Herhangi bir X kişi söz konusu değildi. Annemin güvenebileceği bir kişi olmalıydı. Bu büyük sorumluluk gerektiren iş (büyük ciddiyetle söylüyorum!) Annem tarafından bana aktarıldı.

Ve dedim ki; "Annem bana güveniyor." Neyse ailevi projelerimle ilgili bir konu değil onuda bir ara anlatırım.

Birine bir şey için yetki verme sürecine, Autorisierung adı verilir; bu, benzer Authentifizierung kelimesiyle karıştırılmamak zorundadır.

Yetkilendirme ve kimlik doğrulama arasındaki fark

Saldırıya uğrasam ve bir hırsız benden anahtarı çalsa? O zaman bu da annemin dairesine erişebilir ve çiçekleriyle ilgilenebilir. Anahtarın bir kopyasını da yaptırabilir.

Gerçek hayatta anahtar ve kimlik doğrulamanın görevi Authentifizierung'dur Autorisierung değil.

Teknik açıdan bakıldığında, annem çiçekleriyle ilgilenmem için dairesini açmakla yetkilendirdi.(Autorisierung)

Ve Autorisierung tam olarak bu makalede bahsetmek istediğimiz konu.

Bunun için OAuth 2.0 ( Open Authorization, Açık Yetkilendirme) protokolüne bakacağız. Bu protokol, diğer şeylerin yanı sıra, Google tarafından sunulan ve gmail veya bulut depolama izni olan Google Drive gibi hizmetleri yetkilendirmek(Autorisierung) için kullanılır.

Bu resmi gördüyseniz hazırsınız demektir;



Güven internete ihtiyaç duyar.

Giderek daha fazla sözde kritik iş süreçleri İnternet üzerinden ele alınmakta, bu sayede güçlü bir Autoeisierung seçeneğinin önemi açıktır. Güçlü, Autorisierung güvenli ve elverişli olması gerektiği anlamına gelir. Bu iki faktör zıt yönlerde hareket eder. Buradaki özel zorluk, internetteki uygulamaların giderek dağıldığıdır. Örneğin, fotoğraf uygulamanızın Facebook portföyünde olmasa da, oluşturduğunuz resimlerinizi telefonunuzdaki fotoğraf uygulamasıyla Facebook'ta anında yayınlayabilirsiniz. Mesela Instagram gibi.

Nasıl çalışır?

Facebook, RESTful web servisleri olarak uygulanan, dışarıdan görülebilen (halka açık) bir API (Application Programming Interface, Uygulama Programlama Arayüzü) sunar. Bu API sayesinde, mesajlaşma, beğenme veya arkadaşlık istekleri göndermek gibi normal Facebook işlevlerini yapabileceğiniz programlar yazabiliriz. Ancak, fotoğraf uygulamamızın bu özelliklerin tümünü kullanmasına izin vermek için çok mu güveniyoruz?

Hayır, bu bir güvenlik açığı olurdu! Güven iyidir, ancak bu durumda kontrol daha da iyidir. Bu bizi Autorisierung sorununa geri getiriyor. Fotoğraf uygulamamızın resim yayınlamasına izin vermek, ancak arkadaşlık isteklerini göndermeyi yasaklamak istiyoruz.

Bunu gerçekleştirmek için hangi olasılıklara sahibiz?

Bir olasılık, her bir API çağrısı için bir kullanıcı isteğinde bulunmaktır. Bu, Facebook kimlik bilgilerini onaylamalıdır.

Bu yüzden yayınlamak istediğimiz her resimden önce kimlik bilgilerimizi girmeliydik. Çok can sıkıcı ve iyi bir kullanıcı deneyimi yok. Roma'dan 19 yaşında bir selfie-stick implantlı turist kesinlikle bundan hoşlanmayacaktı. Tabii ki, bizim app kimlik bilgilerini kaydedebilir, böylece her seferinde yeniden girmek zorunda kalmazlar. Ama bu apartman anahtarlarını herhangi bir kişiye vermek gibi olurdu. Bu prosedürün kesin bir dezavantajı vardır, bu nedenle bu prosedürde bir antipattern söz konusudur. Parolamız Antipattern. Yani başka bir çözüme ihtiyacımız var ve bu bize OAuth protokolüne yönlendiriyor.

OAuth 2.0 protokolü etkin!

Fotoğrafımızı doğrudan Facebook zaman tüneline göndermek istediğimiz fotoğraf uygulamasıyla örneğimize sadık kalacağız. Bu senaryoda, aşağıdaki aktörlere sahibiz. İlk olarak, b0mb adında bir kullanıcı istiyorum. b0mb'un resimlerini, arkadaş listesini ve zaman tünelindeki mesajları içeren sözde kaynaklar içeren bir Facebook hesabı var. Bu kaynaklar açıkça b0mb'a atandığından, b0mb'u da kaynak sahibi olarak çağırıyoruz.

Bu kaynaklar, kaynaklara güvenli bir şekilde erişmekten de sorumlu olan bir kaynak sunucu tarafından yönetilmektedir. b0mb kendi zaman tünelune bir gönderi eklemek isterse, önce kaynak sunucuya giriş yapması gerekir. Bu, örneğin bir şifre girerek yapılabilir.

Parolamız Anitipattern. Biz seni istemiyoruz!

Son ve en önemli oyuncu olarak, doğrudan b0mb'un zaman tüneline doğrudan resim göndermek isteyen üçüncü taraf fotoğraf uygulamasına sahibiz. Şifreyi, fotoğraf uygulamasından kaynak sunucusuna aktarmayı nasıl engelleyebiliriz?

OAuth'un yardımıyla parola antipatterning problemini çözmek için, OAuth sunucusu olarak adlandırılan başka bir oyuncuyu tanıtıyoruz. Bu ek sunucunun yardımıyla, fotoğraf uygulamamızı kaynak sunucudaki parola ile kaydetmekten kaçınabiliriz.