Oturum stratejisi nedeniyle kimlik doğrulama göçleri kesiliyor, giriş ekranları nedeniyle değil.

Çoğu auth migration süreci, yeni sağlayıcının zayıf olmasından değil, ekiplerin kimlik doğrulamayı bir kimlik projesi olarak görüp, aynı zamanda bir oturum davranışı projesi olduğunu görmezden gelmesinden dolayı başarısız olur.

Bu, sağlayıcılar, passkey’ler, JWT’ler veya SSO standartları hakkında tartışmaktan daha az heyecan verici görünüyor. Bu nedenle ekipler bunu sıklıkla atlıyor. Ancak kullanıcılar kimlik mimarinizi hissetmez. Beklenmedik bir şekilde oturum açılıp açılmadığını, bir sekmenin çalışırken diğerinin çalışmadığını, güvenilir bir cihazın birden bire güvenilir olmaktan çıktığını ve destek ekibinin neler olduğunu açıklayıp açıklayamayacağını hissetmektedir.

Bu nedenle, pratik öneri önceliklidir: göç lansmanından önce oturum yaşam döngüsünü planlayın. Oturumların web, API, mobil ve yönetici yüzeyleri arasında nasıl verildiğini, güncellendiğini, düşürüldüğünü, iptal edildiğini ve sona erdirildiğini açıklayamıyorsanız, kimlik doğrulama göç stratejiniz eksiktir.

Riskli kısım başarılı bir girişten sonra başlar

Çoğu ekip, kimlik doğrulamanın görünür yüzeyine odaklanır:

• giriş sayfası
• sağlayıcı seçimi
• SSO desteği
• MFA yapılandırması
• token formatı
• sosyal giriş veya kurumsal giriş yolları

Bunlar önemlidir, ancak genelde dağıtımın kırılmasına neden olan durumlar değildir.

Asıl zarar genellikle kimlik doğrulama teknik olarak başarılı olduktan sonra başlar.

Oturum davranışı, üretim gerçeğiyle çakışmaya başlar. Mevcut tarayıcı oturumları yaşamaya devam eder. Mobil uygulamalar sürüm takvimlerinin gerisinde kalır. Eski çerezler varlığını sürdürür. API istemcileri, güncel olmayan varsayımları önbelleğe alır. Yönetim araçları, göç sırasında dokunulmak istenmeyen eski oturum alanlarına dayanır.

Bu yüzden, sahneleme genellikle yanıltıcıdır. Temiz bir girişin temiz bir tarayıcıda geçerli olduğu kanıtlayıcı bir şey değildir. Gerçek kullanıcılar geçmişle gelir. Zaten çerezleri, hatırlanan cihazları, eski token’ları, birden fazla sekmeyi, birden fazla ürünü, kaydedilmiş oturumları, şifre sıfırlama bağlantılarını ve bazı durumlarda mobil istemcileri vardır; bunlar sizin backend dağıtımı ile bir haftadır geridedir.

Göç işleminizin hayatta kalması gereken ortam budur.

Gerçekten önemli sorular oldukça serttir:

• Diğer cihazlarda zaten giriş yapmış olan kullanıcılara ne olur?
• Artık çıkış yapmak ne anlama geliyor?
• Eski oturumlar yeni API’lere erişebilir mi?
• Yeni oturumlar eski çerezlerle güvenli bir şekilde bir arada durabilir mi?
• Hatırlanan cihaz güvenliği ne olur?
• Şifre sıfırlama, e-posta değişimi veya izin düşürülmesi durumunda ne iptal edilir?

Eğer bu sorular belirsizse, göç tasarımı eksik demektir; ne kadar şık görünse de giriş akışı.

Oturum stratejisi gerçek göç sözleşmesidir

Kötü bir auth migration hakkında düşünmenin en temiz yolu, kimliğin kullanıcının kim olduğunu kanıtladığı, oturum stratejisinin ise bu gerçeğin zamanla nasıl davrandığını tanımladığıdır.

Bu ikinci kısım, üretim güvenilirliğinin olduğu yerdir.

İyi bir oturum göç sözleşmesi, altı alanı açıkça belirtmelidir:

Ekiplere çelme takan şey, bunların sadece güvenlik detayları olmadığıdır. Bunlar ürün davranışlarıdır.

