Erişim anahtarı yenileme hatası, teknik ekibin kendi içinde çözeceği küçük bir kimlik doğrulama problemi değildir. Sipariş alma, stok güncelleme, fiyat aktarımı, ürün senkronizasyonu ve yönetim ekranı verisi aynı bağlantıya dayanıyorsa tek bir yenileme hatası e-ticaret operasyonunun görünmeyen kesinti noktasına dönüşür.

Shopify'ın 28 Ağustos 2026'da duyurduğu değişiklik bu riski doğrudan hedefliyor. Süresi dolan çevrimdışı erişim anahtarlarında yenileme sürecini daha dayanıklı hâle getiren yeni davranış, önceki yenileme anahtarının belirli koşullarda tekrar kullanılmasına izin veriyor. Shopify aynı duyuruda token çiftlerinin atomik biçimde saklanmasını ve aynı mağaza için yenileme işlemlerinin seri yürütülmesini öneriyor.[1] Mesaj nettir: anahtarı almak kadar doğru yenilemek ve doğru kaydetmek de iş sürekliliğinin parçasıdır.

Erişim anahtarı bozulduğunda neden yalnız yönetim ekranı etkilenmez?

Erişim anahtarı, uygulamanın başka bir sistem adına işlem yapmasına izin veren çalışma yetkisidir. Bu yetki kaybolduğunda sorun kullanıcı girişinde görünmeyebilir; arka plandaki otomasyonlar sessizce durur. Siparişleri beş dakikada bir çeken bir servis yeni sipariş göremez. Stok servisi depodaki değişikliği mağazaya yazamaz. Fiyat motoru yeni fiyatı gönderemez. İade sürecindeki durum güncellemesi karşı sisteme ulaşmaz.

Riskin büyüklüğü, aynı kimliğin kaç iş akışını taşıdığıyla artar. Tek erişim anahtarına sipariş, ürün, müşteri ve stok yetkilerinin tamamını bağlayan mimari, arıza alanını genişletir. Bu mimari tercihinin kendisini composable commerce her marka için doğru mu yazısında tarttık. Google'ın OAuth güvenlik rehberi de yetkileri ihtiyaç oldukça ve mümkün olan en dar kapsamla istemeyi öneriyor.[4] Microsoft'un kimlik platformu dokümantasyonu da yenileme anahtarlarının hassas veri olarak ele alınmasını istiyor.[5] Operasyon yöneticisinin sorusu bu yüzden “API çalışıyor mu?” olmamalıdır. Daha doğru soru şudur: “Bu kimlik bilgisi bugün kullanılamazsa hangi ticari süreçler durur, hangileri güvenli biçimde devam eder?”

Süresi dolan erişim anahtarı ile yenileme anahtarı arasındaki fark neden önemlidir?

Kısa ömürlü erişim anahtarı sızma riskini sınırlar; yenileme anahtarı ise uygulamanın yeniden kullanıcı müdahalesi istemeden yeni erişim anahtarı almasını sağlar. Shopify, 20 Mart 2026 tarihli duyurusunda yeni herkese açık uygulamalar için süresi dolan çevrimdışı erişim anahtarlarına geçişi açıkladı ve kısa ömürlü erişim anahtarının yaklaşık 60 dakikalık sızıntı penceresi oluşturduğunu belirtti.[2] Bu güvenlik kazanımı, yenileme mekanizmasını operasyon açısından daha önemli hâle getiriyor.

Temsili bir hesap düşünelim. Bir entegrasyon her 5 dakikada bir sipariş kontrol ediyor ve erişim anahtarı 60 dakika geçerli. Yenileme 10.00'da başarısız olur, fakat sistem yalnız 16.00'da alarm üretirse 6 saatlik bir körlük oluşur. Bu sürede 72 kontrol çevrimi başarısız olur: 6 saat × 12 kontrol = 72. Buradaki 72 bir pazar verisi değil, mekanizmayı göstermek için oluşturulmuş örnektir. Yönetim açısından değerli olan sayı, hatanın kaç kez tekrarlandığı değil, ilk başarısızlık ile müdahale arasındaki süredir. Kısa ömür güvenliği artırır; kötü yenileme tasarımı ise kesinti olasılığını artırır. İki karar birlikte verilmelidir.

Shopify'ın 28 Ağustos değişikliği hangi hata sınıfını azaltıyor?

