Alanlar arası oturum açma işlemlerini birleştirme

Eiji Kitamura

Modern işletme mimarileri genellikle birden fazla farklı alanı kapsar. Kuruluşlar, pazarlama için brand.example, temel ürün için service-app.example ve müşteri hizmetleri için support-portal.example gibi farklı özellikler için özel ortamlar kullanır. İdeal olarak, kullanıcılar bu mülkler arasında gezinirken birleşik ve tek oturum açma deneyimi sunmak istersiniz. Ancak mühendislik ekipleri genellikle bu alanları, parçalanmaya neden olan geçici teknikler kullanarak entegre eder. Bu durum, şifre yöneticisinin otomatik doldurma akışlarını bozarak ve geçiş anahtarı kullanımını geciktirerek yerleşik tarayıcı kimlik bilgisi yönetimini kesintiye uğratır.

Aynı hesap birden fazla alanı kapsıyorsa kullanıcının alanların aynı kuruluşa ait olduğunu anlaması ve oturum açarken aynı kimlik bilgilerini sağlaması gerekir. En kötü durumda, kullanıcı yinelenen bir hesap oluşturur veya şifreyi kimlik avı web sitesine verir.

Alanlar arası kimlik parçalanmasını çözmek ve sorunsuz bir kullanıcı yolculuğu sunmak için mimari standartları ve çözümleri (ör. meta veriler, alanlar arası iFrame'ler, kimlik federasyonu ve alt alan adı birleştirme) nasıl kullanacağınızı öğrenin.

Sık kullanılan geçici çözümler

Kuruluşlar, alanlar arası yolculuğu sürdürmek için çeşitli yerleşik teknikler kullanır. Bu yöntemler yaygın olsa da tarayıcılar daha katı gizlilik sınırları ve güvenlik standartları uyguladığından yapısal engellerle karşılaşırlar.

CORS getirme istekleri

Alanlar bağımsız olarak çalıştığında ön uçlar, genellikle merkezi bir kimlik doğrulama API'sine yönlendirilen merkezler arası fetch() isteklerine dayanır. Bu istekler, merkezler arası kaynak paylaşımı (CORS) kullanılarak güvenli bir şekilde izin verilebilir. Tarayıcılar genellikle siteler arası çerezleri engellediği veya kısıtladığı için geliştiriciler, bu API'leri Set-Cookie üstbilgilerine güvenmek yerine JSON yüklerinde JSON Web Jetonları (JWT'ler) gibi kimlik doğrulama jetonları döndürecek şekilde açıkça tasarlayabilir.

Hesap veritabanı paylaşımı

Karmaşık ön uç entegrasyonları olmadan kimliği arka uçta birleştirmek için kullanıcı veri deponuzu merkezileştirebilirsiniz. Birden fazla alan aynı veritabanına karşı kimlik doğrulaması yapsa da ön uç giriş deneyimleri ayrı kalır. Bu durum, kullanıcıları aynı kimlik bilgilerini kullandıkları alan adlarını hatırlamaya zorlayarak kötü bir kullanıcı deneyimine yol açar.

Ayrık oturum açma işlemleriyle ilgili sorunlar

Teknik geçici çözümler temel işlevselliği sağlayabilir ancak sorunsuz bir yolculuk sunamaz. Ayrık oturum açma akışları, hem kullanılabilirlikten hem de güvenlikten ödün veren sürtünme noktaları oluşturur.

Şifre yöneticisi parçalanması

En büyük zorluk, şifre yöneticilerinin kesintiye uğramasıdır. Şifre yöneticileri, depolanan kimlik bilgilerini kaydedildikleri belirli kaynağa bağlar. Bu ayar, aynı kuruluşa ait olsalar bile tarayıcının farklı alanlarda otomatik doldurma önermesini engeller.

Bir kullanıcı, kaydedilmiş kimlik bilgilerinin bulunduğu bir alandan kuruluşunuzdaki yeni bir alana geçtiğinde şifre yöneticisi ilişkiyi tanıyamaz ve otomatik doldurma istemini tetiklemez. Bu durum, manuel girişle ilgili sorunlara neden olur. Kullanıcıların kimlik bilgilerini araması, şifrelerini sıfırlaması veya yinelenen bir hesap oluşturması gerekir.

Şifre yöneticisi bu mülklerde güvenilir olmadığını kanıtladığından kullanıcılar bu sitelerdeki araçları bırakabilir. Bunun yerine, genellikle başka yerlerde yeniden kullanmak için zayıf ve kolay hatırlanabilen şifreler oluştururlar. Bu durum, kuruluşunuzun genel güvenliğini azaltır.

Kimlik avı ağ geçidi

Bu kesinti, kimlik avı ağ geçidi olarak işlev görür. Şifre yöneticisinin, tanınmayan bir alanda otomatik doldurmayı reddetmesi temel bir savunma mekanizmasıdır. Kullanıcıların farklı URL'lerde kimlik bilgilerini manuel olarak girmesini isteyerek, kullanıcılarınızı istemeden kimlik avı saldırılarına karşı savunmasız hale getiriyorsunuz.

Geçiş anahtarı birlikte gösterimi

Geçiş anahtarları kullanıldığında sürtünme artar. WebAuthn'nin temel güvenlik mimarisi, geçiş anahtarlarını kriptografik olarak belirli bir Relying Party kimliğine (RP kimliği) sıkı bir şekilde bağlar.

Bu işlem, "RP ID Trap" oluşturur. Tarayıcı, alanlar arası erişimi reddettiği için brand.example üzerinde kayıtlı bir geçiş anahtarı service-app.example üzerinde kullanılamaz. Kullanıcıların her site için ayrı geçiş anahtarları kaydetmesini önlemek istiyorsanız bu özellikleri tek bir RP kimliğinde birleştirmeniz gerekir.

Önerilen yaklaşımlar

Kimlik sürekliliğini sağlamak için geçici oturum açma entegrasyonlarından uzaklaşmanız ve tanınan mimari standartları benimsemeniz gerekir:

• Meta veri yapılandırma dosyalarını kullanma: Kriptografik güven zinciri oluşturmak için Digital Asset Links ve İlgili Kaynak İstekleri gibi meta veri dosyalarını barındırın. Bu sayede, farklı alanlar ve mobil uygulamalar arasında sorunsuz kimlik bilgisi ve geçiş anahtarı paylaşımı yapılabilir. Bu yaklaşım, kimlik parçalanması için düşük maliyetli ve sessiz bir düzeltmedir. Mevcut web altyapısının karmaşık bir şekilde yeniden yapılandırılmasını gerektirmez.
• Kaynaklar arası iFrame'leri kullanın: Kayıtlı kimlik bilgilerini ve geçiş anahtarlarını farklı sitelerde köprülemek için merkezi kimlik doğrulama kaynağını güvenen taraf içinde iFrame olarak yerleştirin. Bu yaklaşım, İGP ve belgeler arası mesajlaşma yoluyla sıkı güvenlik sınırlarını korurken izin politikası ve bölümlendirilmiş çerezleri kullanarak sorunsuz ve bağlam içi bir oturum açma deneyimi sağlar.
• Standart kimlik federasyonunu kullanın: Kimlik doğrulama işlemlerini özel bir kimlik sağlayıcı (IdP) alanında merkezileştirmek için OpenID Connect gibi endüstri standardı protokolleri kullanın. Bu, güvenli yönlendirmeler aracılığıyla oturum açma yolculuğunu resmileştirerek kırılgan entegrasyonların yerini güvenilir ve ölçeklenebilir bir birinci taraf çözümüyle alır.
• Alt alan adlarını birleştirme: Ortak bir kök altındaki alt alan adlarına geçiş yapın. Bu, tüm kayıtlı alan genelinde joker karakterli çerezler ve geçiş anahtarı sürekliliği aracılığıyla sorunsuz oturum paylaşımını sağlar. Birçok şifre yöneticisi, paylaşılan kök alanı tanıyabilir ve ilgili alt alanlarda kayıtlı kimlik bilgilerini otomatik olarak önerebilir.

Meta veri yapılandırma dosyalarını kullanma

Alanlar arası kimliğin temel zorluklarından biri, kaydedilen kimlik bilgilerinin parçalanmasıdır. Şifre yöneticileri, farklı alanları ve uygulamaları tamamen yalıtılmış varlıklar olarak ele alır. Bu nedenle, bir mülkte kaydedilen kimlik bilgilerinin başka bir mülkte otomatik olarak doldurulmasını engeller.

Parçalanma sorununu çözmek için web sitenizin yapısını değiştirmek yerine şifre yöneticilerinin davranışını yapılandırabilirsiniz. Kuruluşlar, belirli meta veri yapılandırma dosyalarını barındırarak farklı alanların ve uygulamaların aynı kuruluşa ait olduğunu kriptografik olarak onaylayabilir. Bu sayede işletim sistemleri, tarayıcılar ve şifre yöneticileri bu ilişkiyi tanıyabilir ve kimlik bağlamını otomatik olarak köprüleyerek mülkleriniz arasında şifreleri ve geçiş anahtarlarını paylaşabilir. Web alanlarınız birleştirilmiş olsa bile web tabanlı şifreleri ve geçiş anahtarlarını mobil uygulamalarla paylaşmak için de bu yaklaşım gereklidir.

Farklı platformları ve ekosistemleri kapsadığınızdan emin olmak için iki farklı yapılandırma dosyası kullanın:

• Android ve Chrome'da Google Şifre Yöneticisi: Bir kuruluşun ilişkili uygulamaları ve web siteleri arasında doğrulanabilir bir güven ilişkisi oluşturmak için /.well-known/assetlinks.json konumunda bir Digital Asset Links (DAL) JSON dosyası barındırın. Bu güven, uygulamalarda derin bağlantıları ve Sorunsuz Kimlik Bilgisi Paylaşımı'nı etkinleştirir. Bu özellik sayesinde, web'de kaydedilen şifreler ilişkili web sitelerinde otomatik olarak doldurulur (ancak geçiş anahtarlarının birden fazla web alanında paylaşılması için yine de İlgili Kaynak İstekleri gerekir). Sorunsuz kimlik bilgisi paylaşımı kılavuzundan daha fazla bilgi edinebilirsiniz.

• iOS ve Safari'de Apple Parolaları: iOS uygulamaları ve Safari'de Apple Parolaları durumlarını köprülemek için gereken kriptografik güven zincirini oluşturmak üzere /.well-known/apple-app-site-association adresinde bir Apple App Site Association (AASA) dosyası barındırın. Üçüncü taraf ekosistemlerini desteklemek için bu ilişkili alanları kitle kaynaklı bir depoyu kullanarak merkezi olarak bildirebilirsiniz. Bu sayede bağımsız araçlar (ör. bu depoyu açıkça kullanan 1Password) da paylaşılan kimlik bağlamını tanır. Apple App Site Association hakkında daha fazla bilgi edinmek için Supporting associated domains (İlişkili alanları destekleme) başlıklı makaleyi okuyun.

Geliştiriciler, farklı web alanlarında geçiş anahtarlarını etkinleştirmek ve geçiş anahtarı engelini aşmak için /.well-known/webauthn adresinde bir Related Origin Requests (ROR) dosyası barındırabilir. ROR, aynı geçiş anahtarı RP kimliğini güvenli bir şekilde paylaşmasına izin verilen yetkili alanları açıkça belirtir. İlgili Kaynak İstekleri hakkında daha fazla bilgi edinmek için İlgili Kaynak İstekleri ile sitelerinizde geçiş anahtarı yeniden kullanımına izin verme başlıklı makaleyi inceleyin.

• Artıları:
  • Son kullanıcılar için arka planda düzeltme: Tamamen arka planda çalışır. Bu sayede, kullanıcı deneyiminde görünür herhangi bir değişiklik olmadan otomatik doldurma parçalanması otomatik olarak çözülür ve işletim sistemi veya tarayıcı düzeyinde geçiş anahtarı sürekliliği sağlanır.
  • Basit uygulama: Bu, yalnızca statik JSON dosyalarının barındırılmasını gerektiren düşük maliyetli bir çözümdür. Arka uçta yeniden mimari oluşturulmasını veya karmaşık jeton değişimi mantığı kullanılmasını gerektirmez.
  • Mevcut altyapıyı korur: Markanızı değiştirmeden veya alanlarınızı birleştirmeden alanlar arası yolculuğu önemli ölçüde iyileştirebilirsiniz.
• Eksileri:
  • Platform kısıtlamaları: Platformlar genellikle YG'ye katı sınırlar uygular. Örneğin, Chrome tek bir RP kimliğini en fazla 5 ilişkili eTLD+1 etiketiyle sınırlar. Örneğin, example.co.uk ve example.de aynı example eTLD+1 etiketini paylaşır ancak example-rewards.com ayrı bir example-rewards etiketi kullanır. Geniş veya çeşitli bir alan adı portföyünü yönetiyorsanız bu sınırlar yetersiz kalabilir.
  • Artan operasyonel gecikme: Meta veri dosyalarının çözümlenmesi için ek bir ağ gidiş dönüşü gerekir. Bu da tarayıcı kimlik doğrulama işlemini yaparken gecikmeye neden olur.

Kaynaklar arası iframe'ler kullanma

ROR alan sınırları nedeniyle meta veri yapılandırma dosyaları yaklaşımını kullanamıyorsanız alanlar arası iframe öğeleri, alanlar arası oturum açma sorunlarını çözmek için sağlam ve standartlar tarafından desteklenen bir yol sunar.

Merkezi kimlik doğrulama kaynağını (örneğin, auth.brand.example) güvenen taraf içinde (örneğin, brand.example) iFrame olarak yerleştirerek hem normal form alanlarıyla hem de modern API'lerle etkileşim kurabilirsiniz. Şifreler için tarayıcının kimlik bilgisi yöneticisi, otomatik doldurma işlemlerini iFrame'in kaynağıyla (auth.example) ilişkilendirir. Bu sayede kullanıcılar, farklı sitelerde merkezi kimlik bilgilerine sorunsuz bir şekilde erişebilir.

Geçiş anahtarları için üst pencere, izin politikası çerçevesini kullanarak iFrame'e erişim izni vermelidir. Bu sayede iFrame, kendi kaynağının RP kimliğine karşı kimlik doğrulaması yapmak için WebAuthn'i çağırabilir. Her iki akışta da İGP (İçerik Güvenliği Politikası), kullanıcıları tıklama tuzağı ve siteler arası komut dosyası çalıştırma gibi saldırılardan korumak için yararlıdır. Kimlik doğrulama başarılı olduktan sonra, bölümlenmiş bir çerezle oturum oluşturulur ve jeton, postMessage() kullanılarak güvenli bir şekilde üst pencereye geri iletilir.

• Artıları:
  • Merkezi kimlik bilgileri: Kimlik bilgilerinin parçalanmasını önler. Tek bir merkezi kaynak, hem kayıtlı şifreleri hem de birleşik geçiş anahtarı RP kimliğini yönetir. Böylece farklı alanlar, alanları birleştirmeye gerek kalmadan bu kimlik bilgilerini paylaşabilir.
  • Bağlama dayalı kimlik doğrulama: Şifrenin otomatik olarak doldurulması veya geçiş anahtarıyla doğrulama gibi tüm oturum açma akışı, kesintiye neden olan birleştirilmiş yönlendirmelerden kaçınarak üst sayfada sorunsuz bir şekilde gerçekleşir.
  • İzlemeye karşı koruma özelliklerine karşı dayanıklılık: Bu yaklaşım, bölümlenmiş çerezler kullanılarak siteler arası izlemeye karşı sıkı koruma uygulandığında bile doğru şekilde çalışır.
• Eksileri:
  • Uygulama kısıtlamaları: Bu mimari, uzmanlaşmış mühendislik gerektirir. Güvenilir üst alanlara yerleştirmeyi kısıtlamak ve tıklama korsanlığını önlemek için katı CSP (frame-ancestors), WebAuthn API'yi etkinleştirmek için HTTP izin politikalarının yapılandırılması ve kaynak sahteciliği ile CSRF saldırılarını azaltmak için güvenli, doğrulanmış belgeler arası mesajlaşma (postMessage()) gerektirir. En iyi uygulamaları iFrame'lerde geçiş anahtarları sayfasında öğrenebilirsiniz.

Standart kimlik federasyonunu kullanın.

OpenID Connect gibi standart kimlik federasyonunu benimsemek, hesap sisteminizi sürdürmek için sağlam ve sürdürülebilir bir yaklaşımdır. Bu yaklaşım, kimlik doğrulama iş akışını auth.brand.example gibi tek bir özel kimlik sağlayıcı (IdP) alanında birleştirerek resmileştirir. Uygulamalar, oturum açma işlemini hedef alanda tamamlamak için güvenli bir şekilde jeton aktarımı almadan önce kullanıcıları kimlik doğrulama için bu merkezi hub'a yönlendirir. Genellikle üçüncü taraf oturum açma işlemleriyle (ör. Google ile oturum açma) ilişkilendirilse de standart federasyon, kırılgan geçici çözümlerin yerine birinci taraf çözümü olarak tamamen geçerli ve yaygın bir şekilde kullanılır.

• Artıları:
  • Ortak mühendislik dili: Geliştiricilerin belirli, özel olarak oluşturulmuş bir protokolü öğrenmesi veya sürdürmesi gerekmez. Bunun yerine, yerleşik sektör bilgilerinden ve kapsamlı kitaplıklardan yararlanabilirler. Paketlenmiş çözümler de mevcuttur.
  • Savaşta test edilmiş güvenilirlik: Standart protokollerin güvenli olduğu ve geçici uygulamalara kıyasla çok daha az kırılgan olduğu kanıtlanmıştır.
  • Kolayca genişletilebilir: Kuruluşun yeni bir üçüncü taraf hizmetiyle federasyon oluşturması veya daha sonra bir satın alma işlemini entegre etmesi gerekirse kimlik altyapısı, kimlik bilgileri sağlamak için zaten donatılmıştır.
  • Tutarlı kullanıcı deneyimi: Kullanıcılar, merkezi IdP sayfasını marka için yetkili kaynak olarak tanır. Böylece, kimlik bilgilerinin tam olarak ne zaman ve nerede gerekli olduğu netleşir.
• Eksileri:
  • Yüksek entegrasyon ek yükü: Merkezi bir IdP'ye geçiş yapmak veya bu IdP'yi geliştirmek yüksek entegrasyon ek yükü getirir ve özel güvenlik uzmanlığı gerektirir. Kuruluşlar, güvenli yönlendirmeye dayalı kalıpları desteklemek için bağlı tüm uygulamaları güvenli bir şekilde yeniden düzenlemeye yatırım yapmalıdır.
  • Kesintiye neden olan yönlendirmeler: Kimlik doğrulama akışı, kullanıcıların kaynak siteden merkezi bir kimlik sağlayıcı sayfasına yönlendirilmesini gerektiriyor. Bu durum, bağlam içinde sorunsuz bir oturum açma deneyimini engelliyor.

Alt alan adlarını birleştirme

Başka bir yapısal yaklaşım ise farklı dijital mülkleri ortak bir kayıt edilebilir kök alan (eTLD+1) altında birleştirerek tüm alanları birleştirmektir. Bu işlem, brand.example ve service-app.example gibi ayrı alanları www.brand.example ve service.brand.example gibi alt alanlara dönüştürmeyi içerir.

• Artıları:
  • Birleştirilmiş kimlik bilgisi yönetimi: Şifre yöneticileri, kök alanı tanıyabilir ve tüm alt alanları tek bir giriş olarak değerlendirerek şifreler için yinelenen istemleri ve manuel girişi ortadan kaldırabilir.
  • Geçiş anahtarı sürekliliği: Geliştiriciler, geçiş anahtarı RP kimliğini tescil edilebilir alanla yerel olarak sınırlayabilir ve geçiş anahtarı desteğini ilişkili tüm alt alanlarda anında genişletebilir. Bu durumda, brand.example RP kimliği hem www.brand.example hem de service.brand.example konumunda çalışır.
  • Kolay oturum paylaşımı: Alan yapısını birleştirmek, joker karakter çerezleri kullanarak tek bir oturumun paylaşılmasını sağlar (örneğin, bir çerezin kapsamını Domain=brand.example olarak belirleme).
• Eksileri:
  • Markalama ve taşıma kısıtlamaları: Kuruluşunuzun farklı üst düzey alanlar kullanması zorunluysa bu yaklaşım, markalama ile ilgili sınırlamalar getirebilir. Bu taşıma işlemi karmaşıktır ve HTTP yönlendirmelerinin dikkatli bir şekilde yönetilmesini, eski kaynaklar arası yapılandırmaların kapsamlı bir şekilde düzeltilmesini gerektirir.

Sonuç

Kimlik sürekliliğini sağlamak için geçici oturum açma entegrasyonlarından yerleşik kimlik doğrulama standartlarına geçiş yapmanız gerekir. İşletme kısıtlamalarını federasyon, alan birleştirme, iFrame'ler veya meta veriler gibi yerleşik uygulamalara göre değerlendirerek kullanıcı deneyimindeki sorunları ortadan kaldırabilir ve ekosisteminizde kimlik doğrulama sürecini iyileştirebilirsiniz.

İlgili konular hakkında daha fazla bilgi edinmek için blogumuzu takip etmeyi ve Chrome'un kimlik portalında diğer kaynakları incelemeyi unutmayın.