Eski sisteminiz uzun süreli tarayıcı sürekliliğine izin veriyorsa ancak yeni sistem sık sık yeniden kimlik doğrulama zorunluluğu getiriyorsa, kullanıcılar bunu fark eder. Eski sistem, şifre sıfırlama anında her şeyi iptal ederse ancak yeni olan sadece bazı istemcileri iptal ediyorsa, bu bir backend nüansı değildir. Bu, güvenlik duruşunda gerçek bir değişimdir. Bir uygulamadan çıkış yapmak, şimdi üç diğerinden çıkış yapmak anlamına geliyorsa, bu da uygulama detayı değildir. Bu, destek sonuçları olan bir ürün davranışıyla ilgilidir.

Bu nedenle, auth migration stratejisi, bir sağlayıcı entegrasyon kontrol listesi yerine bir operasyonel sözleşme gibi yazılmalıdır.

Karma mod dağıtımı, auth göçlerinin dengesiz hale geldiği yerdir

En kötü auth hata durumları genellikle temiz son durumda ortaya çıkmaz. Geçici uyumluluğun basit olacağını düşündükleri, karma bir geçiş aşamasında kendini gösterir.

Nadir olur.

Oldukça yaygın bir üretim şekli şu şekildedir: ana web uygulaması sunucu destekli bir oturumu güvenilir kabul eder, yeni API katmanı erişim ve yenileme token’larını bekler, yönetim paneli roller için eski oturum verilerini kontrol eder ve mobil uygulama sadece kısmen güncellenmiştir. Bu karışıma paylaşılan alt alanlar veya eski çerezler ekleyin ve sistemde “kimlik doğrulanmış” olmak, isteğin nereye gittiğine bağlı olarak farklı anlama gelebilir.

Bu, kullanıcıların bir perspektiften “giriş yapıldı” görünürken diğerinde “giriş yapılmadı” durumu olarak en sinir bozucu göç hatasına yol açar.

Bir yol çalışır. Diğerine yönlendirilir. UI oturumun süresinin dolduğunu iddia ederken API çağrıları başarılı olur. Şifre sıfırlama, tarayıcı oturumunu öldürür ama mobil tokenı etkilemez. Destek, tarayıcı durumu, dağıtım durumu ve uygulama sürümünün hepsinin önemli olduğu için bunu sürekli olarak yeniden üretemez.

Bu bir kenar durumu değildir. Bu, dağıtım modlarının açıkça belirtilmediği zamanlarda varsayılan hata modelidir.

Daha güvenli bir yaklaşım, göç durumlarını adlandırmak ve her hizmetin bunlara saygı duymasını sağlamaktır.

enum AuthRolloutMode: string
{
    case LegacyOnly = 'legacy_only';
    case DualAccept = 'dual_accept';
    case DualWrite = 'dual_write';
    case NewPrimary = 'new_primary';
    case LegacyRetired = 'legacy_retired';
}

Enum’in kendisi önemli değil. Disiplin önemlidir.

Her mod, aşağıdaki pratik sorulara yanıt vermelidir:

• Geçerli oturum nesneleri hangileri?
• Hangi çerezlerle kabul edilir?
• Hangi hizmetler her iki formatı da güvenilir kabul eder?
• Giriş, bir oturum nesnesi mi yoksa iki tane mi yazar?
• Uyumluluk penceresi hangi olayla biter?

Eğer bu yanıtlar birinin zihninde ya da iki hafta önceki bir sprint panosunda duruyorsa, dağıtım riskli hale gelmiştir.

Burada önerim görüşmelidir: karma mod sürelerini kısa tutun. Ekipler genellikle yeniden kimlik doğrulamayı zorlamaktan korkarak bunları uzatır. Pratikte, kısa ve açık bir şekilde iletilen bir yeniden giriş genellikle belirsiz karma oturum davranışlarından daha ucuzdur.

Çerez alanı ve çıkış anlamları, token tartışmalarından daha fazla acı yaratır

En sıkıcı göç detayları genellikle en yıkıcı olanlardır.