Yeni davranış özellikle “yeni token'ı aldım fakat güvenli biçimde kaydedemedim” türündeki kesintilere karşı toparlanma alanı açıyor. Shopify'ın açıklamasına göre önceki yenileme anahtarı, onun yerine verilen yeni anahtar kullanılmaya başlanana kadar tekrar denenebiliyor. Yenileme yanıtı ağ hatası veya kayıt problemi yüzünden kaybolursa uygulama aynı eski anahtarla yeniden deneme şansına sahip oluyor.[1]

Bu tolerans sınırsız değildir. Shopify, kurtarma penceresini ilk kullanımdan itibaren en fazla 30 günle sınırlandırıyor ve normal yenileme anahtarının 90 günlük ömrünü aşan bir uzatma vermiyor.[1] Bu iki süre “nasıl olsa eski token çalışır” rahatlığı üretmemelidir. Amaç, dağıtık sistemlerde kaçınılmaz olan ağ ve yazma hatalarına kontrollü geri dönüş yolu sağlamaktır.

İkinci temsili hesapta, uygulama 1.000 mağaza bağlantısı yönetiyor olsun. Günlük yenilemelerin yalnız %0,2'sinde veritabanına yazma hatası oluşsa günde 2 bağlantı riskli duruma düşer: 1.000 × %0,2 = 2. Yeni davranış bu iki hatayı otomatik olarak çözmez; tekrar denemeyi mümkün kılar. İzleme yoksa kurtarma yolu kullanılmadan kesinti devam eder. Bu sayılar benchmark değildir; hata oranının küçük görünmesinin büyük bağlantı sayısında neden yeterli güvence olmadığını gösterir.

Token çiftini atomik kaydetmek neden veritabanı ayrıntısı değil, operasyon kuralıdır?

Erişim anahtarı ile yenileme anahtarı aynı yenileme işleminin iki parçasıdır. Biri yeni, diğeri eski kalırsa sistem kendi kimlik durumunu tutarsızlaştırır. Shopify bu nedenle token çiftinin tek işlem içinde, yani ya tamamen kaydedilecek ya da hiç kaydedilmeyecek biçimde saklanmasını öneriyor.[1]

Örneğin veritabanı önce yeni erişim anahtarını kaydedip sonra çökerse, yenileme anahtarı eski kalabilir. Tersi durumda yeni yenileme anahtarı yazılır fakat eski erişim anahtarı kullanılır. Her iki senaryoda da sorun ilk anda görünmeyebilir. Bir sonraki yenileme geldiğinde uygulama hangi çiftin geçerli olduğunu ayırt etmekte zorlanır.

Aynı mağaza için eş zamanlı iki yenileme isteği de benzer yarış koşulu yaratır. Shopify, yenilemeleri mağaza bazında sıraya koymayı öneriyor.[1] Bu, yüksek trafik altında “daha fazla paralellik daha iyidir” refleksinin doğru olmadığı bir alandır. Kimlik durumunda sıralı işlem, hızdan önce tutarlılığı korur.

Gizli anahtarı döndürmek neden erişim anahtarını yenilemekten ayrı planlanmalıdır?

Uygulama gizli anahtarı ile erişim anahtarı aynı şey değildir. Gizli anahtar, uygulamanın kendi kimliğini kanıtlayan daha kök bir bilgidir; erişim ve yenileme anahtarları ise belirli yetkilendirme akışının sonucudur. Shopify'ın kimlik bilgisi yönetimi dokümantasyonu, gizli anahtarların güvenli saklanmasını ve dönüşüm sırasında eski-yeni anahtar geçişinin dikkatle yönetilmesini ister.[3]

Google da OAuth istemci kimlik bilgileri ve kullanıcı token'larının düz metin olarak saklanmamasını, erişimin kısıtlanmasını ve gerektiğinde iptal mekanizması bulunmasını öneriyor.[4] IETF'nin OAuth 2.0 Security Best Current Practice belgesi, yenileme anahtarlarının saldırgan için değerli hedef olduğunu ve istemci türüne göre koruma mekanizmaları gerektiğini tanımlıyor.[6]

Bunun operasyonel karşılığı iki ayrı çalışma planıdır. Birincisi rutin token yenilemesidir. İkincisi istemci gizli anahtarı sızması, çalışan değişikliği, altyapı geçişi veya periyodik güvenlik politikası nedeniyle yapılan secret rotation işlemidir. İkisini aynı prosedür gibi yönetmek, olay anında yanlış anahtarın iptal edilmesine ve çalışan entegrasyonların topluca kesilmesine yol açar.

