OAuth Uygulamalarında Çoklu Redirect URI ve Token Yenileme
GitHub, OAuth uygulamaları ve GitHub App platformlarında güvenliği artırmayı hedefleyen bir dizi güncelleme yayımladı. Değişiklikler OAuth uygulamalarına süresi dolan erişim tokenları ile yenileme (refresh) tokenı kullanma imkanı tanıyor, birden fazla redirect URI kaydına olanak veriyor ve redirect URI’ler için joker (wildcard) eşleşmesini opsiyonel hale getiriyor. Aşağıda her başlığın kaynaktaki bilgilere göre ne anlama geldiğini ve geliştirici tarafında nasıl uygulandığını özetliyorum.
OAuth uygulamaları için dönen (rotating) tokenlar
OAuth uygulamaları artık kullanıcı kimlik doğrulama akışı sırasında kısa ömürlü token talep edebiliyor. Uygulama bu davranışa dahil olduğunda sekiz saat geçerli bir erişim tokenı ve altı ay geçerli bir yenileme tokenı elde ediyor. Erişim tokenının süresi dolduğunda uygulama, yenileme tokenını kullanarak yeni bir token çifti alıyor.
Geliştiriciler yenileme tokenı desteğini uygulamaya iki farklı şekilde ekleyebilir:
- Kimlik doğrulama isteğine
offline_accesskapsamını (scope) eklemek. Bu yöntem kısa ömürlü token akışını tetikliyor ve GitHub’ın belirttiği üzere değişikliği test edip aşamalı olarak devreye almanın önerilen yolu. - Uygulama kaydında her zaman kısa ömürlü token kullanılacak şekilde ayar yapmak. Bu seçenek, güncellenmemiş eski istemcileri güncellemeye zorlamak ve tüm istemcilerin kısa ömürlü token almasını garantiye almak için tercih edilebilir.
Kısa ömürlü tokenlar, yeni oluşturulan tüm uygulamalarda varsayılan olarak etkin geliyor. Kullandığınız kimlik doğrulama SDK’sı yenileme tokenı akışını henüz desteklemiyorsa SDK’yı güncellerken bu özelliği geçici olarak devre dışı bırakabilirsiniz.
Bir OAuth uygulamasında birden fazla redirect URI
Bir diğer önemli yenilik, OAuth uygulamalarına en fazla 10 redirect URI (GitHub arayüzünde “callback URI” olarak geçiyor) tanımlama imkanı vermesi. Böylece birden fazla ortam, alan adı veya dağıtım konfigürasyonu, ayrı uygulamalar oluşturmaya gerek kalmadan aynı OAuth uygulaması altında desteklenebiliyor.
Geliştiriciler, uygulama ayarlarında yeni eklenen Add redirect URI düğmesiyle eşleşmede kullanılacak ek URL’leri tanımlayabilir.
Redirect URI’ler için wildcard eşleşmesi
OAuth uygulamaları ve GitHub App’ler, yapılandırılmış her redirect URI için ayrı ayrı wildcard eşleşmesini etkinleştirebiliyor. Bu, örneğin bir uygulamanın kiracı bazlı (tenanted) alt alan adları gibi birden fazla ilgili site için her kiracıya özel redirect URI kaydetmeden yönlendirme yapabilmesine olanak tanıyor.
Wildcard eşleşmesi etkinleştirildiğinde yetkilendirme kodunun (ve kullanıcının), redirect URI’nin bir alt alan adına ya da ek bir yoluna uyan herhangi bir URL’ye GitHub tarafından gönderilmesine izin veriliyor.
Yönlendirilen site kendi rotaları üzerinde güçlü bir kontrole sahip değilse (örneğin kullanıcı içeriği barındırıyorsa) wildcard eşleşmesi kötüye kullanılabilir. GitHub, bu özelliği açmadan önce uygulama mimarisinin gözden geçirilmesini öneriyor.
Yalnızca tek bir redirect URI’ye sahip uygulamalarda wildcard eşleşmesi zaten etkin durumda. Bu GitHub’ın eski (legacy) davranışıydı; artık görünür ve kontrol edilebilir hale geldi. GitHub, mevcut uygulamaların gözden geçirilmesini ve ihtiyaç yoksa wildcard eşleşmesinin devre dışı bırakılmasını tavsiye ediyor. Bu, tüm OAuth uygulamalarını ve tek bir redirect URI kayıtlı olan GitHub App’leri kapsıyor.
GitHub Enterprise Server tarafı
Değişikliklerin tamamının GitHub Enterprise Server 3.23 sürümünde de yer alacağı belirtiliyor. Böylece self-hosted GHES kullanan kurumlar da aynı token yenileme ve redirect URI iyileştirmelerinden yararlanabilecek.
Geliştiricilerin dikkat etmesi gerekenler
- Kimlik doğrulama SDK’nızın yenileme tokenı akışını destekleyip desteklemediğini kontrol edin; desteklemiyorsa güncelleme planı yaparken kısa ömürlü tokenları geçici olarak kapatmayı değerlendirin.
- Kısa ömürlü token akışını önce
offline_accesskapsamıyla test edip aşamalı yaymak, uygulama kaydında zorunlu hale getirmeden önce daha güvenli bir geçiş sağlar. - Tek redirect URI’li uygulamalarda geçmişten gelen wildcard davranışının hala açık olabileceğini unutmayın; gerçekten gerekmiyorsa kapatın.
- Wildcard etkinleştirmeden önce hedef alan adının rota kontrolünü ve kullanıcı içeriği barındırıp barındırmadığını değerlendirin.
Token yaşam döngüsü ve OAuth güvenliği konularını daha geniş bir çerçevede ele almak isteyenler, kimlik doğrulama tokenlarının veri sözleşmesi olarak kullanılmaması gerektiğine dair daha önceki değerlendirmeye de göz atabilir.
Kaynaklar ve İleri Okuma
- GitHub Changelog: Multiple redirect URIs and token refresh for OAuth apps
- Authorizing OAuth apps (GitHub Docs)
- GitHub App: User authorization callback URL (Docs)
- Creating an OAuth app (GitHub Docs)
- GitHub Community tartışması
- Kimlik Doğrulama Token’ları Neden Asla “Veri Sözleşmesi” Değildir?
- GitHub App Token Formatı Değişiyor: Hazırlık Rehberi
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
3 comments