WebAuthn Relying Party ID (rpID) ve Geçiş Anahtarları: Etki Alanları ve Yerel Uygulamalar

TikTok, GitHub, WhatsApp, X (Twitter), LinkedIn ve Amazon gibi teknoloji devleri geçiş anahtarlarını kullanıma sundukça veya zaten sunmuş oldukları için, geçiş anahtarı kimlik doğrulaması hızla standart haline geliyor. Teknoloji dünyasının basit ve güvenli kimlik doğrulamanın önemini anladığı ortada.

Face ID, Touch ID veya Windows Hello ile kimlik doğrulamanın kusursuz kullanıcı deneyiminin ötesinde, geçiş anahtarları, parolalar gibi geleneksel kimlik doğrulama yöntemleriyle karşılaştırıldığında benzersiz bir güvenlik sunar. Öne çıkan özelliklerinden biri kimlik avına karşı güçlü dirençleridir.

Passkeys Cheat Sheet. Passkey programları için pratik rehberler, geçiş kalıpları ve KPI'lar.

Cheat sheet al

Canlı demo ile passkeys deneyin.

Passkeys dene

Kimlik avı (phishing) saldırısı, kurbanın orijinal siteyi taklit eden sahte bir siteye kimlik bilgilerini sağlaması için kandırıldığı bir saldırıdır. Örneğin, bankanızdan gelmiş gibi görünen ve giriş yapmanızı isteyen bir e-posta aldığınızı hayal edin. Bağlantıya tıklarsınız, web sitesi meşru görünür, bu nedenle kimlik bilgilerinizi girersiniz ve saldırgan bunları orijinal siteye giriş yapmak için kullanabilir. Bu, dijital çağda giderek büyüyen bir sorun haline geliyor ve Okta (bir kimlik doğrulama sağlayıcısı!) veya Retool gibi büyük şirketler bile hedef odaklı kimlik avı (spear-phishing) saldırılarının kurbanı olmuştur (tekil kurbanların çok kişisel kimlik avı hileleriyle özellikle hedeflendiği özel bir kimlik avı biçimi), bu da sağlam güvenlik önlemlerine olan ihtiyacı vurgulamaktadır.

Aksine, bir geçiş anahtarı kullanırsanız ve site sahteyse, kimlik doğrulamanız başarısız olur. Bunun nedeni, geçiş anahtarlarının Relying Party ID aracılığıyla oluşturuldukları etki alanlarına bağlı olmalarıdır.

Bu mekanizma, parolasız kimlik doğrulama için geçiş anahtarlarının temelini oluşturan web standardı WebAuthn'e entegre edilmiştir. WebAuthn iki temel tören (ceremony) üzerine kuruludur: kayıt ve kimlik doğrulama töreni.

Kayıt (kaydolma) töreni sırasında, bir web veya yerel uygulama aracılığıyla çevrimiçi bir hizmet (Relying Party) için yeni bir geçiş anahtarı oluşturulur. Bu süreçte, geçiş anahtarının oluşturulduğu etki alanı (Relying Party ID) geçiş anahtarında saklanır.

Bu, kimlik doğrulama (oturum açma) töreninin, web veya yerel uygulamanın ait olduğu çevrimiçi hizmetin (Relying Party), geçiş anahtarında saklanan Relying Party ID ile eşleşip eşleşmediğini kontrol etmesini sağlar.

Aşağıda, bu etki alanı eşleme sürecinin nasıl çalıştığını ve özellikle yerel uygulamaların nasıl güvence altına alındığını ayrıntılı olarak göreceğiz.