Hangi alarm, kesintiyi müşteri fark etmeden önce yakalar?

En faydalı alarm “token yenileme başarısız” mesajı değildir; ticari akışın beklenen ritimden koptuğunu gösteren alarmdır. Kimlik hatası teknik kök nedendir. Operasyonun gördüğü sonuç ise sipariş aktarımının gecikmesi, stok güncellemesinin durması veya webhook sonrası yazma işleminin reddedilmesidir. Bu nedenle en az dört zaman damgası tutulmalıdır: son başarılı yetkilendirme, son başarılı veri okuma, son başarılı veri yazma ve ilk başarısız yenileme. Bu dört kayıt, “entegrasyon ayakta” gibi tek bitlik sağlık bilgisinden daha değerlidir. Sistem token alıyor fakat sipariş okuyamıyorsa kimlik katmanı sağlıklı sayılmaz. Karar eşiği de iş akışına göre değişir. Stok fiyatlaması dakikalık çalışıyorsa 30 dakikalık sessizlik ciddi sapmadır. Gece çalışan katalog senkronizasyonunda aynı 30 dakika anlamsız olabilir. Alarm eşiği teknik bileşene değil, taşıdığı sürecin hizmet seviyesine bağlanmalıdır.

Bağlantı türü	İlk izlenecek sinyal	Müdahale eşiği	Güvenli ilk hareket
Sipariş aktarımı	Son başarılı sipariş çekimi	Sipariş SLA'sını aşan sessizlik	Yeni yazmayı durdur, kimlik ve kuyruk durumunu doğrula
Stok senkronizasyonu	Son başarılı stok yazımı	Kanal stok toleransını aşan gecikme	Riskli SKU'larda güvenlik stoğu kuralını devreye al
Fiyat aktarımı	Son başarılı fiyat güncellemesi	Planlı fiyat penceresinin kaçırılması	Eski fiyatın geçerliliğini koru, toplu yeniden yazma yapma
Müşteri/CRM akışı	Yetki hatası oranı	Normal hata bandının üzeri	Kapsamı ve token durumunu incele, veriyi yeniden isteme
Yönetim raporu	Veri tazelik zamanı	Karar periyodundan eski veri	Raporu “güncel” diye sunma, veri kesintisini işaretle

Yetki kapsamı neden kesintinin etki alanını belirler?

Bir token yalnız “geçerli” veya “geçersiz” değildir; hangi kaynaklara hangi işlemlerle erişebildiği de riskin parçasıdır. Salt okunur katalog raporu ile sipariş durumunu değiştirebilen entegrasyon aynı kapsamla çalışmamalıdır. Google, OAuth izinlerinde kullanıcının ihtiyacı kadar erişim istemeyi ve yeni işlev gerektiğinde ek yetki talep etmeyi öneriyor.[4] Bu yaklaşım erişim anahtarı sızdığında veya yanlış servis tarafından kullanıldığında etki alanını daraltır.

E-ticaret mimarisinde pratik ayrım süreç bazında kurulabilir. Sipariş toplama servisi sipariş okumaya, stok servisi ilgili envanter yazımına, raporlama katmanı ise mümkünse salt okunur verilere erişir. Bu ayrımın ticari tarafını agentic commerce için e-ticaret altyapısının nasıl hazırlanacağı yazısında anlattık. Bir servis arızalandığında diğerlerinin kimlik bilgisini topluca iptal etmek gerekmez. Tek token altında her şeyi birleştiren yapı operasyonu kurmayı kolaylaştırır; olay yönetimini zorlaştırır. Bu tercih başlangıçta birkaç saat kazandırıp ilk gerçek kesintide günlerce belirsizlik üretebilir.

Temsili bir etki hesabı yapalım. Beş iş akışının tek kimlik bilgisine bağlı olduğunu ve bunlardan yalnız birinde güvenlik olayı çıktığını varsayın. Ortak token iptal edilirse 5 akışın 5'i durur. Her akış ayrı ve dar kapsamlı kimlikle çalışıyorsa yalnız etkilenen servis durdurulabilir; teorik kesinti alanı %100'den %20'ye iner. Bu oran gerçek sistem performansı değil, bağımlılık mimarisinin etkisini göstermek için kurulmuş bir örnektir.