Çerez kapsamı iyi bir örnektir. Ekipler, token standartları ve sağlayıcı yeteneklerine aşırı enerji harcar, ardından .example.com üzerindeki bir eski çerezin auth.example.com üzerindeki yeni bir akışla çakışması veya test ortamında iyi görünen bir SameSite ayarının, çapraz alt alan yönlendirmeleri devreye girdiğinde farklı davranmasıyla aniden kör kalır.

Eski sistemler zamanla tuhaf varsayımlar biriktirir:

• birden fazla uygulama için paylaşılan çerez
• eski bir yönetim yolundan kalan yol kapsamlı çerez
• CSRF davranışı belirli bir oturum çereziyle ilişkilendirilmiştir
• ortamlar arasında tutarsız güvenli bayraklar
• kimlik durumu bir çerez adından okunur ki, kimse bunun emekli edilmesini istemez

Sonra göç, bu parçalardan birini değiştirdiğinde, öylece dağıtım, hayaletlenmiş gibi görünür. Kullanıcılar giriş döngülerine girer. Bir tarayıcı iyi görünürken, diğeri görünmez. Çıkış, bir katmanı temizler ama diğerini bırakır. Oturum yenileme, alt alanlar arasında geçiş yapıldığında yanlış çerezi sıfırlar.

Basit bir uyumluluk tablosu burada birçok acıyı azaltır:

Cookie           Eski Kapsam         Yeni Kapsam            Geçiş Kuralı
legacy_session   .example.com      emekli              yalnızca karma modda kabul
app_session      app.example.com   app.example.com      birincil tarayıcı oturumu
refresh_token    auth.example.com  auth.example.com     httpOnly, güvenli, dar yol
device_trust     .example.com      app.example.com      yalnızca düşük riskli MFA tahammülü için kullanılır

O tablo gösterişli değildir. Operasyonel olarak faydalıdır.

Aynışekilde, çıkış anlamları da aynı şekilde işlemektedir. Birçok sistem “çıkış” işlemini tek bir eylem olarak ele alırken, aslında birçok farklı eylem vardır:

• mevcut tarayıcı oturumundan çıkış
• sadece mevcut uygulamadan çıkış
• tüm cihazlarda tüm uygulamalardan çıkış
• şifre sıfırlama sonrasında tüm oturumları iptal etme
• şüpheli giriş tespiti sonrası sadece yüksek riskli oturumları iptal etme

Ürün, backend ve destek hangi birinin nerede var olduğunu eşit bilmediğinde, kullanıcılar hemen tutarsızlığı hissedecektir.

Cihaz güveni, göçlerin hem UX’i hem de güvenliği gizlice zedelediği yerdir

Kimlik doğrulama göçlerinin en az tartışılan kısımlarından biri cihaz güvenidir, bu garip çünkü burası kullanıcıların göçü en doğrudan hissettiği yerdir.

Eski sisteminiz “bu cihazı hatırla” semantikası, MFA tahammül süreleri veya hassas eylemler için step-up kuralları içeriyorsa, yeni sistem yalnızca başarılı bir kimlik doğrulaması sağlamakla kalmamalıdır. Bu güven sınırlarını korumalı veya kasıtlı olarak yeniden tanımlamalıdır.

Burada takımlar genellikle sorun yaşıyor.

Bazen yeni sistem kazara daha zayıf hale gelir. Güven durumunun temiz bir şekilde göç etmemesi, ancak kimsenin bunu fark etmemesi. Çünkü oturum açma hala çalışır.

Bazen yeni sistem kazara daha sert hale gelir. Daha önce güvenilir cihazlarda kullanıcılar, çoğunlukla stabil olan iş akışlarında sürekli MFA zorluğu veya step-up istemleri ile karşı karşıya kalır.

Bu sonuçlar hiç de iyi değildir.

Aşağıdaki sorulara kesin yanıtlar almalısınız:

• Hatırlanan cihaz durumu göç eder mi yoksa sıfırlanır mı?
• Cihaz güveni her tarayıcı, uygulama veya kimlik sağlayıcısına göre mi tanımlıdır?
• Geçerli bir oturumda bile hangi eylemler step-up kimlik doğrulaması gerektiriyor?
• E-posta veya şifre değişikliğinde hatırlanan cihaz durumu iptal olur mu?
• Şüpheli giriş incelemesi aktif oturumları nasıl etkiler?

