--- url: 'https://www.corbado.com/tr/blog/gecis-anahtari-2-gun-sorunlari' title: 'Geçiş Anahtarı 2. Gün Sorunları: Lansman Sonrası 5 Risk' description: 'Geçiş anahtarları, yanlış uygulanmadıkları sürece harikadır. Kurtarma, cihazlar arası UX, yerel uygulamalar, benimseme ve platform değişiklikleriyle ilgili beş 2. gün sorununu öğrenin.' lang: 'tr' author: 'Vincent Delitz' date: '2026-05-27T11:04:58.316Z' lastModified: '2026-05-27T11:06:20.838Z' keywords: 'geçiş anahtarı 2. gün sorunları, geçiş anahtarı operasyonel zorlukları, lansman sonrası geçiş anahtarı riskleri, geçiş anahtarı üretim sorunları, geçiş anahtarı uygulanmalı mı' category: 'Passkeys Strategy' --- # Geçiş Anahtarı 2. Gün Sorunları: Lansman Sonrası 5 Risk ## Key Facts - **Düşük benimseme**, en yaygın başarısızlık nedenidir: Lansman stratejisini atlayan işletmeler, teknik olarak sağlam uygulamalara rağmen geçiş anahtarı kullanımını %5'in altında görür ve bu da tüm mühendislik yatırımını boşa çıkarır. - **Kurtarma geri dönüş tasarımı**, oltalama riskini yeniden mi sunacağınızı yoksa kullanıcıları geniş ölçekte sistem dışında mı bırakacağınızı belirler. Saldırgan gelen kutusunu kontrol ediyorsa, e-posta tabanlı sıfırlamalar oltalama direncine sahip geçiş anahtarlarını tamamen atlar. - **Platform değişiklikleri**, `isUserVerifyingPlatformAuthenticatorAvailable()` işlevinin Safari dışındaki tüm tarayıcılarda false döndürdüğü iOS 26.2 hatasının gösterdiği gibi geçiş anahtarlarını sessizce bozar ve algılama mantığı güncellemeleri gerektirir. - **Yerel uygulama karmaşıklığı**, platforma özgü hata kodları ve acil geçiş anahtarı gerileme düzeltmelerini engelleyen uygulama mağazası inceleme döngüleri ile web, iOS ve Android'de QA yüzeyini üç katına çıkarır. ## 1. Giriş: Lansman Sonrası Geçiş Anahtarı Riskleri **Geçiş anahtarlarını uygulamayın.** En azından ne pahasına olursa olsun değil ve eğer bunu düzgün yapacak kaynaklarınız yoksa. Evet, geçiş anahtarları son on yılda tüketici kimlik doğrulamasının başına gelen en iyi şeydir. Evet, oltalamayı (phishing) bitirirler. Evet, kullanıcı deneyimini (UX) muazzam ölçüde iyileştirebilirler. Ancak yanlış uygulanan geçiş anahtarları da çok fazla zarara neden olabilir. Bir WebAuthn sunucusu uygulamak çok karmaşık değildir. Asıl zorluk bunun etrafındaki her şeydir. Geçiş anahtarlarını geniş ölçekte verimli bir şekilde işletmek önceden planlama yapmayı gerektirir. Tüm "2. Gün" sorunlarını, yani yalnızca geçiş anahtarı lansmanına başladıktan sonra ortaya çıkan operasyonel gerçekleri düşünmeniz gerekir. Bu makale, geçiş anahtarı projelerini sürekli olarak sonlandıran beş 2. gün sorununu ele almaktadır. Eğer bunların hepsini çözemiyorsanız, geçiş anahtarlarını yayınlamaya hazır değilsiniz demektir. Eğer çözebilirseniz, parolaların sunabileceğinden hem daha güvenli hem de daha kullanışlı bir kimlik doğrulama sistemi kurmuş olursunuz. ## 2. Geçiş Anahtarı 2. Gün Sorunları Nelerdir? Mühendislikte "1. Gün", inşa edip yayına aldığınız zamandır. "2. Gün" ise yayına aldığınız şeyi işlettiğiniz, bakımını yaptığınız ve ölçeklendirdiğiniz zamandır. Geçiş anahtarları için 1. Gün basit olabilir: - Kurumsal teknoloji yığınınıza bir WebAuthn sunucusu entegre edin - Ön yüz akışlarını ekleyin ve başlatın. Çoğu ekip, temel bir geçiş anahtarı uygulamasını birkaç gün veya hafta içinde çalışır hale getirebilir. Projelerin başarısız olduğu yer 2. Gün'dür. Gerçek uç durumları olan gerçek cihazlardaki gerçek kullanıcıların geçiş anahtarı sisteminizle etkileşime girdiği andır. MacBook'unuzda mükemmel çalışan o parlak demonun, kurumsal bir proxy arkasında Chrome çalıştıran bir Windows dizüstü bilgisayarda bozulduğunu keşfettiğiniz zamandır. Destek ekibinizin "Artık giriş yapamıyorum" biletleriyle dolup taştığı zamandır. Çalışan bir geçiş anahtarı demosu ile üretim düzeyinde bir geçiş anahtarı dağıtımı arasındaki uçurum devasa boyuttadır. Teknik uygulama tuzaklarını ve geçiş anahtarı projelerinin başarısız olmasının stratejik nedenlerini daha önce ele almıştık. Bu makale, operasyonel bir perspektiften yayına girdikten sonra tam olarak ne olduğuna odaklanmaktadır. İşte ele alacağımız beş 2. gün sorunu: - [Sorun 1: Kurtarma ve Geri Dönüş akışlarını güvenli hale getirmek zordur](#3-issue-1-recovery-and-fallback-are-hard-to-secure) - [Sorun 2: Cihazlar Arası ve Ekosistemler Arası Uç Durumlar Geçiş Anahtarı Akışlarını Bozar](#4-issue-2-cross-device-and-cross-ecosystem-edge-cases-break-passkey-flows) - [Sorun 3: Yerel Uygulamalar Geçiş Anahtarı Karmaşıklığını Çoğaltır](#5-issue-3-native-apps-multiply-passkey-complexity) - [Sorun 4: Benimseme bir Teknoloji Sorunu değil, bir Ürün Sorunudur](#6-issue-4-adoption-is-a-product-problem-not-a-tech-problem) - [Sorun 5: Platform Değişiklikleri Geçiş Anahtarlarını sessizce bozar](#7-issue-5-platform-changes-break-passkeys-silently) ## 3. Sorun 1: Kurtarma ve Geri Dönüş akışlarını güvenli hale getirmek zordur Kurtarma ve geri dönüş süreçlerini düzgün bir şekilde tasarlamazsanız, kullanıcıları geniş ölçekte sistem dışında bırakırsınız veya ortadan kaldırmak istediğiniz oltalama yapılmaya müsait akışları sessizce yeniden sunarsınız. ### 3.1 Geniş Ölçekte Hesap Kilitlenme Riski iPhone'unda bir geçiş anahtarı oluşturan ve ardından o iPhone'u kaybeden bir kullanıcıyı ele alalım. Genellikle, bu kurtarma vakalarının büyük bir kısmı artık kimlik bilgisi yöneticisi (büyük ihtimalle iPhone'larda iCloud Keychain) tarafından ele alınmaktadır. Kullanıcı Apple hesabına erişebildiği sürece, yeni bir cihazda giriş yapmak için kullanılabilecek senkronize edilmiş geçiş anahtarlarına sahiptir. Peki ya o bulut hesabına artık erişimleri yoksa? İşte o zaman normal kurtarma yolunuz devreye girer. Diyelim ki, özel anahtarın kullanıcının giriş yapmaya çalıştığı cihazda hala mevcut olduğunu varsayıyorsunuz, bu nedenle WebAuthn giriş seremonisini başlatıyorsunuz. Bu, kullanıcının "başka bir cihazdaki geçiş anahtarınızla giriş yapın" demesini isteyen bir işletim sistemi / tarayıcı penceresi ile sonuçlanacaktır. Temel olarak, kullanıcı artık hesabına erişemez. Geçiş anahtarının saklandığı başka bir cihaz yoktur. Kullanıcının kafası çok karışır. Bunu binlerce kullanıcıyla çarptığınızda bir destek kriziniz olur. Ortak tepki, geri dönüş olarak e-posta tabanlı hesap sıfırlamaları eklemektir. Ancak bu, geçiş anahtarlarının amacına aykırıdır: oltalama yapılabilen bir kurtarma kanalını yeniden kullanıma sunmuş oldunuz. Bir kullanıcının e-postasını ele geçirebilen bir saldırgan artık oltalama direncine sahip geçiş anahtarı uygulamanızı tamamen atlayabilir. ### 3.2 Oltalamayı Yeniden Sunmadan Geri Dönüş Tasarlamak Bize göre doğru yaklaşım katmanlı kurtarmadır: 1. **Senkronize geçiş anahtarları** temel strateji olarak: cihaz kaybının kimlik bilgisi kaybı anlamına gelmemesi için kullanıcıların senkronize geçiş anahtarları (iCloud Keychain, Google Password Manager veya üçüncü taraf bir geçiş anahtarı sağlayıcısı aracılığıyla) oluşturmasını sağlayın 2. **Cihazlar arası kimlik doğrulama** ikinci bir katman olarak: kullanıcıların başka bir geçiş anahtarının bulunduğu başka bir cihazdan, bir QR kodu tarayarak kimlik doğrulamasına izin verin 3. **Kimlik doğrulama (IDV)** üçüncü katman olarak: parola/OTP'lere geri dönmek yerine canlılık (liveness) kontrolleriyle otomatik IDV sunun. 4. **Dijital doğrulanabilir kimlik bilgileri (verifiable credentials)** dördüncü katman olarak: hesap kurtarmanın en güvenli, gizliliği koruyan ve UX dostu sürümüdür. Bu, kullanıcının standart API'leri (ör. Digital Credentials API) kullanarak kimliğini doğrulamak için dijital doğrulanabilir kimlik bilgilerini (ör. dijital ulusal kimlik veya mDL) kullanmasına olanak tanır. Bu teknoloji oldukça yenidir ve benimsenmesi çok yüksek değildir ancak önümüzdeki ay ve yıllarda büyük bir rol oynayacaktır. Genel olarak, maliyet / sürtünme perspektifinden hesap kurtarmanın hangi katmanlarının haklı çıkarılabileceğine karar vermeniz gerekir. Örneğin, [perakende](https://www.corbado.com/passkeys-for-e-commerce) / [e-ticaret](https://www.corbado.com/passkeys-for-e-commerce) sektöründe finansal nedenlerle sadece ilk iki katmanı sunabilir ve oltalama riskini kabul edebilirsiniz. Güvenliğin daha önemli olduğu diğer endüstrilerde 3. ve 4. katmanlara geçersiniz. Her katman karmaşıklık katar. Kullanım durumunuzun hangi katmanlara ihtiyaç duyduğuna karar vermeniz, bunları oluşturmanız, tüm cihaz kombinasyonlarında test etmeniz ve kullanımlarını izlemeniz gerekir. Bu, ilk WebAuthn entegrasyonundan çok daha fazla iştir. ### 3.3 Çoğu Ekibin Yanlış Yaptığı Şey Çoğu ekip kurtarma sürecini aşırı basitleştirir (parolalara veya SMS OTP'ye geri dönme) veya aşırı karmaşıklaştırır (örneğin her kurtarma işlemi için donanım güvenlik anahtarları zorunlu kılmak). Doğru denge tehdit modelinize, kullanıcı tabanınıza ve yasal gerekliliklerinize bağlıdır. Yanlış yapmak, ya güvenlik duruşunuzu zayıflatmak ya da kullanıcıların akışı terk edeceği kadar fazla sürtünme yaratmak anlamına gelir. ## 4. Sorun 2: Cihazlar Arası ve Ekosistemler Arası Uç Durumlar Geçiş Anahtarı Akışlarını Bozar Kullanıcılarınız sadece temiz bir Apple dünyasında yaşamazlar. Cihaz değiştirirler, Windows ile iOS'u karıştırırlar, farklı tarayıcılar kullanırlar ve şirket tarafından yönetilen kurulumlarda çalışırlar. Önceden planlamadıysanız geçiş anahtarı akışlarının koptuğu yer burasıdır. ### 4.1 Ekosistem Parçalanması Gerçektir Geçiş anahtarı ekosistemi üç büyük platformu (Apple, Google ve Microsoft), birden fazla tarayıcıyı (Chrome, Safari, Firefox ve Edge), düzinelerce geçiş anahtarı sağlayıcısı / kimlik bilgisi yöneticisini (örneğin 1Password, Bitwarden, Dashlane ve diğerleri) ve sayısız işletim sistemi/tarayıcı/cihaz kombinasyonunu kapsar. Her kombinasyon biraz farklı davranabilir, örneğin: - **Apple** geçiş anahtarlarını varsayılan olarak iCloud Keychain aracılığıyla iOS, iPadOS ve macOS arasında senkronize eder ancak Windows veya Android ile etmez - **Google** Google Password Manager aracılığıyla Android ve Chrome arasında senkronize eder ancak iOS üzerindeki deneyim farklıdır (manuel olarak ayarlamanız gerekir) - **Windows**'un diğer platformlardan önemli ölçüde farklı kendi geçiş anahtarı davranışı vardır - **Parola yöneticileri** her biri geçiş anahtarı oluşturma ve seçimini farklı şekilde ele alır, bazen platforma özgü (native) istemlerle çakışır ### 4.2 Cihazlar Arası Kimlik Doğrulama Akışları Bir kullanıcı iPhone'unda bir geçiş anahtarı oluşturup ancak Windows dizüstü bilgisayarda giriş yapmak istediğinde, cihazlar arası kimlik doğrulama kullanabilir (genellikle bir QR kodu ve Bluetooth aracılığıyla). Bu akış çalışır ancak kırılgan bir yapıya sahiptir: - Her iki cihazda da Bluetooth'un etkinleştirilmiş olmasını gerektirir - Arka planda kurulan bir tünel olduğu için kurumsal güvenlik duvarları ve MDM politikaları engel olabilir - Tarayıcılar arasındaki UX çok farklıdır - Kullanıcılar genellikle ne olduğunu veya neden bir QR kodu taradıklarını anlamazlar Bu uç durumları binlerce cihaz kombinasyonunda ilk elden gördük. Eğer geçiş anahtarlarını şirket içinde geliştiriyorsanız, bunların her birini test etmeniz ve işlemeniz gerekir. Eğer yapamazsanız, kullanıcılarınız destek ekibinizin açıklayamayacağı hatalarla karşılaşacaktır. ### 4.3 Tarayıcı ve İşletim Sistemi Tutarsızlıkları Aynı cihazda bile farklı tarayıcılar farklı davranır. macOS'teki Chrome, macOS'teki Safari'den farklı geçiş anahtarı pencereleri gösterir. Firefox'un kendine özgü bir davranışı vardır. Client hints (İstemci ipuçları) ve user agent (kullanıcı aracısı) algılaması, doğru akışları doğru kullanıcıya sunmak için kritik hale gelir, ancak bunları tüm kombinasyonlar arasında doğru bir şekilde ayrıştırmak, hiç bitmeyen bir bakım yüküdür. ## 5. Sorun 3: Yerel Uygulamalar Geçiş Anahtarı Karmaşıklığını Çoğaltır Geçiş anahtarı testi ve QA zaten web uygulamaları için bir zorluktur (bunu [Sorun 5: Platform Değişiklikleri Geçiş Anahtarlarını sessizce bozar](#7-issue-5-platform-changes-break-passkeys-silently) bölümünde detaylıca ele alıyoruz). Ancak ürününüzün yerel iOS ve Android uygulamaları da varsa, sadece web ile uğraşan ekiplerin asla yüzleşmeyeceği mimari kararlar ve platforma özgü davranışlar nedeniyle karmaşıklık katlanır. ### 5.1 Yerel Uygulama ve WebView Kararları İlk karar, geçiş anahtarlarını yerel (native) olarak mı yoksa bir WebView aracılığıyla mı uygulayacağınızdır. Her yaklaşımın artı ve eksileri vardır: | Yön | Yerel Uygulama (Native) | WebView Uygulaması | | ------------------------- | -------------------------------------- | ------------------------------------------ | | **UX kalitesi** | Sınıfının en iyisi, platforma özgü his | WebView türüne bağlıdır | | **Bakım** | iOS ve Android için ayrı kod tabanları | Paylaşılan web mantığı | | **Platform gereksinimleri** | Apple/Google SDK değişiklikleri izlenmeli| WebView geçiş anahtarı destek sorunları ele alınmalı | | **Karmaşıklık** | Yüksek (platforma özgü API'ler) | Orta (ancak WebView türü önemlidir) | Sadece iOS üzerinde bile, WKWebView, SFSafariViewController, SFAuthenticationSession ve ASWebAuthenticationSession arasında seçim yapabilirsiniz - her birinin farklı geçiş anahtarı destek özellikleri vardır. Android'de, Chrome Custom Tabs, standart WebViews'dan farklı davranır. Bunlar yalnızca web için çalışan ekiplerin asla vermek zorunda kalmadığı kararlardır ve her seçim kendi bakım yüzeyini oluşturur. ### 5.2 Yerel Uygulamalarda Platforma Özgü Davranış Mimari kararın ötesinde, iOS ve Android geçiş anahtarlarını işletim sistemi düzeyinde farklı şekilde işler: - **iOS**, geçiş anahtarlarını her iOS sürümüyle değişebilen belirli otomatik doldurma davranışlarıyla sistem kimlik bilgisi yöneticisine derinden entegre eder - **Android**, geçiş anahtarı isteklerini birden fazla geçiş anahtarı sağlayıcısıyla aynı anda etkileşime giren Credential Manager API aracılığıyla yönlendirir - Hata durumları, zaman aşımı davranışları ve kullanıcı istemleri platformlar arasında farklılık gösterir. Aynı kullanıcı iptali, web'de `NotAllowedError` olarak görünürken iOS'ta `SimpleAuthenticationServices.AuthorizationError` ve Android'in Credential Manager sisteminde `User cancelled the operation` olarak ortaya çıkar - tam bir çapraz platform hata eşlemesi için üretimdeki WebAuthn hatalarına bakın - Uygulama mağazası inceleme döngüleri, geçiş anahtarı gerilemeleri için acil düzeltmeler göndermeniz gerektiğinde gecikmelere neden olur ### 5.3 Üç Katına Çıkan QA Yüzeyi Hem bir web uygulaması hem de yerel uygulamalar çalıştırıyorsanız, sadece QA çabasını ikiye katlamakla kalmıyor aynı zamanda üç katına çıkarıyorsunuz. Web, iOS ve Android'in her biri bağımsız uçtan uca test ve izleme gerektiren ayrı geçiş anahtarı ortamları olarak davranır. Bir düzeltmeyi anında dağıtabildiğiniz web'in aksine, yerel uygulama düzeltmeleri uygulama mağazası inceleme döngüleri tarafından engellenir. ## 6. Sorun 4: Benimseme bir Teknoloji Sorunu değil, bir Ürün Sorunudur "Geçiş anahtarları destekleniyor" demek "geçiş anahtarları kullanılıyor" demek değildir. Eğer bir lansman stratejiniz ve ölçümünüz yoksa, benimsenme oranı hayal kırıklığı yaratacak ve proje dahili olarak başarısızlıkla etiketlenecektir. ### 6.1 Düşük Benimseme Neden Projenizi Öldürür? Bunu geçiş anahtarı uygulamalarının neden başarısız olduğu hakkındaki makalemizde kapsamlı bir şekilde ele aldık: eğer kullanıcılar geçiş anahtarlarına geçiş yapmazsa, proje çoktan başarısız olmuştur. Parolalar baskınlığını korur, SMS OTP maliyetleri yüksek kalır, oltalama riskleri devam eder ve kuruluşunuz önemli bir mühendislik yatırımının karşılığını göremez. Geçiş anahtarı benimsemesi için iş gerekçesi güçlüdür, ancak yalnızca benimseme gerçekten gerçekleşirse. Lansman stratejisi ve benimseme stratejisi üzerinde kimse düşünmediği için, harika teknik uygulamalara sahip geçiş anahtarı lansmanları yapan ve %5'ten daha az benimseme oranına ulaşan işletmeler gördük. ### 6.2 Benimseme, Bilinçli Ürün Çalışması Gerektirir Geçiş anahtarı benimsemesini yönlendirmek, aşağıdakileri gerektiren bir ürün zorluğudur: - **Kademeli kayıt (Progressive enrollment)**: kullanıcıları doğru anlarda geçiş anahtarları oluşturmaya yönlendirmek (ör. başarılı bir girişten sonra, hesap güvenlik incelemeleri sırasında) - **Açık kullanıcı iletişimi**: geçiş anahtarlarının ne olduğunu ve neden daha iyi olduklarını teknik olmayan kullanıcıların anlayacağı bir dilde açıklamak - **Cihaza duyarlı istemler**: yalnızca kullanıcının cihazı bunu gerçekten iyi destekliyorsa geçiş anahtarı oluşturma teklifi sunmak, desteklenmeyen yapılandırmalarda sinir bozucu deneyimlerden kaçınmak - **Ölçüm altyapısı**: darboğazları belirlemek ve düzeltmek için geçiş anahtarı oluşturma oranlarını, giriş başarı oranlarını, geri dönüş oranlarını ve terk edilme oranlarını izlemek ### 6.3 "İyi" Benimseme Neye Benzer Büyük ölçekli geçiş anahtarı dağıtımlarıyla olan deneyimlerimize dayanarak, işte işletmelerin hedeflemesi gerekenler: | Metrik | Zayıf | Kabul Edilebilir | Güçlü | | --------------------------------------------- | ------- | ---------- | ------- | | **Geçiş Anahtarı Oluşturma Oranı** (uygun kullanıcıların) | <%10 | %10-60 | >%60 | | **Geçiş Anahtarı Giriş Oranı** (tüm girişlerin) | <%5 | %5-40 | >%40 | Benimseme rakamlarınız üç ay sonra "zayıf" sütunundakine benziyorsa, projenin başı derttedir. Bunu ölçecek analitik verileriniz olmadan bunu bilemeyeceksiniz. ## 7. Sorun 5: Platform Değişiklikleri Geçiş Anahtarlarını sessizce bozar İşletim sistemi ve tarayıcı güncellemeleri istemleri, otomatik doldurma davranışını ve geri dönüş akışlarını değiştirir. Eğer sürekli bir izlemeniz yoksa, uyarı olmadan gerilemeler ve destek biletleri alırsınız. Kısa süre önce üretimde meydana gelen WebAuthn hatalarının kapsamlı bir genel görünümünü yayınladık. ### 7.1 Geçiş Anahtarları Neden Platform Değişikliklerinden Benzersiz Şekilde Etkilenir? Sadece sunucunuzun doğruladığı dizeler olan parolaların aksine, geçiş anahtarları işletim sistemi, tarayıcı ve kimlik bilgisi yöneticisi ile derin entegrasyona dayanır. Apple yeni bir iOS sürümü çıkardığında, geçiş anahtarı oluşturma istemleri farklı görünebilir. Chrome otomatik doldurma mantığını güncellediğinde, giriş akışınız bozulabilir. Bir parola yöneticisi yeni bir sürüm yayınladığında, öngörmediğiniz yollarla geçiş anahtarı isteklerini yakalamaya başlayabilir. Yakın zamandaki bir örnek, `isUserVerifyingPlatformAuthenticatorAvailable()` işlevinin Safari dışındaki tüm tarayıcılarda (Chrome, Edge, Firefox) `false` döndürdüğü ve geçici çözüm olarak `getClientCapabilities()` kullanan platforma duyarlı algılama mantığı gerektiren iOS 26.2 hatasıdır. ### 7.2 İzleme İsteğe Bağlı Değildir Olası tüm hatalardan haberdar olduğunuzdan ve benimsenme oranını izlediğinizden emin olmak için kimlik doğrulama gözlemlenebilirlik yığınınızı (observability stack) kurmanız gerekir. Aşağıdakilerin en azından mevcut olmasını öneririz: - **Gerçek zamanlı kimlik doğrulama analitiği**: işletim sistemi, tarayıcı ve geçiş anahtarı sağlayıcısı kombinasyonuna göre başarı ve başarısızlık oranlarını izleyin - **Sürüme duyarlı izleme**: yeni bir işletim sistemi veya tarayıcı sürümünün hatalarda veya geri dönüşlerde ne zaman bir artışa neden olduğunu tespit edin. Beklenen hatalar (`NotAllowedError` olarak ortaya çıkan kullanıcı iptalleri) ile beklenmeyen hatalar (eşzamanlılık hatalarından kaynaklanan `AbortError` artışları veya bir Android güncellemesinden sonraki yeni Credential Manager geçiş anahtarı hataları) arasında ayrım yapın - **Uyarı (Alerting)**: kullanıcılarınız destek biletleri açmaya başlamadan önce haberdar olun - **Hızlı müdahale yeteneği**: düzeltmeleri uygulamaya koyma veya etkilenen cihaz kombinasyonları için geçiş anahtarlarını hızlıca devre dışı bırakma yeteneği Bu, çoğu ekibin bir olay yaşayana kadar kurmadığı türden bir kimlik doğrulama analitiği altyapısıdır. O zamana kadar, kullanıcı güvenine ve dahili proje güvenilirliğine verilen hasar çoktan verilmiş olur. ### 7.3 Devam Eden Bakım Maliyeti Geçiş anahtarı uygulamasının gerçek maliyeti ilk oluşturma süreci değildir. Devam eden bakımdır: - iOS, Android, Windows, macOS ve tüm büyük tarayıcılardaki platform değişikliklerinin izlenmesi - Her güncellemenin gerilemeler açısından test edilmesi - Tarayıcı API'leri değiştiğinde ön uç (frontend) SDK'nızın güncellenmesi - Büyüyen bir geçiş anahtarı sağlayıcıları ekosistemiyle uyumluluğun korunması - Değişikliklerin belgelenmesi ve destek ekibinize iletilmesi ## 8. Geçiş Anahtarlarını Ne Zaman Yayınlamalı / Yayınlamamalısınız? Bu 2. Gün sorunları göz önüne alındığında, geçiş anahtarlarını ne zaman yayınlayıp ne zaman yayınlamamanız gerektiğine dair dürüst bir değerlendirme aşağıda sunulmuştur. ### 8.1 Şu Durumlarda Geçiş Anahtarlarını Yayınlamayın - Net bir geri dönüş ve kurtarma stratejiniz yoksa - Kullanıcılarınızın fiilen kullandığı cihaz kombinasyonlarında test yapmadıysanız - Yerel uygulamalarınız var ancak devam eden platforma özgü QA için bir planınız yoksa - Benimsemeyi ölçecek analitik altyapınız yoksa - Devam eden bakım için mühendislik kaynakları ayıramıyorsanız - Geçiş anahtarlarını yalnızca düzgün bir planlama yapmadan bir uyumluluk kontrol kutusu için uyguluyorsanız Düzgün bir planlama yapmadan mevzuat nedenleriyle tüm gücünüzle bu işe girmek maliyetleri önemli ölçüde artırabilir. Kötü uygulanmış bir geçiş anahtarı sistemi, hiç geçiş anahtarı sistemi olmamasından daha kötüdür: kullanıcı güvenini zedeler, destek yükü yaratır ve dahili paydaşlara projeyi öldürmeleri için bir neden verir. ### 8.2 Şu Durumlarda Geçiş Anahtarlarını Yayınlayın - Yukarıda açıklanan beş 2. Gün sorununun tümünü planladıysanız - Devam eden bir lansmanı destekleyecek ürün, mühendislik, güvenlik ve analitik yeteneklerine sahipseniz - Sadece ilk oluşturma için değil, sürekli bakım için bütçe ayırdıysanız - Net benimseme hedefleri olan aşamalı bir lansman stratejiniz varsa - Operasyonel karmaşıklığı sizin yerinize yöneten Corbado gibi bir ortakla çalışıyorsanız ### 8.3 İnşa Etme (Build) ve Satın Alma (Buy) Kararı Bu makalede açıklanan 2. Gün sorunları tam olarak birçok şirketin geçiş anahtarı altyapılarını sıfırdan oluşturmak yerine satın almayı seçmesinin nedenidir. Bir WebAuthn sunucusu oluşturmak işin kolay kısmıdır. Üretim düzeyinde bir geçiş anahtarı sistemini, düzgün kurtarma, izleme ve benimseme analitiği ile binlerce cihaz kombinasyonunda çalıştırmak, bir demoyu gerçek bir dağıtımdan ayıran şeydir. ## 9. Corbado Geçiş Anahtarı 2. Gün Sorunlarını Nasıl Çözer? Corbado, 2. Gün sorunları zor olduğu için var. Platformumuz, bu operasyonel karmaşıklığı kendi başınıza inşa edip sürdürmek zorunda kalmamanız için yönetir. ### 9.1 Kurtarma ve Geri Dönüş Corbado, uyarlanabilir güvenlik seviyeleriyle kullanıma hazır kurtarma akışları sağlar. Senkronize edilmiş geçiş anahtarı stratejilerinden cihazlar arası kimlik doğrulamasına ve otomatikleştirilmiş kimlik doğrulamasına kadar. Kurtarma mantığı yerleşiktir ve sürekli güncellenir. ### 9.2 Cihazlar Arası Uyumluluk Ön uç (frontend) SDK'larımız binlerce işletim sistemi, tarayıcı ve geçiş anahtarı sağlayıcısı kombinasyonunda önceden test edilmiştir. Cihaz algılama, koşullu (conditional) kullanıcı arayüzü yönetimi ve geri dönüş yönlendirmesi otomatik olarak gerçekleşir. Yeni bir tarayıcı sürümü bir şeyi bozduğunda, biz bunu SDK'mızda kullanıcılarınız fark etmeden önce düzeltiriz. ### 9.3 Yerel Uygulama Desteği Corbado, platform farklılıklarını soyutlayan SDK'lar ile hem yerel (native) hem de WebView geçiş anahtarı uygulamalarını destekler. Siz uygulamanızın UX'ine odaklanırken biz iOS ve Android'deki geçiş anahtarı altyapısını yönetiriz. ### 9.4 Benimseme Analitiği Analitik panomuz önemli olan her metriği izler: geçiş anahtarı oluşturma oranları, giriş başarı oranları, geri dönüş oranları ve cihaz düzeyindeki kırılımlar. Sadece ham verileri değil, benimsemeyi artırmak için eyleme dönüştürülebilir içgörüler elde edersiniz. ### 9.5 Platform Değişikliği İzleme Corbado, geçiş anahtarlarını etkileyen işletim sistemi ve tarayıcı değişikliklerini sürekli olarak izler. SDK'larımız proaktif olarak güncellenir. Geçiş anahtarı dağıtımınız, platform ortamı altında değişirken bile sabit kalır. ## 10. Sonuç Geçiş anahtarları kimlik doğrulamanın altın standardıdır. Bu tartışmasız bir gerçek. Ancak "geçiş anahtarları destekleniyor" durumundan "geçiş anahtarları geniş ölçekte güvenilir bir şekilde çalışıyor" durumuna giden yol, çoğu ekibin hafife aldığı 2. Gün sorunlarıyla döşelidir. Ele aldığımız beş sorun (kurtarma, cihazlar arası uç durumlar, yerel uygulama karmaşıklığı, benimseme ve platform değişiklikleri) nadir değildir. Bunlar, herhangi bir üretim (production) geçiş anahtarı dağıtımının temel operasyonel zorluklarıdır. Bunları görmezden gelmek ortadan kalkmalarını sağlamaz. Sadece kullanıcılarınızın bunları ilk önce keşfedeceği anlamına gelir. Dürüst tavsiyem: Eğer geçiş anahtarlarını düzgün bir şekilde uygulamak için teknik bilgiye ve kaynaklara sahip değilseniz, bunları yayına almayın. Ya yeteneğe (ürün, mühendislik, güvenlik ve analitik) yatırım yapın ya da bu sorunları çoktan çözmüş olan bir ortakla çalışın. En kötü sonuç, 2. Gün için kimse plan yapmadığı için geri çekilen yarım yamalak bir geçiş anahtarı dağıtımıdır. ## Sıkça Sorulan Sorular ### Lansman sonrasında geçiş anahtarı projelerinin başarısız olmasına neden olan beş 2. gün sorunu nedir? Beş operasyonel sorun; güvensiz kurtarma ve geri dönüş akışları, cihazlar arası ekosistem uç durumları, yerel uygulama karmaşıklığı, düşük kullanıcı benimsemesi ile işletim sistemi ve tarayıcı güncellemelerinden kaynaklanan sessiz gerilemelerdir. Çoğu ekip ilk WebAuthn entegrasyonuna odaklanır ve bu lansman sonrası zorlukları hafife alır. Bu da birçok geçiş anahtarı projesinin geri alınmasına veya dahili olarak sessizce terk edilmesine neden olur. ### iPhone'da kayıt olan Windows üzerindeki kurumsal kullanıcılar için cihazlar arası geçiş anahtarı kimlik doğrulamasını nasıl yönetirim? Kullanıcılar, bir QR kodu ve Bluetooth cihazlar arası akışı aracılığıyla kimlik doğrulayabilir, ancak bu, her iki cihazda da Bluetooth'un etkin olmasını gerektirir ve kurumsal MDM politikaları ve güvenlik duvarları tarafından engellenebilir. UX tarayıcılar arasında önemli ölçüde değişir ve kullanıcılar genellikle neden bir QR kodu taradıklarını anlamazlar. Bu da cihaz farkında olan geri dönüş yönlendirmesini ve kurumsal dağıtımlar için net iletişimi kritik hale getirir. ### Lansman sonrasında hangi geçiş anahtarı benimseme metriklerini hedeflemeli ve izlemeliyim? Güçlü benimseme, uygun kullanıcıların %60'ının üzerinde bir geçiş anahtarı oluşturma oranını ve tüm girişlerin %40'ının üzerinde bir geçiş anahtarı giriş oranını ifade eder. Üç ay sonra %10'un altında oluşturma ve %5'in altında giriş oranları başarısız bir lansmana işaret eder. Bunu ölçmek, cihaz ve işletim sistemi kombinasyonuna göre ayrılmış oluşturma oranlarını, giriş başarı oranlarını, geri dönüş oranlarını ve terk etmeleri izleyen özel bir altyapı gerektirir. ### Mobil uygulamamda geçiş anahtarlarını yerel (native) olarak mı oluşturmalıyım yoksa bir WebView mı kullanmalıyım? Yerel uygulama, sınıfının en iyisi kullanıcı deneyimi (UX) sunar ancak platforma özgü API işleme ve bağımsız QA ardışık düzenleri (pipelines) içeren ayrı iOS ve Android kod tabanları gerektirir. WebView yaklaşımları paylaşılan web mantığını kullanır ancak WebView türüne bağlı olarak geçiş anahtarı destek tutarsızlıkları getirir. Yalnızca iOS'ta WKWebView, SFSafariViewController ve ASWebAuthenticationSession arasındaki seçim, bir mimariye karar vermeden önce değerlendirilmesi gereken farklı geçiş anahtarı destek özellikleri taşır. ### Geçiş anahtarı hesap kurtarma işlemi neden göründüğünden daha zordur ve doğru yaklaşım nedir? E-posta tabanlı sıfırlamalar gibi basitleştirilmiş kurtarma işlemleri oltalama (phishing) yapılabilir kanalları yeniden sunarken, zorunlu donanım güvenlik anahtarları gibi aşırı katı kurtarma işlemleri süreci terk etmeye neden olur. Önerilen yaklaşım katmanlıdır: temel strateji olarak senkronize geçiş anahtarları, ikinci bir katman olarak cihazlar arası QR kod doğrulaması, üçüncü olarak canlılık (liveness) kontrollerine sahip otomatik kimlik doğrulama ve dördüncü olarak dijital doğrulanabilir kimlik bilgileri (verifiable credentials). Hangi katmanların uygulanacağı tehdit modelinize, kullanıcı tabanınıza ve yasal gerekliliklerinize bağlıdır.