OAuth spesifikasyonu ilk olarak 2007'de yayınlandı. React ve Angular gibi çerçeveler üzerine inşa edilen Tek Sayfalı Uygulamaların (SPA'lar) hakim olduğu bugünün web geliştirme ortamı, OAuth'un ilk taslağını oluşturan komiteye tamamen yabancı olurdu. Bunun, MySpace'in etrafındaki en büyük web sitelerinden biri olduğu ve bugün bildiğimiz mobil uygulamaların bulunmadığı bir zaman olduğunu hatırlayın.
OAuth'un birkaç revizyondan geçmesi şaşırtıcı değil. İlk büyük revizyon, daha önce bahsedilen göze çarpan eksikliklerin bir kısmını karşılayan OAuth 2.0'ın 2012'de piyasaya sürülmesiydi. Ancak yazılım geliştirme hızla hareket eden bir alandır ve 2012 yılında geliştirme için yaygın olarak kullanılan normlar ve teknolojiler bile bugün büyük ölçüde yerini almıştır.
Bu hikaye, OAuth'un SPA çerçeveleriyle desteklenen günümüz web uygulamalarının ihtiyaçlarını yansıtacak şekilde nasıl güncellendiğine ve üçüncü taraf API'lerle etkileşime giren güvenli kod yazmak için bu yeni işlevleri nasıl kullanabileceğimize odaklanacak.
OAuth'un, geliştiricilerin, kullanıcıların verilerine başka bir uygulamadan erişmelerine izin verebileceği çeşitli "akışları" vardır. Neredeyse her akış, kullanıcının kimlik bilgilerini doğrudan harici API'ye iletmesini ve uygulamanız tarafından alınan ve ardından kimliği doğrulanmış kullanıcıyı temsil eden bir erişim belirtecini içerir. Tartışmamıza devam etmeden önce dört ana OAuth akışını hızlıca inceleyelim.
3. İstemci Kimlik Bilgileri: Bu, daha az kullanılan bir akıştır. Bu akışa hiçbir kullanıcı dahil değildir. Bunun yerine, arka uç sunucunuz bir jeton almak için doğrudan OAuth sunucusuyla kimlik doğrulaması yapar. Bu yöntemin en büyük sınırlaması, belirli bir kullanıcının erişim belirtecini alamamanız ve yalnızca harici API içindeki herkese açık bilgilere erişimle sınırlı olmanızdır.
4. Kod Değişimi için İspat Anahtarlı Yetkilendirme Kodu PKCE: PKCE'li Yetkilendirme Kodu ('pixy' olarak telaffuz edilir), Örtük Akış ve Yetkilendirme Kodu akışının bir kombinasyonu olarak düşünülebilir. Yetkilendirme kodu akışının doğrudan web istemcisinde kullanılmasına izin verir, çünkü istemciyi aşağıdaki gibi doğrulamak için bir karma sorgulama kullanarak bir istemci sırrına olan ihtiyacı ortadan kaldırır:
Burada kod doğrulayıcı rastgele bir dizedir. Ön uç uygulaması her yüklendiğinde farklıdır. Sunucu, yukarıdaki diyagramın 3. bölümündeki talebin, bölüm 3'te kod doğrulayıcının kendi karmasını hesaplayarak bölüm 1'deki taleple aynı kaynaktan geldiğini doğrular ve bu daha sonra bölüm 1'de alınan karma ile aynı olmalıdır. .
TLDR: Örtülü Akış, güvenlik açıkları olan arkaik bir standarttır. Yetki Kodunu mümkün olan her yerde Örtük Akış yerine PKCE ile kullanın.
PKCE ile örtük akış ve Yetkilendirme kodu akışı, her ikisi de nihai olarak istemci uygulamanızın OAuth erişim belirteciyle sonuçlanmasını sağladığından, doğrudan bir SPA istemcisinde kimlik doğrulaması için uygun yaklaşımlardır. Ancak, Örtük Akış, yeniden yönlendirmenin URL'sini görebilen herhangi biri kullanıcının kimliğine bürünebileceği için önemli bir güvenlik açığı olan URL'nin bir parçası olarak erişim belirtecini döndürür. Yetkilendirme kodu akışı, jetonu bir POST isteğinin yanıt gövdesinde güvenli bir şekilde döndürerek bu sorunu çözer. Bu nedenle, Yetkilendirme Kodu akışını her zaman Örtük Akış yerine PKCE ile kullanmayı hedeflemelisiniz.
Bu, insanların kendi arka uçlarına bağlı React gibi bir SPA müşterisine sahip olduklarında karşılaştıkları yaygın bir ikilemdir. Bu durumda, arka uç sunucunuzdaki belirteci almak için Yetkilendirme Kodu akışını kullanabilir veya belirteçinizi ön uçta almak için PKCE akışıyla Yetkilendirme Kodunu kullanabilirsiniz. Hangisini kullanmalısınız? Belirtecin sunucu tarafında alınmasını kesinlikle zorunlu kılmak için iyi bir nedeniniz yoksa, yine de PKCE ile Yetkilendirme Kodunu kullanmanızı tavsiye ederim.
Bunun nedeni, Yetkilendirme Kodu akışının kullanılması, yeniden yönlendirme sunucuya yapıldığı için kullanıcıyı ön uçta asılı bırakmasıdır. Node / Express arka uç ile istemci tarafında oluşturulmuş bir React uygulamamız olduğunu ve üçüncü taraf bir sağlayıcıyla oturum açma işlemi gerçekleştirdiğimizi varsayalım. Yukarıdaki yetkilendirme kodu akışı (PKCE olmadan) şemasına bakın. OAuth sağlayıcısı 4. adımdaki erişim kodunu arka uca döndürdüğünde, bu noktada web uygulamasındaki kullanıcınız giriş ekranında olmaya devam edecek ve sunucunun, kimlik doğrulamanın başarılı olduğunu sunucuya iletme yolu olmayacaktır. . Web uygulamasının güncellenmesi için bu noktada yenilenmesi gerekecektir.
Bunun aksine, PKCE akışı web uygulamasında çözülür ve bu da jetonu arka uç sunucusuna göndermemize ve yanıtı aldığımızda web uygulamasındaki ekranı hemen güncellememize olanak tanır. Bu, çok daha sorunsuz bir kullanıcı deneyimi sağlar.
PKCE akışının etkin olduğu Auth Code'u görmek için hızlı bir örnek yapalım. Bir barebones React uygulaması kullanacağız. Uygulamamızda, kullanıcının bir erişim belirteci almak için Spotify'da oturum açmasına izin veren tek bir işlev uygulayacağız. Bu erişim jetonunu arka ucumuza gönderiyormuş gibi yapacağız ve bu jetondan e-postayı çıkararak kullanıcıyı veritabanımıza kaydetmek için kullanacağız.
İlk olarak, işte ana App.jsx dosyamız. Uygulamamızın yalnızca iki bileşeni vardır: biri giriş akışını başlatmak, diğeri ise yukarıdaki PKCE akış şemasında 2. adımdaki yönlendirmeyi yönetmek için.
Sıradaki, Giriş bileşeni. Oturum açma düğmesine tıklandığında, rastgele uzunlukta rastgele bir dizi oluşturulur. Bunun temel 64 kodlu karması hesaplanır ve kullanıcının Spotify sunucusuna gönderilmek üzere ayrıntılarını girdiği URL yönlendirmesine dahil edilir. Durum adı verilen başka bir rastgele dize üretilir ve istekte gönderilir. Bu, Spotify'dan gelen yanıtın meşru olduğunu doğrulamak için daha sonra kontrol edilebilir. Kod doğrulayıcı ve durum yerel depoda saklanır, çünkü bir sonraki adımda Spotify API'den yönlendirmeyi ele alırken onlara ihtiyacımız olacak.
Son olarak, yönlendirmeyi Spotify API'den halledecek bir bileşenimiz var. Yönlendirme, bir POST isteği aracılığıyla bir erişim belirteci oluşturmak için kullanabileceğimiz bir kod içerir. Ancak kodu takas etmek için sadece kodu kullanamayız. Ayrıca, son adımda oluşturduğumuz ve sakladığımız karma olmayan kod doğrulayıcıyı da eklememiz gerekecek. Burada bir önceki bölümde gönderdiğimiz durumu da doğruluyoruz.
Jetonu aldıktan sonra, jetonu kullanıcının e-postasını ve diğer ayrıntılarını çıkarmak ve veritabanında saklamak için kullanabilen arka uç sunucumuza gönderebiliriz.
OAuth yıllar içinde önemli ölçüde gelişti. PKCE akışlı Yetkilendirme Kodu, React, Angular veya Vue gibi çerçeveler üzerine kurulu Tek Sayfalı Uygulamalar ile kullanılmak üzere tasarlanmış en son eklemelerden biridir. PKCE akışı, eski Örtülü Akışın sorunlarının ve güvenlik açıklarının üstesinden gelir ve modern web uygulamalarında OAuth belirteçlerini almak için önerilen yöntemdir. Spotify, PKCE akışını nasıl uygulayacağınızı öğrenmek için kullanabileceğiniz iyi belgelenmiş bir yetkilendirme API'si sağlar.
Teknoloji dünyasında, işletmeler sürekli olarak siber suçluların şeytani faaliyetlerinin tuzağına düşme riski altındadır. Endişe verici derecede sık hale gelen böyle bir taktik, kimlik bilgilerini doldurmaktır.
Kasım 2020'nin başlarında SalesForce, açıklanamayacak şekilde JARM adlı yeni bir aktif TLS parmak izi alma aracını duyurdu. JARM'ın temeli, bir hedef sunucu özel olarak hazırlanmış çeşitli farklı TCP "İstemci merhaba" paketleri kullanılarak tarandığında, elde edilen yanıtların birleştirilip, paylaşılan veya benzer bir uygulama veya sunucunun göstergesi olan bir parmak izi sağlamak için karma hale getirilebilmesidir. yığını.
Harika geliştiriciler yapan teknik olmayan şeyler Bir süredir bu makaleyi yazmayı erteliyorum - yazmak için hiç nitelikli hissetmedim. Bugün onu yazma zamanının geldiğini düşündüm.
Teknoloji endüstrisindeki bir pozisyon için mülakat yaparken, herhangi bir teklif değerlendirilmeden önce genellikle en az üç tur mülakattan geçeceksiniz. Mermiler genellikle şuna benzer: Eğer öyle düşünüyorsan, yanılıyorsun.
Pragmatik Programcı ilk olarak 1999'da yayınlandı ve o zamandan beri tüm zamanların en iyi programlama kitabı seçildi. Yazarlar Andy Hunt ve David Thomas, Agile Manifesto'nun orijinal yazarları arasındaydı ve bazı ciddi referanslara sahipler.