Eğer yanıt “yeni sağlayıcı muhtemelen bunu halleder” ise, bu bir uyarı işareti. Sağlayıcılar mekanizmaları yönetir. Eski ürününüze özgü güven modelinizi otomatik olarak korumazlar.

Pratikte, göçün açık ve biraz muhafazakâr olmasını tercih ederim, içsel olarak tutarsız, yapay bir şekilde kesintisiz olmasındansa. Eğer güvenilir cihaz taşınabilirliği karmaşık hale geliyorsa, buna açıkça belirtin, sıfırlayın bir kez ve kurtarma yolu net hale getirin. Bu genellikle, sürekliliğin var olduğu izlenimini vermekten daha iyidir.

Örnek: Bir Laravel uygulamasını klasik oturumlardan SPA ve API kimlik doğrulamasına geçirme

Bu, en yaygın tam yığın göç yollarından biridir.

Bir Laravel uygulaması, oturum tabanlı kimlik doğrulama ve sunucu tarafından oluşturulan sayfalarla başlar. Ardından ekip, bir SPA, mobil istemciler veya üçüncü taraf entegrasyonlar ekler. Tartışma hızla Sanctum, Passport, bearer token’lar, yenileme akışları ve API koruyucuları etrafında döner.

Bu tartışma genellikle erken aşamada yapılır.

Daha iyi bir başlangıç sorusu, “Hangi kimlik doğrulama yığını üzerinde standartlaşmalıyız?” değil, “Tarayıcı, API ve mobil istemcilerin bir arada bulundukları sürede hangi oturum davranışları tutarlı kalmalıdır?” olmalıdır.

Makul bir aşamalı tasarım şu şekilde olabilir:

// Aşama 1
// Tarayıcı, oturum esaslı kalır.
// Aynı kökenli API çağrıları mevcut oturuma güvenebilir.

// Aşama 2
// Mobil ve harici istemciler token-tabanlı kimlik doğrulama benimser.
// İptal, oturum ve token katmanları arasında bağlantılıdır.

// Aşama 3
// Hassas eylemler step-up kimlik doğrulama gerektirir.
// Kullanıcılar aktif oturumlar ve cihazlar hakkında görünürlük kazanır.

// Aşama 4
// Eski koruyucular ve uyumluluk dalları emekli edilir.

Önemli olan, bunun tek doğru sıra olmadığıdır. Önemli olan, iptal, oturum görünürlüğü, çıkış ve sıfırlama davranışlarının mimari değişirken tutarlı kalmasıdır.

Burada yaygın bir Laravel spesifik hata durumu, son derece farklı iki gerçeğe ulaşmaktır:

• tarayıcı, sunucu oturum durumunun otoriter olduğunu düşünmektedir
• API katmanı, token’ların otoriter olduğunu düşünmektedir

Bu, kullanıcıların bir yüzeyde “giriş yapılmadı” durumuna düşmesine ve diğer yüzeyde ise hala etkin olarak görünmesine neden olur. Eğer hibrid auth’a geçiyorsanız, iptal semantiklerini erken bir şekilde bağlayın ya da dağıtımla birlikte çelişkiler açıklarken vakit harcayacaksınız.

Örnek: Çapraz alt alan SSO göçleri, iptal belirsiz kaldığında başarısız olur

Şimdi daha geniş bir tam yığın yapılandırmasına bakalım:

• app.example.com ürün için
• admin.example.com iç araçlar için
• billing.example.com hesap yönetimi için
• auth.example.com yeni merkezi kimlik hizmeti olarak

Kağıt üzerinde, kimliği merkezi hale getirmek basit bir iyileşme gibi görünüyor. Pratikte, oturum açma federasyonu genellikle kolay kısımdır. Çıkış ve iptal ise, karmaşık hale gelir.

Dağıtımdan önce, şu sorulara net yanıtlar almanız gerekir:

• Bir uygulamadan çıkış yapmak, tüm uygulamalardaki oturumları bitirir mi?
• Yerel çıkış hala herhangi bir yerde kabul edilir mi?
• İptal olayları nasıl iletilir?
• Bir uygulama merkezi kimlik hizmeti ile teması kaybederse ne olur?
• Eski uygulama özel çerezleri ne zaman kabul edilmez?