Yenileme prosedürü neden test ortamında bozulmadan önce bozulmalıdır?

Kimlik akışı yalnız üretimde gerçek süre dolduğunda sınanıyorsa ekip aslında bir prosedüre değil umuda güveniyor demektir. Süre sonu, ağ kesintisi, veritabanı yazma hatası, aynı anda iki yenileme isteği, eski secret'ın iptali ve geri alma senaryoları kontrollü testte ayrı ayrı çalıştırılmalıdır. Testin amacı her hatayı engellemek değil, sistemin hangi hatada hangi güvenli davranışı verdiğini önceden bilmektir.

Özellikle yenileme yanıtını aldıktan sonra veritabanına yazamama senaryosu önemlidir. Shopify'ın 28 Ağustos değişikliği tam bu aradaki boşluğa dayanıklılık ekliyor.[1] Fakat uygulama başarısız yazmayı kaydetmiyor veya aynı mağaza için paralel yenilemeleri serbest bırakıyorsa platformun sağladığı kurtarma alanı yine boşa çıkar. Platform davranışı, uygulama tasarımının yerini tutmaz.

Üretim öncesi testten sonra runbook da teknik ekibin zihninde kalmamalıdır. Hangi alarm kime gider, ilk 15 dakikada hangi kayıtlar kontrol edilir, hangi secret iptal edilir, kuyruk nasıl dondurulur ve veri uzlaştırması ne zaman tamamlanmış sayılır yazılı olmalıdır. Çünkü gerçek kesintide en pahalı süre, çözümü uygulamak değil kimin ne yapacağına karar vermek için harcanan süredir.

Hata sonrası toparlanma neden “yeniden bağla” düğmesinden ibaret değildir?

Bağlantıyı yeniden yetkilendirmek yalnız gelecekteki çağrıları düzeltir. Kesinti sırasında biriken siparişler, kaçırılan güncellemeler ve yarım kalan işlemler ayrıca uzlaştırılmalıdır. Aksi hâlde teknik ekip bağlantıyı yeşile çevirir fakat ticari kayıtlar eksik kalır. Toparlanma sırası veri türüne göre kurulmalıdır. Önce idempotent, yani tekrarlandığında ikinci kez ticari sonuç üretmeyen işlemler geri oynatılır. Ardından sipariş, ödeme veya iade gibi çift kayıt riski taşıyan hareketler tekil kimliklerle karşılaştırılır. Kuyrukta 500 olay varsa hepsini bir anda yeniden çalıştırmak ikinci bir arıza yaratabilir. Kontrollü parti, oran sınırlaması ve hata karantinası gerekir.

Yönetici için kapanış ölçütü “API 200 dönüyor” değildir. Son başarılı işlem zamanı normale döndü mü, kesinti aralığındaki kayıtların tamamı uzlaştırıldı mı, çift kayıt oluşmadı mı ve kök neden tekrarını önleyecek değişiklik kayda geçti mi? İş sürekliliği burada biter.

Olay sonrası hangi kanıt saklanmadan sistem yeniden açılmamalıdır?

Kimlik sorunu düzeldiğinde servisleri hemen normale döndürmek caziptir; fakat kök neden kanıtı kaybolursa aynı hata tekrarlandığında ekip yeniden başa döner. En az başarısız yenileme zamanı, dönen hata kodu, kullanılan token sürümü, veritabanı yazım sonucu, aynı mağaza için eş zamanlı istek olup olmadığı ve yeniden yetkilendirme adımı olay kaydında tutulmalıdır. Hassas token değerlerinin kendisi loga yazılmamalıdır; yalnız güvenli kimlik veya sürüm referansı kaydedilmelidir. Google'ın OAuth güvenlik yaklaşımı kimlik bilgilerini korumayı, Shopify ise token çiftlerini tutarlı ve atomik saklamayı öneriyor.[1][4]