Relying Party ID, temel olarak geçiş anahtarı içinde saklanan bir etki alanıdır ve geçiş anahtarının yalnızca mevcut tarayıcı URL'si (her istekte otomatik olarak gönderilen kullanıcı kaynağı) ile eşleşmesi durumunda çalışmasını sağlar (aşağıdaki yerel uygulama yaklaşımına bakın). Bu, WebAuthn spesifikasyonunun çok önemli bir bileşenidir ve buradan inceleyebilirsiniz. Relying Party ID kök etki alanı (örn. corbado.com) veya bir alt alan adı (auth.corbado.com) olabilir. Genel son ek listesinde ise (listeyi ve genel son ek tespiti için kütüphaneleri burada bulabilirsiniz) kök etki alanını Relying Party ID olarak kaydedemezsiniz. Çevrimiçi bir hizmet için Relying Party ID'yi değiştirmek mevcut geçiş anahtarlarını bozar (istisnalar: yeni Relying Party ID, eski Relying Party ID'nin bir alt alan adıdır veya geçiş anahtarının ilgili etki alanları arasında yeniden kullanımına izin vermek için .well-known/webauthn aracılığıyla Related Origin Requests yapılandırılmıştır).

Kimlik doğrulama işlemi sırasında, eşleştiklerinden emin olmak için Relying Party ID, tarayıcı URL'sine (kullanıcının kaynağı) karşı kontrol edilir. Bu anlamda eşleştirme, aşağıdakilerden biri anlamına gelir:

• Tarayıcı URL'si (kullanıcının kaynağı) tam olarak Relying Party ID ile eşleşiyor VEYA
• Tarayıcı URL'si (kullanıcının kaynağı) Relying Party ID ile eşleşen bir alt alan adıdır ve ana etki alanı kaydedilebilir düzeydedir (örn. com veya Genel Son Ek Listesindeki herhangi bir etki alanı çalışmaz)

Aşağıda, hangi originalHost'un (ikinci sütun) ana etki alanına erişmesine izin verildiğini gösteren ayrıntılı bir taslak bulunmaktadır:

Aşağıda, ayrıştırılmış (parsed) PublicKeyCredentialCreationOptions yapısını görüyorsunuz:

{
    "publicKey": {
        "attestation": "direct",
        "authenticatorSelection": {
            "authenticatorAttachment": "platform",
            "requireResidentKey": false,
            "userVerification": "preferred"
        },
        "challenge": "qNqrdXUrk5S7dCM1MAYH3qSVDXznb-6prQoGqiACR10=",
        "excludeCredentials": [],
        "pubKeyCredParams": [
            {
                "alg": -7,
                "type": "public-key"
            }
        ],
        "rp": {
            "id": "corbado.com",
            "name": "Corbado"
        },
        "timeout": 30000,
        "user": {
            "displayName": "Corbado user",
            "id": "bz9ZDfHzOBLycqISTAdWwWIZt8VO-6mT3hBNXS5jwmY="
        }
    }
}

rp, Relying Party'yi temsil eder.

Relying Party ID'nin en önemli faydalarından biri kimlik avı saldırılarının önlenmesidir. Aşağıdaki senaryoyu hayal edin:

1. Bir saldırgan, sizin adınıza giriş yapmak ve saldırganın hesabına para göndermek için PayPal kimlik bilgilerinizi çalmaya çalışan sahte bir web sitesi olan bir PayPal klonu geliştirir. Bu sahte PayPal web sitesi paybal.com alan adında barındırılır (bu nedenle ilk bakışta farklı bir alan adı olduğu genellikle fark edilmez).
2. Geçmişte yasal PayPal sitesi için zaten bir geçiş anahtarı oluşturdunuz. Bu geçiş anahtarı, paypal.com Relying Party ID'sini sakladı.
3. paybal.com adresindeki sahte PayPal web sitesini ziyaret edersiniz (bu siteyi ziyaret ettiğinizde, isteğinizin kaynağı paybal.com'dur*) ve site, cihazınıza (kimlik doğrulayıcıya) Relying Party ID paypal.com için bir meydan okuma (challenge) gönderir (burada sizi kandırmaya çalışır) ve sizden onu paypal.com Relying Party ID'si için geçiş anahtarınızla imzalamanızı ister.
4. Cihazınız (kimlik doğrulayıcı), isteğin kaynağı (paypal.com) ile geçiş anahtarında sakladığı Relying Party ID'nin (paypal.com) eşleşip eşleşmediğini kontrol eder.
5. Bunlar açıkça eşleşmediğinden, kimlik doğrulama başarısız olur ve sizi bazı saldırganlara PayPal hesabınıza erişim izni vermekten kurtarır.

Aşağıdaki diyagram, bu kimlik avı önleme mekanizmasını göstermektedir.

Yerel bir uygulama durumunda, kaynak (origin) işleme platforma göre farklılık gösterir: Android'de kaynak android:apk-key-hash:<SHA256_fingerprint> formatındadır. iOS'ta WebAuthn kaynağı, RP web kaynağıdır (örn. https://paypal.com). Her iki durumda da, yerel uygulamanız ile sunucu arasındaki güven, ilgili ilişkilendirme dosyası aracılığıyla doğrulanır (bkz. aşağıda). Yerel uygulamalar için kaynak doğrulamasının nasıl çalıştığına dair ayrıntılı bilgi için, yerel uygulamalar için WebAuthn kaynak doğrulamasına ilişkin özel kılavuzumuza bakın.

Güncellemeler ve destek için Passkeys Community'ye katılın.

Katıl

Yerel bir uygulamada geçiş anahtarlarını uygulamak için bir geliştirici, bunları WebView aracılığıyla veya yerel olarak (natively) ekleme arasında karar verebilir. Aşağıda her iki yaklaşımın avantajlarını ve dezavantajlarını inceleyelim.

Geçiş anahtarlarını entegre etmek için bir WebView* kullanmak, kimlik doğrulama sürecini yönetmek için yerel uygulama içine bir web tarayıcısı gömmek anlamına gelir. Bu yaklaşım, temel olarak uygulama içinde bir web sayfası görüntüler ve web tabanlı kimlik doğrulama akışlarını yerel platform için yeniden yazmak zorunda kalmadan yeniden kullanmayı kolaylaştırır. Ancak bazı dezavantajları vardır. WebView'lar tüm geçiş anahtarı özelliklerini desteklemeyebilir ve güvenli bir şekilde uygulanmazsa "ortadaki adam" (man-in-the-middle) saldırısı riski potansiyeli taşır. Ayrıca, kullanıcı deneyimi yerel entegrasyonlardaki kadar pürüzsüz olmayabilir ve farklı cihazlar ve işletim sistemi sürümlerinde tutarlı davranış sağlamada zorluklar yaşanabilir.

*Birden çok WebView türü vardır: iOS'ta (OAuth/OpenID Connect tabanlı kimlik doğrulama akışları için WKWebView, SFSafariViewController veya SFAuthenticationSession / ASWebAuthenticationSession) ve Android'de (WebView, CCT-Chrome Custom Tabs). Ayrıntılar için bu blog yazısına bakın. Yerel bir entegrasyon istemiyorsanız geçiş anahtarları bağlamında SFSafariViewController/ ASWebAuthenticationSession ve Chrome Custom Tabs kullanmanızı öneririz.

Kaç kişinin gerçekten passkeys kullandığını görün.

Adoption verilerini gör

Yerel entegrasyon, platforma özgü API'leri ve kütüphaneleri kullanarak geçiş anahtarı işlevselliğini doğrudan iOS veya Android uygulamasında oluşturmayı içerir. Bu yöntem, yerel uygulama ile bir WebView arasında geçiş yapma ihtiyacı olmadığı için daha pürüzsüz bir kullanıcı deneyimi sunar. Aynı zamanda daha iyi performans ve daha tutarlı bir görünüm ve his sağlar. Güvenlik açısından bakıldığında, yerel entegrasyon özellikle platforma özgü güvenlik özellikleriyle birleştirildiğinde belirli saldırı türlerine karşı artırılmış koruma sunabilir. Ancak, geliştiricilerin her platform (Android ve iOS) için ayrı kod yazması ve sürdürmesi gerektiğinden uygulama çabası daha yüksek olabilir. Ek olarak, en son geçiş anahtarı / WebAuthn spesifikasyonlarıyla güncel kalmak daha sık uygulama güncellemeleri gerektirebilir.

Aşağıda, yerel geçiş anahtarı entegrasyonuna odaklanıyoruz.

Kaç kişinin gerçekten passkeys kullandığını görün.

Adoption verilerini gör

Yerel uygulamalar (örn. iOS veya Android uygulamaları) web uygulamalarına kıyasla bir zorluk sunar. Web uygulamalarından farklı olarak, Relying Party ID ile eşleştirilecek bir tarayıcı URL'si yoktur. Bununla birlikte, aynı güvenlik seviyesini sağlamak için etki alanları yerel uygulamalara ilişkilendirme dosyaları (association files) aracılığıyla bağlanır, böylece bir etki alanı ile yerel bir uygulama arasında güven oluşturulur.

Bu, özellikle bir geçiş anahtarı bir web uygulamasında oluşturulduysa ve yerel bir uygulamada aynı Relying Party ID için kullanılacaksa (ve tersi) önemlidir.

iOS, apple-app-site-association dosyasını kullanır. Bu dosya çeşitli yetkilendirmeler (entitlements) içerir, ancak WebAuthn ve geçiş anahtarları için webcredentials yetkilendirmesi önemlidir.

{
    "webcredentials": {
        "apps": ["9RF9KY88B2.com.corbado.passkeys"]
    }
}

webcredentials.apps içinde Uygulama Tanımlayıcı Ön Ekinizi (Application Identifier Prefix) (örn. 9RF9KY77B2) ve Paket Tanımlayıcınızı (Bundle Identifier) (örn. com.corbado.passkeys) saklamanız gerekir.

iOS yerel uygulamalarının çalışması için apple-app-site-association dosyasının Relying Party ID'lerinin /.well-known dizininde (https://<Relying Party ID>/.well-known/apple-app-site-association) saklanması gerekir.

Canlı bir örneği buradan görebilirsiniz.

Android, assetlinks.json dosyasını kullanır, bu dosya iOS muadili gibi WebAuthn ve geçiş anahtarları için belirli yapılandırmalar gerektirir.

[
    {
        "relation": [
            "delegate_permission/common.handle_all_urls",
            "delegate_permission/common.get_login_creds"
        ],
        "target": {
            "namespace": "android_app",
            "package_name": "com.corbado.passkeys.pub",
            "sha256_cert_fingerprints": [
                "F8:90:4E:9A:99:01:71:75:25:38:D5:36:16:2D:B3:65:EB:41:51:D4:53:9A:72:BC:4B:56:C5:16:43:62:E2:C0"
            ]
        }
    }
]

delegate_permission/common.handle_all_urls ve delegate_permission/common.get_login_creds ilişki değerlerinin (relation values) ayarlanmış olması gerekir. Ayrıca paket adınızı ve imzalama sertifikanızın SHA-256 parmak izini eklemeniz gerekir.

Bir geçiş anahtarının yerel bir uygulama ile bir web uygulaması arasında paylaşılmasına izin vermek için iki giriş (entry) eklemeniz gerekir. Biri namespace web için ve diğeri namespace android_app için.

Canlı bir örneği buradan görebilirsiniz.

Android uygulamalarının çalışması için assetlinks.json dosyasının Relying Party ID'lerinin /.well-known dizini altında https://<Relying Party ID>/.well- known/assetlinks.json konumunda saklanması gerekir - yani iOS'taki gibi.

Yerel bir Android / iOS uygulaması ile bir web uygulaması arasında geçiş anahtarlarını paylaşan örnek bir uygulamayı görmek için bu blog yazısına göz atın.

Passkeys Debugger içinde passkey akışlarını deneyin.

Ücretsiz dene

Bir iOS uygulaması ile web uygulaması arasında güven oluşturma süreci şu şekildedir:

1. iOS uygulaması geliştiricisinin yerel uygulama ile ilişkilendirmek istediği etki alanlarının bir listesini belirtmesi gerekir. Bu etki alanları, iOS uygulamasının yetkilendirmelerine kodlanmıştır (hardcoded), örneğin:

• webcredentials:auth.Corbado.com
• webcredentials:*.Corbado.com

2. iOS uygulaması her yüklendiğinde veya güncellendiğinde, iOS, iOS uygulaması yetkilendirme listesinin her girişi için apple-app-site-association dosyasını indirir.

3. Bir iOS uygulaması içinde bir kimlik bilgisi (örn. geçiş anahtarı) oluşturulduğunda, iOS uygulaması aşağıdaki iki yönü kontrol ederek ilgili taraf sunucusunun etki alanının iOS uygulamasıyla ilişkili olup olmadığını doğrular:

• Cihazda bu ilgili taraf (relying party) sunucusunun etki alanı için bir apple-app-site-association dosyası mevcut mu?
• iOS uygulaması o apple-app-site-association dosyasında listeleniyor mu?

Eğer, ve sadece eğer, her iki soruya da evet yanıtı verilebiliyorsa, iOS uygulaması içinde bir geçiş anahtarı oluşturulabilir.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

We hit 80% mobile passkey activation across 5M+ users without replacing our IDP.

See how VicRoads scaled passkeys to 5M+ users — alongside their existing IDP.

Read the case study

Bir Android uygulaması ile web uygulaması arasında güven oluşturma süreci şu şekildedir:

1. Android uygulaması geliştiricisinin Android uygulaması ile ilişkilendirmek istediği etki alanlarının bir listesini belirtmesi gerekir. Bu etki alanları assetlinks.json dosyasında namespace web'e sahip hedefler (targets) olarak saklanır. Android uygulamaları ve web uygulamalarının kimlik bilgilerini paylaştığını beyan etmek için delegate_permission/common.get_login_creds belirtilmelidir. Ayrıntıları burada bulabilirsiniz.

2. Android uygulaması içinde bir geçiş anahtarı oluşturulursa, Android uygulaması assetlinks.json dosyasını kontrol ederek Relying Party ID'nin Android uygulamasıyla ilişkili olup olmadığını doğrular:

• https://<Relying Party ID>./well-known/assetlinks.json adresinde bu Relying Party ID için bir assetlinks.json dosyası var mı
• Android uygulaması bir hedef olarak doğru bir şekilde tanımlanmış mı.

3. Eğer, ve sadece eğer, her iki soruya da evet yanıtı verilebiliyorsa, Android uygulaması içinde bir geçiş anahtarı oluşturulabilir.

Aşağıdaki diyagram, bu güven oluşturma süreçlerini yan yana karşılaştırmaktadır.

Son haberler için Passkeys Substack'e abone olun.

Abone ol

Aşağıda, yerel uygulamalar için geçiş anahtarı kimlik doğrulamasını doğru bir şekilde ayarlamak için gereken farklı ayarların ayrıntılı bir özetini sunuyoruz.

Flutter için, ilgili Android veya iOS kuralı geçerlidir. Tek Flutter'a özgü ayar, ilişkilendirme dosyalarının kaydıdır; şunları eklemelisiniz:

• Android için: flutter_deeplinking_enabled to AndroidManifest.xml
• iOS için: FlutterDeepLinkingEnabled true to Info.plist

Relying Party ID'lerle, farklı seviyelerdeki (alt) alan adları ve CNAME'lerle çalışmanın oldukça zorlayıcı bir görev olabileceğini deneyimlediğimizden, dört farklı örnek sunuyor ve bunların neden ve nasıl çalıştıklarını açıklıyoruz.

CNAME tablo satırının geçiş anahtarı kimlik doğrulaması için gerekli olmadığını ve yalnızca eklemek istediğimiz araştırmamızın bir sonucu olduğunu unutmayın.

Bu örnekte, Corbado.com için apple-app-site-association / assetlinks.json dosyası, yerel uygulama yüklendiğinde / güncellendiğinde hiçbir sorun olmadan indirilebilir, çünkü dosya Relying Party ID ile aynı konumdadır.

Relying Party ID için bir geçiş anahtarı oluşturulabilir.

Bu örnekte, auth.corbado.com için apple-app-site-association / assetlinks.json dosyası, yerel uygulama yüklendiğinde / güncellendiğinde hiçbir sorun olmadan indirilebilir; çünkü dosya, Relying Party ID ile aynı konumdadır, zira CNAME Relying Party ID'den saklanan konuma işaret eder.

Relying Party ID için bir geçiş anahtarı oluşturulabilir.

Bu örnekte, auth.corbado.com için apple-app-site-association / assetlinks.json dosyası, yerel uygulama yüklendiğinde / güncellendiğinde hiçbir sorun olmadan indirilebilir, çünkü CNAME nedeniyle dosya auth.corbado.com'un beklediği konumdadır.

FAKAT: corbado.com için apple-site-association-file / assetlinks.json, yerel uygulama yüklendiğinde / güncellendiğinde indirilemez; çünkü dosya beklenen yer olan https://corbado.com/.well-known/apple-app-site-association / https://corbado.com/.well-known/assetlinks.json adresinde değildir ve ona işaret eden hiçbir CNAME yoktur.

Relying Party ID için bir geçiş anahtarı oluşturulamaz.

Bu örnekte, corbado.com için apple-app-site-association dosyası, yerel uygulama yüklendiğinde / güncellendiğinde hiçbir sorun olmadan indirilebilir, çünkü dosya beklendiği yerdedir ve webcredentials yetkilendirmesi (*.corbado.com) Relying Party ID'si (auth.corbado.com) ile eşleşir. Android (wildcard) yetkilendirmeler gibi bir şeyle çalışmadığı için bu örneğin Android'de çalışmadığını unutmayın. Genel olarak, Relying Party ID'lerini bu şekilde tanımlamak önerilmez.

Relying Party ID için bir geçiş anahtarı oluşturulabilir.

Güncellemeler ve destek için Passkeys Community'ye katılın.

Katıl

Hata:

Geliştirmeye başladınız ve Relying Party ID'niz olarak bir alt alan adı (örn. login.acme.com) tanımladınız. İlk kullanıcılar bu Relying Party ID için bir geçiş anahtarı oluşturdu. Ardından, bu geçiş anahtarlarına başka bir alt alan adında (örn. app.acme.com) kimlik doğrulama için de ihtiyacınız olduğunu fark edersiniz. Yeni alt alan adı için bir kullanıcının kaynağı ve Relying Party ID eşleşmediğinden, kullanıcı geçiş anahtarıyla oturum açamaz. WebAuthn ayarlarınızdaki Relying Party ID'yi acme.com olarak değiştirmek, yeni kaynak ile mevcut geçiş anahtarlarında saklanan Relying Party ID eşleşmeyeceği için mevcut tüm geçiş anahtarlarını geçersiz kılar.

Çözüm:

Relying Party ID'nizi tanımlarken başlangıçta iki kez kontrol edin çünkü bu az çok kalıcıdır. Emin değilseniz ve geleceğe hazır olmak istiyorsanız, yani gelecekte diğer alt alan adlarının kimlik doğrulama için geçiş anahtarına ihtiyaç duyabileceğini düşünüyorsanız, Genel Son Ek Listesinde (Public Suffix List) yer almadığı sürece Relying Party ID olarak kök etki alanını (örn. acme.com) kullanmanızı öneririz.

Hata:

Eşzamanlı olarak yerel ve web uygulaması geliştiriyorsunuz. İşleri hızlandırmak için iki farklı WebAuthn sunucusu (yerel ve web uygulaması için farklı Relying Party ID'leri ile) kullanıyorsunuz. Kullanıcılarınız ilk geçiş anahtarlarını oluşturdukça, ilgili Relying Party ID geçiş anahtarında saklanır. Aynı geçiş anahtarıyla cihazlar arası / platformlar arası oturum açmaya izin vermek, örn. bir web uygulamasında oluşturulan bir geçiş anahtarı ile ve yerel bir uygulamada oturum açmaya çalışmak artık mümkün değildir. İki WebAuthn sunucusunu birleştirmek, eski WebAuthn sunucusuna (eski Relying Party ID) kayıtlı geçiş anahtarlarını terk edecek ve kullanıcılarınız bu geçiş anahtarlarıyla oturum açamayacaktır.

Çözüm:

Birden fazla uygulamanız varsa (örn. bir web uygulaması ve yerel bir uygulama), her zaman tek bir WebAuthn sunucunuz olsun ve tüm uygulamalarınız için yalnızca bir Relying Party ID tanımlayın. Bu uygulamalar arasındaki bağlantı, yukarıda açıklanan adımlarla yapılabilir.

Hata:

Uygulamanızı geliştirmeye başladınız, ilişkilendirme dosyalarını yapılandırdınız ve bunları sunucunuza dağıttınız. Bazı nedenlerden dolayı hala hata mesajları alıyorsunuz ve temel nedeni bulamıyorsunuz.

Çözüm:

Hata mesajının olası bir nedeni, hatalı biçimlendirilmiş veya ulaşılamaz bir ilişkilendirme dosyası olabilir. Herhangi bir ilişkilendirme dosyasını sunucuya dağıtmadan önce, iOS ve Android için sağlanan araçlar aracılığıyla bir ilişkilendirme dosyasının geçerliliğini ve erişilebilirliğini (genellikle bu dosyalar Apple ve Google'ın tarayıcıları için uygun erişimi engelleyen sağlam bir VPN veya güvenlik duvarı arkasında olabilir) kontrol etmenizi şiddetle tavsiye ederiz.

Hata:

apple-app-site-association dosyanızı sunucunuza dağıttınız ve test cihazınızda hemen bir geçiş anahtarı oluşturmaya başlamak istiyorsunuz. Bazı nedenlerden dolayı geçiş anahtarını oluşturamıyorsunuz ve hata mesajları alıyorsunuz.

Çözüm:

Bu hata mesajlarının arkasındaki neden, iOS cihazlarının Relying Party'yi doğrulamak için apple- app-site-association dosyasını indirmesidir. Bunu yapmak için, iOS cihazları sunucunuza doğrudan bir istek göndermez, bunun yerine bir CDN kullanır. Hem cihaz hem de CDN, başarıyla alındıktan sonra apple-app-site- association dosyasını önbelleğe alır. Bu önbelleğe alma işlevi nedeniyle, apple-app-site-association dosyanızdaki yeni değişiklikler uygulamanıza doğrudan yansıtılmaz. CDN'nin apple-app-site-association dosyasını önbelleğe alması 24 saati bulabilir. Geliştirme sırasında bu kısıtlamayı aşmak için, Relying Party ID'sine ?mode=developer ekleyebilir ve önbelleğe almayı tamamen devre dışı bırakabilirsiniz (örn. Relying Party ID acme.com?mode=developer olacaktır).

Hata:

Bir Android uygulaması geliştirmeye başlıyorsunuz ve bunu bir Android emülatöründe test etmek istiyorsunuz. Bazı nedenlerden dolayı, Android emülatörünü düzgün bir şekilde kurmuş olmanıza ve diğer uygulamalar üzerinde sorunsuz çalışıyor gibi görünmesine rağmen hata mesajları alıyorsunuz.

Çözüm:

Bir geçiş anahtarı uygulamasını test ederken Android sürümleri, Play Store desteği ve API sürümleri önemli bir rol oynar. Ayrıca, bir Google hesabına giriş yapmış olmanız gerekir. Ayrıntılar için lütfen sorun giderme bölümümüze bakın.

Genel tavsiyemiz, Relying Party ID'nizi uygulama ortamınıza ve gereksinimlerinize göre dikkatlice seçmenizdir. Aşağıda, en yaygın kullanım durumlarını derledik, ancak genel tavsiyemiz kök etki alanınızı Relying Party ID olarak seçmeyi hedeflemeniz ve kimlik doğrulamanızı bu şekilde yapılandırmanız gerektiğidir. Corbado ile, bunu sizin için önceden de bu şekilde yapılandırdık (tüm teknik kurulumlar için sorunsuz geçiş anahtarı kimlik doğrulaması sunma yaklaşımımızın bir parçası olduğu için. UI bileşenlerimiz ve SDK'larımız, kök etki alanınızla Relying Party ID olarak kullanılmaya hazırdır).

Aşağıda, geçiş anahtarı çözümünüz olarak Corbado'yu kullanırken doğru Relying Party ID'yi ve ilişkilendirme dosyalarını nasıl yöneteceğinizi / barındıracağınızı belirlemenize yardımcı olacak çok spesifik bir karar ağacı sunuyoruz.

İlk karar, geliştirme veya üretim ortamında olup olmadığınızdır. Vermeniz gereken bir sonraki karar seviyesi, uygulama yapınıza (landscape) bağlıdır: yalnızca yerel bir uygulamanız mı var yoksa yerel ve web uygulamanız mı var.

Geliştirme ortamı için, hızlı bir şekilde geliştirmeye ve test etmeye başlamak istediğinizi varsayıyoruz. Canlıya geçmek isterseniz Relying Party ID daha sonra değiştirilebilir.

• Relying Party ID'yi Ayarla = pro-XXX.frontendapi.cloud.corbado.io (varsayılan değer)
• Corbado ilişkilendirme dosyasını sizin için barındırır
• Sizin için DNS Yapılacaklar (ToDo) yok

Hem web uygulamasını hem de yerel uygulamayı aynı anda test etmek kolayca mümkün değildir

1. Seçenek:

Ya Relying Party ID'yi = pro-XXX.frontendapi.cloud.corbado.io olarak ayarlarsınız (yerel uygulama çalışır) VEYA Relying Party ID'yi = localhost olarak ayarlarsınız (web uygulaması çalışır)

2. Seçenek:

Yerel ve web uygulamasının aynı anda çalışması için tek çözüm, yerel bir ters proxy (reverse proxy) kullanmaktır (oldukça hileli / hacky bir çözümdür):

• Relying Party ID'yi Ayarla = acme-dev.com
• acme-dev.com'dan CNAME'i şuna ayarla => pro-XXX.frontendapi.cloud.corbado.io
• Yerel /etc/hosts girişine localhost acme-dev.com ekle
• acme-dev.com => localhost:3000 (örnek olarak) için kurallı ters proxy (nginx) ekle

Üretim ortamında, Relying Party ID (örn. auth.acme.com) olarak bir alt alan adıyla ilgili bir sorununuz olup olmadığına veya Relying Party ID (örn. acme.com) olarak bir kök etki alanı isteyip istemediğinize karar vermelisiniz.

• Relying Party ID'yi Ayarla = auth.acme.com
• Corbado ilişkilendirme dosyasını sizin için barındırır
• auth.acme.com'dan CNAME'i şuna ayarla => pro-XXX.frontendapi.cloud.corbado.io

• Relying Party ID'yi Ayarla = auth.acme.com
• Corbado ilişkilendirme dosyasını sizin için barındırır
• auth.acme.com'dan CNAME'i şuna ayarla => pro-XXX.frontendapi.cloud.corbado.io (Corbado'nun oturum yönetimini kullanıyorsanız çerezlerin çalışması için de gereklidir)

• Relying Party ID'yi Ayarla = acme.com
• İlişkilendirme dosyasını kendi sunucunuzda acme.com/.well-known/<association file> adresinde kendiniz barındırın
• Sizin için DNS Yapılacaklar (ToDo) yok

• Relying Party ID'yi Ayarla = acme.com
• İlişkilendirme dosyasını kendi sunucunuzda acme.com/.well-known/<association file> adresinde kendiniz barındırın
• Corbado'nun oturum yönetimini kullanıyorsanız, çerezlerin çalışmasını sağlamak için auth.acme.com'dan CNAME'i şuna ayarlamanız gerekir => pro-XXX.frontendapi.cloud.corbado.io (bu CNAME, yalnızca oturum yönetimi için Relying Party ID için gerekli değildir)

Aşağıdaki karar ağacı tüm yapılandırma yollarını özetlemektedir.

Relying Party ID, WebAuthn ve geçiş anahtarı tabanlı kimlik doğrulamanın temel taşıdır ve kimlik avına (phishing) karşı güçlü direnç sağlar. Bunu uygun şekilde yapılandırmak, etki alanı eşleştirme inceliklerini anlamak ve yerel uygulamalar için doğru dağıtımı sağlamak çok önemlidir. Bu blog yazısı size bunları nasıl doğru bir şekilde kuracağınızı ve farklı hatalarla nasıl başa çıkacağınızı gösterdi. rpID yapılandırmanız sağlamlaştığında, gerçek benimsemeyi artırmak için geçiş anahtarı oluşturma akışlarınızı ve geçiş anahtarı giriş akışlarınızı optimize etmeye odaklanın. Yerel uygulamalar için geçiş anahtarları ayarlama hakkında daha fazla bilgi edinmek için Flutter'da geçiş anahtarları hakkında okumanızı öneririz.

Başka sorularınız varsa veya yardıma ihtiyacınız varsa, bize ulaşmaktan çekinmeyin.

Corbado Hakkında

Corbado, büyük ölçekte tüketici kimlik doğrulaması yöneten CIAM ekipleri için Passkey Intelligence Platform'tur. IDP loglarının ve genel analytics araçlarının göremediğini görmenizi sağlarız: hangi cihazların, OS sürümlerinin, tarayıcıların ve credential manager'ların passkey desteklediğini; kayıtların neden girişe dönüşmediğini; WebAuthn akışının nerede başarısız olduğunu; bir OS ya da tarayıcı güncellemesinin girişi sessizce ne zaman bozduğunu — hem de Okta, Auth0, Ping, Cognito veya kendi IDP'nizi değiştirmeden. İki ürün: Corbado Observe, passkey'ler ve diğer tüm giriş yöntemleri için observability sağlar. Corbado Connect, analytics entegre managed passkey'ler sunar (IDP'nizin yanında). VicRoads, Corbado ile 5M+ kullanıcı için passkey çalıştırıyor (%80+ passkey aktivasyonu). Bir Passkey uzmanıyla görüşün →

Kimlik doğrulayıcı, tarayıcının gerçek kaynağını (origin) geçiş anahtarında saklanan Relying Party ID ile karşılaştırır. Bir saldırgan farklı bir etki alanında sahte bir site barındırıyorsa, sahte meydan okuma (challenge) meşru bir RP ID iddia etse bile, kaynak uyuşmazlığı kimlik doğrulamanın otomatik olarak başarısız olmasına neden olur. Bu bağlayıcılık, paypal.com'a kayıtlı bir geçiş anahtarının paybal.com gibi benzer bir alanda kullanılamayacağı anlamına gelir.

RP ID'yi değiştirmek, mevcut tüm geçiş anahtarlarını geçersiz kılar çünkü her kimlik bilgisinde (credential) saklanan RP ID artık yeni değerle eşleşmeyecektir. Tek istisnalar, yeni RP ID'nin eskisinin bir alt alan adı olması veya .well-known/webauthn aracılığıyla Related Origin Requests'in yapılandırılmış olmasıdır. Bu geri döndürülemez sorunu önlemek için başından itibaren RP ID olarak kök etki alanını seçin.

iOS, apple-app-site-association dosyasını doğrudan sunucunuzdan getirmez. Apple'ın CDN'ini kullanır, bu da yeni dağıtılan veya güncellenen bir dosyayı önbelleğe alması 24 saate kadar sürebilir. Geliştirme sırasında, önbelleğe almayı tamamen atlamak için Relying Party ID'sine ?mode=developer ekleyin.

Kök etki alanının (örn. acme.com) kullanılması önerilir, çünkü herhangi bir alt alan adında oluşturulan geçiş anahtarları, o kökün tüm alt alan adlarında kimlik doğrulaması yapabilir. Bir alt alan adı RP ID'si, geçiş anahtarı kullanımını o alt alan adı ve onun alt birimleriyle sınırlar; bu da daha sonra alt alan adları arası akışları (cross-subdomain flows) bozabilir. acme.com ve acme.co.uk gibi birden çok kök etki alanınız varsa, geçiş anahtarının bunlar arasında yeniden kullanılmasına izin vermek için .well-known/webauthn aracılığıyla Related Origin Requests yapılandırın.