Basit bir olay bazlı model genelde merkezî kimlik durumunu her uygulamanın farklı yorumlamasını sağlamaktan daha güvenlidir.

{ 
  "events": [ 
    "auth.session.revoked", 
    "auth.password.changed", 
    "auth.mfa.reset", 
    "auth.account.locked"
  ] 
}

Her uygulama, bu olaylara öngörülebilir bir şekilde yanıt verebilir ve bunları yerel davranışa dönüştürebilir. Bu, her ürün alanının “oturum iptal edildi” için kendi anlamını icat etmesinden çok daha iyidir.

Anahtar nokta, SSO göçlerinin öncelikle bir token üretme problemi olmadığını, paylaşılan oturum semantikleri sorunu olduğunu anlamasıdır.

Dağıtımdan önce test edilmesi gerekenler ve varsayımlarınızın durması gerekenler

Çoğu auth migration test planı çok sığdır. Girişi sağlamayı kanıtlar ve sonra geçer.

Bu yeterli değildir.

Ciddi bir göç test yüzeyi oturum yaşam döngüsü davranışlarını denemelidir: giriş, yenileme, çıkış, iptal, şifre sıfırlama, e-posta doğrulama, MFA zorluğu, step-up kimlik doğrulaması ve şüpheli giriş yakalama. Ayrıca uyumluluk davranışlarını test etmelidir: eski oturumların yeni yolları kullanması, yeni oturumların eski hizmetleri kullanması, tarayıcıların hem eski hem de yeni çerezleri taşıması, karma sürümlü mobil istemciler ve çapraz alt alan yönlendirmeleri.

Risk testi de önemlidir. Yetkiler oturum devam ederken değişirse ne olur? Bir yönetici taklit oturumu açıkken diğer sekmede ne olur? Bir kullanıcı mobil cihazdan şifre sıfırlarken tarayıcı oturumu hala aktifse ne olur? İşte göçün sağlam olup olmadığını veya sadece yüzeysel olarak başarılı olup olmadığını belirleyen durumlar bunlardır.

Daha da önemlisi, bu şeylerin “muhtemelen iyi” olduğunu varsayımlarınızı bırakın:

• çıkış her yerdе aynı anlama gelmiyor
• bir tarayıcı bir oturum anlamına gelir
• mobil istemciler yeterince hızlı güncellenecek
• cihaz güven durumu temiz bir şekilde göç eder
• sağlayıcı varsayımları mevcut ürün davranışınızı karşılıyor
• token tabanlı kimlik doğrulama otomatik olarak iptali basitleştirir

Çoğu zaman, bunların hiçbiri varsayılan olarak güvenli değildir.

Çoğu ekibin öncelikli olarak yapması gerekenler

Eğer bir auth migration planlıyorsanız, yeni giriş ekranları veya sağlayıcı pazarlama kontrol listeleri ile başlamayın.

Öncelikle mevcut oturum modelini dürüst bir şekilde yazın. Oturumların nasıl sona erdiğini tanımlayın, sadece nasıl başladıkları değil. Her ilgili uygulama yüzeyi boyunca çerez alanını belgeleyin. Eski ve yeni nesnelerin dağıtım sırasında nasıl bir arada duracağını karar verin ve o uyumluluğun ne zaman sona ereceğine karar verin. Cihaz güveni ve MFA semantikleri açıkça belirtin. Ardından iptal ve kurtarma akışlarını, girişten daha zor bir şekilde test edin.

Bu sıralama sıkıcıdır, işte bu yüzden işe yarar.

Pratik karar kuralı basit: eğer bir oturumun her istemcide nasıl başladığını, hayatta kaldığını, yükseldiğini, alçaldığını ve öldüğünü açıklayamıyorsanız, auth migration stratejiniz tamamlanmamıştır.

Ekipler, kimlik doğrulama hakkında tartışmayı sever; çünkü bu kısım mimari görünümü vardır. Kullanıcılar ise kimlik doğrulamayı oturum katmanında değerlendirir; çünkü bu kısım daha gerçektir. Bu farkı göz ardı ederseniz, göç size zor yoldan hatırlatacaktır.

Tam yazının tamamını QCode’da okuyun: https://qcode.in/full-stack-auth-migrations-fail-because-session-strategy-gets-ignored/