Olay kapatma kriteri de teknik geri dönüşten daha geniş olmalıdır. Kesinti aralığında sipariş, stok ve fiyat kuyrukları uzlaştırılmadan “çözüldü” durumu verilirse sistem yeşil görünürken ticari veri eksik kalır. Örneğin 240 siparişlik bir kuyruk 20'şerli partilerle doğrulanıyorsa 12 kontrol grubu oluşur: 240 / 20 = 12. İlk 11 grup başarılı olup son grupta çift kayıt görülürse bağlantı sağlıklı olsa bile olay kapanmaz. Bu sayılar temsili operasyon hesabıdır. Son adım tekrar önleme kaydıdır. Alarm eşiği, rotasyon prosedürü, token saklama veya seri yenileme kuralından hangisi değiştirildiyse yeni sürüm ve sorumlusu belirtilmelidir. Böylece olay notu arşiv değil, bir sonraki entegrasyon tasarımına geri besleme olur.

Kimlik bağımlılığı mimari diyagramda nasıl görünür hâle getirilmelidir?

API kutularını çizmek yetmez; hangi servis hangi token'a, hangi kapsamla ve hangi yenileme sahibine bağlı açıkça gösterilmelidir. Tek kimlik bilgisinin beş iş akışını taşıdığı mimari ile beş bağımsız yetki alanı aynı teknik diyagramda farklı risk profili oluşturur. Diyagramda token sahibi servis, secret saklama noktası, yenileme kuyruğu ve başarısızlıkta duracak akışlar işaretlenirse olay anında bağımlılık aramak için zaman kaybedilmez. Bu belge değişiklik yönetiminde de güncellenmeli; yeni entegrasyon gizlice eski token'a bağlanmamalıdır.

Bu ne zaman geçersiz?

Tek kullanıcılı, salt okunur ve ticari işlem üretmeyen küçük bir iç araçta kapsamlı kurtarma orkestrasyonu gereksiz olabilir. Uygulama haftada bir rapor çekiyor, veri kaynağını değiştirmiyor ve kesinti müşteriye yansımıyorsa daha hafif bir yenileme ve alarm modeli yeterlidir. Risk, işlevin önemine göre ölçülmelidir.

Aynı şekilde her erişim anahtarını kısa ömürlü yapmak tek başına güvenlik sağlamaz. Yenileme anahtarı düz metin tutuluyorsa, kapsamlar gereğinden genişse veya eski secret'lar iptal edilmiyorsa kısa erişim süresi yalnız saldırı yüzeyinin bir parçasını küçültür. Kimlik yönetimi; saklama, kapsam, rotasyon, izleme ve olay müdahalesi birlikte tasarlandığında anlam kazanır.

Roilab değerlendirmesi

Roilab erişim anahtarını teknoloji ekibinin izole konusu olarak değil, taşıdığı ticari süreçlerin bağımlılığı olarak değerlendirir. Önce bağlantının hangi sipariş, stok, fiyat, müşteri ve raporlama akışlarını etkilediği çıkarılır. Sonra yetki kapsamı, yenileme davranışı, alarm eşiği, geri oynatma planı ve sorumluluk zinciri aynı işletim modeline bağlanır. İyi entegrasyon yalnız normal zamanda hızlı çalışan entegrasyon değildir. Kimlik bilgisi yenilenemediğinde neyi durduracağını, neyi koruyacağını ve eksik işlemleri nasıl geri kazanacağını bilen entegrasyondur.

Başvurun, değerlendirelim.

Kaynaklar

[1] Shopify Developers, More resilient refreshes for expiring offline access tokens, 28 Ağustos 2026 — https://shopify.dev/changelog/more-resilient-refreshes-for-expiring-offline-access-tokens

[2] Shopify Developers, Expiring offline access tokens required for new public apps April 1, 2026, 20 Mart 2026 — https://shopify.dev/changelog/expiring-offline-access-tokens-required-for-public-apps-april-1-2026

[3] Shopify Developers, Manage client credentials, güncel dokümantasyon, erişim 10 Eylül 2026 — https://shopify.dev/docs/apps/build/authentication-authorization/manage-credentials

[4] Google for Developers, OAuth 2.0 Policies and Best Practices, güncel dokümantasyon, erişim 10 Eylül 2026 — https://developers.google.com/identity/protocols/oauth2/resources/best-practices

[5] Microsoft Learn, OAuth 2.0 and OpenID Connect protocols on the Microsoft identity platform, güncel dokümantasyon, erişim 10 Eylül 2026 — https://learn.microsoft.com/en-us/entra/identity-platform/v2-protocols

[6] IETF, RFC 9700: Best Current Practice for OAuth 2.0 Security, Ocak 2025; sayfa güncellemesi 20 Mayıs 2026 — https://datatracker.ietf.org/doc/rfc9700/