Passkeys ve iframe'ler: Bir Passkey ile Nasıl Hesap Oluşturulur ve Giriş Yapılır?

Açıklama
✅ = destekleniyor ❌ = desteklenmiyor

Her geçen hafta daha fazla kuruluş Passkey kullanıma sunduğunu duyuruyor (örneğin son zamanlarda Visa, Mastercard veya Vercel). Diğer şirketlerdeki geliştiriciler ve ürün yöneticileri bu rol modellerini takip ettikçe, Passkey uygulamasının daha fazla kullanım senaryosu tartışılıyor.

Sürekli olarak bize sorulan konulardan biri de Passkey'lerin iframe'lerde nasıl çalıştığıdır, çünkü iframe'ler modern web geliştirmede farklı kaynaklardan gelen içeriği sorunsuz bir şekilde yerleştirmek için yaygın olarak kullanılır. Passkey'ler ve WebAuthn bağlamında, iframe'ler özellikle güvenlik ve kullanıcı etkileşimleri konusunda kendi zorluklarını beraberinde getirir.

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

Bu blog yazısı, iframe'lerde Passkey'leri ve WebAuthn'ı kullanma konusunda kapsamlı bir rehber sunmaktadır. Bu yazıda şunları yapacağız:

• Mevcut yetenekleri keşfedeceğiz
• Kaynaklar arası iframe desteğini tartışacağız
• iframe entegrasyonunun faydalarını vurgulayacağız ve
• Adım adım bir uygulama rehberi sunacağız

Bu yazının sonunda, iframe'ler içinde Passkey'lerden nasıl yararlanılacağı konusunda net bir anlayışa sahip olacaksınız.

iframe'ler veya satır içi çerçeveler, geliştiricilerin mevcut belge içine başka bir HTML belgesi yerleştirmesine olanak tanıyan HTML elemanlarıdır. Bu yetenek, videolar, haritalar ve diğer web sayfaları gibi dış kaynaklardan içerik eklemek için yaygın olarak kullanılır.

Farklı iframe türlerine bir göz atalım.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Temel iframe en sık kullanılan türdür. Basitçe başka bir URL'den gelen içeriği mevcut sayfa içine yerleştirir.

<iframe src="https://example.com"></iframe>

Bu temel iframe genellikle bir makale gibi statik içeriği bir web sayfasına dahil etmek için kullanılır.

Duyarlı iframe'ler, ekran boyutuna veya yerleştirildikleri kapsayıcıya göre boyutlarını ayarlamak için tasarlanmıştır. Bu, yerleştirilmiş içeriğin masaüstü bilgisayarlar, tabletler ve cep telefonları dahil olmak üzere tüm cihazlarda iyi görünmesini sağlar.

<iframe src="https://example.com" style="width: 100%; height: 500px;"></iframe>

CSS medya sorguları, iframe'in görüntü alanı boyutuna göre dinamik olarak ayarlanmasını sağlamak için de kullanılabilir.

Get a free passkey assessment in 15 minutes.

Book free consultation

Güvenli veya sanal alanlı (sandboxed) bir iframe, iframe içinde gerçekleştirilebilecek eylemleri kısıtlar. Bu, güvenilmeyen kaynaklardan içerik yerleştirmek veya güvenliği artırmak için kullanışlıdır.

<iframe src="https://example.com" sandbox></iframe>

sandbox özelliği, çeşitli kısıtlamalar içerebilir, örneğin:

<iframe src="https://example.com" sandbox="allow-scripts allow-same-origin"></iframe>

sandbox özelliği, komut dosyalarının çalışmasına izin verir ancak form gönderimleri veya eklenti kullanımı gibi potansiyel olarak tehlikeli eylemleri kısıtlar.

Become part of our Passkeys Community for updates & support.

Join

Kaynaklar arası iframe'ler, farklı bir alan adından içerik yerleştirir. Genellikle ödeme ağ geçitleri veya sosyal medya widget'ları gibi üçüncü taraf hizmetlerini entegre etmek için kullanılırlar. Güvenlik kısıtlamaları nedeniyle, bu iframe'lerin yerleştirildiği sayfanın içeriğine ve tam tersi şekilde sınırlı erişimi vardır.

Kaynaklar arası (cross-origin) olmak, yüklenen içeriğin farklı bir kaynaktan geldiği anlamına gelir; burada bir kaynak, şema (protokol), ana bilgisayar (alan adı) ve port numarasının birleşimiyle tanımlanır. Örneğin, https://example.com ve http://example.com farklı şemalar (HTTP vs. HTTPS) kullandıkları için farklı kaynaklar olarak kabul edilir.

Benzer şekilde, alt alan adları da ana alan adlarından ayrı kaynaklar olarak ele alınır. Örneğin, https://example.com ve https://sub.example.com, aynı temel alan adını paylaşmalarına rağmen kaynaklar arasıdır. Bu ayrım, bir alt alan adından gelen komut dosyalarının ve verilerin, açık izin olmadan diğeriyle doğrudan etkileşime girmemesini sağlayarak güvenliği artırır.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

Corbado proved to be a trusted partner. Their hands-on, 24/7 support and on-site assistance enabled a seamless integration into VicRoads' complex systems, offering passkeys to 5 million users.

Kurumsal şirketler, kullanıcılarını korumak ve Passkey'ler ile giriş işlemlerini daha sorunsuz hale getirmek için Corbado'ya güveniyor. Ücretsiz Passkey danışmanlığınızı şimdi alın.

Ücretsiz danışmanlık alın

İşte kaynaklar arası ve aynı kaynaklı kavramlarını göstermek için örnekler:

Kaynaklar arası örnek:

https://payment.example.com adresinden gelen içeriği, https://www.mystore.com üzerinde barındırılan bir web sayfasına yerleştirmek. Bunlar farklı alan adlarına sahip oldukları için kaynaklar arasıdır.

Aynı kaynaklı örnek:

https://www.example.com/shop adresinden gelen içeriği, https://www.example.com/blog üzerinde barındırılan bir web sayfasına yerleştirmek. Bunlar aynı şema, ana bilgisayar ve portu paylaştıkları için aynı kaynaklıdır.

Kaynaklar arası iframe'ler, kaynağın başka bir alan adından gelmesiyle temel iframe'lerden ayrılırken, aynı site iframe'inin kaynağı yerleştirildiği yerle aynı alan adından gelir.

<iframe src="https://anotherdomain.com"></iframe>

iframe'lerde Passkey kullanmak, geliştiricilerin anlaması gereken yeni yetenekler ve kısıtlamalar getirir. Bu durum temel olarak doğru izinleri ayarlama ve gömülü bağlam içinde güvenli kullanıcı etkileşimleri sağlama etrafında döner.

Geçmişte, Web Authentication API, temel olarak güvenlik endişeleri nedeniyle kaynaklar arası iframe'lerde varsayılan olarak devre dışı bırakılmıştı. Bu sınırlama, geliştiricilerin kullanıcıları yönlendirmesi veya kimlik doğrulama için açılır pencereler kullanması gerektiği anlamına geliyordu, bu da daha az sorunsuz bir kullanıcı deneyimine yol açıyordu.

Passkey'ler / WebAuthn'da iki temel işlem (tören olarak da adlandırılır) vardır:

1. Bir Passkey kaydetme / oluşturma
2. Bir Passkey ile kimlik doğrulama / giriş yapma

Bu iki işlem, kaynaklar arası iframe'lerde eşit şekilde desteklenmiyordu ve hala da desteklenmiyor:

İlk başta, kaynaklar arası iframe'ler aracılığıyla giriş yapmak mümkün kılındı ancak kaynaklar arası oluşturma henüz mümkün değildi çünkü kimsenin böyle bir kullanım senaryosu yoktu.

Son zamanlardaki gelişmeler (örneğin Chrome 123'te) belirli koşullar altında kaynaklar arası iframe Passkey'lerinin oluşturulması için destek getirdi. Ancak, Mayıs 2024 itibarıyla, tüm tarayıcılar kaynaklar arası iframe'ler aracılığıyla Passkey oluşturmayı tam olarak desteklememektedir, ancak çoğu tarayıcıda giriş yapmak mümkündür.

Üstelik, kaynaklar arası iframe desteği (kayıt ve kimlik doğrulama işlemleri için) devam eden WebAuthn Seviye 3 spesifikasyonuna zaten dahil edilmiştir. Bazı tarayıcıların hala spesifikasyona yetişmesi gerekiyor (örneğin Safari). Maalesef Apple, Safari içinde kaynaklar arası Passkey kaydına ne zaman ve izin verip vermeyeceğini henüz açıklamadı. Bu, kaynaklar arası iframe'lerde Passkey kullanmanın en önemli teknik sınırlamasını ortadan kaldıracaktır.

Blog yazısının aşağıdaki bölümlerinde, kaynaklar arası iframe'lerin kullanıldığını varsayıyoruz.

Want to find out how many people use passkeys?

View Adoption Data

aşağıdaki tablolar, kaynaklar arası iframe bağlamlarında iframe kimlik doğrulaması ve Passkey ile iframe girişi için tarayıcı/standart desteğine genel bir bakış sunmaktadır:

Mayıs 2024 itibarıyla, bir kaynaklar arası iframe içinde bir Passkey oluşturmak henüz tüm tarayıcılarda mümkün değildir. Aşağıdaki tablo, kaynaklar arası iframe'lerde Passkey kaydı / oluşturulması için tarayıcı / standart desteğine genel bir bakış sunmaktadır:

Bu gelişme ve destek hakkında daha fazla bilgi edinmek isterseniz, bu GitHub konusuna ve bu Pull Request'e göz atmanızı öneririz.

Kaynaklar arası iframe'lerde Passkey'leri desteklemek için iki ana kullanım senaryosu vardır.

Kaynaklar arası iframe'lerde Passkey'leri etkinleştirmek, birden fazla alan adının dahil olduğu ancak aynı kullanıcı hesaplarının kullanılması gereken birleşik kimlik senaryoları için çok önemlidir.

Şu senaryoyu ele alalım. KAYAK gibi çok uluslu bir şirketsiniz ve farklı bölgeler için farklı alan adlarınız var:

• www.kayak.com
• www.kayak.us
• www.kayak.de

Ancak, kullanıcıların tüm bu alan adlarında aynı hesap ve kimlik bilgileriyle giriş yapmasını sağlayan merkezi bir kimlik yönetim sisteminiz var. WebAuthn standardı, Passkey'lerin yalnızca bir alan adına (Relying Party ID), örneğin www.kayak.com adresine bağlanabilmesi nedeniyle bu senaryolara bir zorluk çıkaracaktır.

Bu zorluğun üstesinden gelmek için, diğer tüm alan adlarınızda www.kayak.com kaynağından bir iframe kullanırsınız. Yani www.kayak.us ve www.kayak.de üzerinde www.kayak.com kaynaklı bir iframe yerleştirirsiniz (kaynaklar arası iframe). Aksi takdirde, Passkey'lerin oltalama saldırılarına karşı dirençli olması nedeniyle "www.kayak.com"a bağlı Passkey'lerinizin bu diğer alan adlarında kullanılması mümkün olmazdı.

Bir not olarak: Alternatif olarak, yeni WebAuthn özelliği olan İlgili Kaynak Talepleri (Related Origin Requests - RoR) de kullanılabilir. Bu özellik, "ilgili kaynakların" iframe'ler olmadan Passkey'lere erişmesine olanak tanır, ancak henüz tüm tarayıcılarda desteklenmemektedir.

Sorunsuz ödeme akışları için de kaynaklar arası iframe'lerde Passkey kullanımı önemli bir rol oynar. Şu senaryoyu düşünün: Bir müşteri bir satıcının web sitesinde (örneğin www.amazon.com) yeni ayakkabılar almak istiyor. Bu satıcının web sitesi, müşterinin banka hesabı aracılığıyla (örneğin www.revolut.com adresinde) ödeme yapmasına izin veriyor ve bu nedenle kullanıcının bankanın web sitesine giriş yapmasını gerektiriyor (bu basitleştirilmiş bir süreçtir). Kullanıcı, bankanın Relying Party ID'sine, örneğin "revolut.com"a bağlı bir Passkey ile bankanın web sitesine giriş yapar.

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

Kullanıcıyı ödeme sürecinde satıcının web sitesinden (www.amazon.com) bankanın web sitesine (www.revolut.com) yönlendirmekten ve kullanıcının orada banka hesabına giriş yapmasını sağlamaktan kaçınmak için kaynaklar arası bir iframe kullanılabilir. Bu sayede kullanıcı www.amazon.com adresinde kalır ve www.revolut.com için oluşturduğu Passkey'i kimlik doğrulama için kaynaklar arası iframe'de kullanır.

Bu nedenle, ödeme akışlarında kaynaklar arası iframe'ler aracılığıyla Passkey'leri entegre etmek, tüketiciler, satıcılar ve bankalar arasında güvenli ve akıcı işlemler sağlar:

Ödeme ve Passkey'ler bağlamında, Güvenli Ödeme Onayı (SPC) ve Passkey'lerle dinamik bağlama hakkındaki blog yazımıza da göz atmanızı öneririz. Ayrıca, aşağıda yerel uygulamalarda üçüncü taraf bağlamı için sınırlamalara da göz atmayı unutmayın.

Ek olarak, Passkey'leri kullanarak kaynaklar arası ödeme akışlarına daha derinlemesine bir bakış için Ödeme Sağlayıcıları için Passkey'ler: 3. Taraf SDK Nasıl Oluşturulur yazımıza bakın.

Genel olarak, Passkey'leri iframe'ler içinde entegre etmek, temel olarak kullanıcı deneyimini (UX) ve güvenliği iyileştirerek çeşitli faydalar sunar. İşte bu avantajların bir dökümü:

Gelişmiş Kullanıcı Deneyimi

1. Açılır Pencere veya Yönlendirme Yok: Kullanıcılar, yönlendirmeler veya açılır pencereler olmadan doğrudan gömülü içerik içinde kimlik doğrulaması yapabilir, bu da daha akıcı ve daha az kesintili bir deneyimle sonuçlanır.
2. Siteler Arasında Tutarlı UX: Kimlik doğrulama akışlarını iframe'ler içine yerleştirmek, bir web sitesinin farklı bölümlerinde veya aynı kimlik doğrulama hizmetini kullanan farklı web sitelerinde tutarlı bir kullanıcı deneyimi sağlar.

İyileştirilmiş Güvenlik

1. Güvenli İşlemler: Ödemeler gibi senaryolar için, iframe'lerdeki Passkey'ler, kimlik doğrulamanın güvenli, gömülü bir bağlamda gerçekleşmesini sağlayarak işlemlerin güvenliğini artırır.
2. Farklı Web Sitelerinde Kullanıcı Hesabı Kullanımı: Birleşik kimlik kurulumlarında, kaynaklar arası iframe'lerdeki Passkey'ler, birden fazla alan adında güvenli ve verimli kimlik doğrulamasına olanak tanır.

iframe'lerde Passkey uygulamak, güvenlik ve işlevsellik sağlamak için bazı önemli adımları içerir. Geliştiriciler için ayrıntılı bir kılavuz sunuyoruz. Lütfen ayrıca https://cross-origin-iframe.vercel.app/ adresindeki örnek uygulamaya da bakın.

HTTP Permissions-Policy başlığı, bir belgede veya bir iframe öğesi içinde belirli tarayıcı özelliklerinin kullanımına izin vermeye veya bunları reddetmeye yardımcı olur. Bir iframe'de Passkey girişlerini etkinleştirmek için, publickey-credentials-get ve publickey-credentials-create izin politikalarını ayarlamanız gerekir. Politikalar, gömülü içeriğin kimlik doğrulaması (navigator.credentials.get({publicKey})) ve bir Passkey oluşturması (navigator.credentials.create({publicKey})) için gerekli WebAuthn API yöntemini çağırmasına izin verir.

<iframe src="https://passkeys.eu" allow="publickey-credentials-get; publickey-credentials-create"></iframe>

HTTP Permissions Policy daha önce Feature Policy olarak adlandırılıyordu. Feature Policy altında, bir kaynağı başlık kaynak listesine ekleyerek veya iframe etiketine bir allow özelliği ekleyerek kaynaklar arası bir iframe'e bir özellik verebilirdiniz. Permissions Policy ile, kaynak listesine kaynaklar arası bir çerçeve eklemek, o kaynak için iframe etiketinin allow özelliğini içermesini gerektirir. Yanıtta bir Permissions Policy başlığı yoksa, kaynak listesi varsayılan olarak * (tüm kaynaklar) olur. iframe'e allow özelliğini eklemek, özelliğe erişim sağlar.

Kaynak listesinde belirtilmeyen kaynaklar arası iframe'lerin, allow özelliği mevcut olsa bile özelliğe erişiminin engellendiğinden emin olmak için, geliştiriciler yanıtta Permissions Policy başlığını açıkça ayarlayabilir.

Chrome 88+ sürümünde, Feature Policy hala kullanılabilir ancak Permissions Policy için bir takma ad olarak işlev görür. Sözdizimi farklılıkları dışında mantık aynı kalır. Hem Permissions Policy hem de Feature Policy başlıkları aynı anda kullanıldığında, Permissions Policy başlığı öncelik kazanır ve Feature Policy başlığı tarafından ayarlanan değeri geçersiz kılar. Lütfen daha fazla uygulama detayı için Chrome ekibinin bu blog yazısına da bakın.

iframe'in kaynak URL'sinden gelen HTTP yanıt başlıklarının ilgili ´Permissions-Policy´ içerdiğinden emin olun. Bu, kaynaklar arası destek için çok önemlidir.

Permissions-Policy: publickey-credentials-get=*, publickey-credentials-create=*

Daha ayrıntılı kontrol için, iframe içeriğini yerleştirmesine izin verilen belirli kaynakları belirtebilirsiniz.

Permissions-Policy: publickey-credentials-get=("https://passkeys.eu"), publickey-credentials-create=("https://passkeys.eu")

iframe içeriğinin Passkey kimlik doğrulamasını tetiklemek için bir kullanıcı eylemi gerektirdiğinden emin olun. Bu, iframe içindeki tıklamalar veya form gönderimleri için olay dinleyicileri kullanılarak yapılabilir. Bu sürece geçici aktivasyon (transient activation) da denir.

document.getElementById('loginPasskeyButton').addEventListener('click',
    async () => {
        try {
            const [publicKeyCredentialRequestOptions](/glossary/publickeycredentialrequestoptions) = { /* Configuration options */ };
 
            const credential = await navigator.credentials.get({publicKey: publicKeyCredentialRequestOptions});
            // Handle the created credential
        } catch (err) {
            console.error('Error authenticating via passkey:', err);
        }
    });

Bu bağlamda, Safari kullanıcı hareketi gereksinimleri hakkındaki blog yazımıza da bakın.

Aşağıda, https://cross-origin-iframe.vercel.com adresinde barındırılan ve https://passkeys.eu aracılığıyla Passkey'ler için kaynaklar arası bir iframe kullanan bir index.html dosyasının tam bir örnek kod parçasını bulabilirsiniz.

<!doctype html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <meta
            http-equiv="Permissions-Policy"
            content="publickey-credentials-get=*; publickey-credentials-create=*"
        />
        <meta
            http-equiv="Content-Security-Policy"
            content="default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; font-src 'self'; img-src 'self'; frame-src https://passkeys.eu;"
        />
 
        <title>Cross-Origin iframe with Passkeys Demo</title>
        <style>
            body {
                font-family: Arial, sans-serif;
                padding: 20px;
                display: flex;
                flex-direction: column;
                justify-content: center;
                align-items: center;
                height: 100vh;
                margin: 0;
            }
 
            h1 {
                width: 100%;
                text-align: center;
            }
 
            .iframe-container {
                width: 80%;
                max-width: 800px;
                height: 80%;
                max-height: 600px;
                border: 1px solid #ccc;
                box-shadow: 0 0 10px rgba(0, 0, 0, 0.1);
                margin-top: 20px;
            }
 
            iframe {
                width: 100%;
                height: 100%;
                border: none;
            }
 
            @media (max-width: 768px) {
                h1 {
                    width: 95%;
                }
 
                .iframe-container {
                    width: 95%;
                }
            }
        </style>
    </head>
    <body>
        <h1>Cross-Origin iframe with Passkeys Demo</h1>
 
        <div class="iframe-container">
            <iframe
                src="https://passkeys.eu"
                allow="publickey-credentials-create; publickey-credentials-get"
            ></iframe>
        </div>
    </body>
</html>

iframe'lerde Passkey uygulamak, geliştiricilerin sorunsuz ve güvenli bir kullanıcı deneyimi sağlamak için ele alması gereken bir dizi zorlukla gelebilir. İşte sık karşılaşılan zorluklara ve bunların üstesinden gelme yollarına ayrıntılı bir bakış.

Sorun: İzin politikalarını yanlış yapılandırmak, iframe'in WebAuthn API'lerine erişmesini engelleyebilir.

“NotAllowedError - The 'publickey-credentials-create' feature is not enabled in this document. Permissions Policy may be used to delegate Web Authentication capabilities to cross-origin child frames.”

İzin politikalarını doğru bir şekilde eklemezseniz, tarayıcı aşağıdaki hatayı verir:

Çözüm:

• Allow Özelliğinin ve HTTP Başlıklarının Ayarlandığını İki Kez Kontrol Edin: allow özelliğinin ve HTTP başlıklarının doğru ayarlandığından emin olun. publickey-credentials-get ve publickey-credentials-create izinlerinin hem iframe öğesinde hem de sunucunun HTTP yanıt başlıklarında yer aldığını iki kez kontrol edin.
• Web Sunucusu Başlıkları Yerine Meta Başlıkları: İzin politikalarını tanımlamak için web sunucunuzdaki başlıkları ayarlamak yerine <meta/> başlıklarını kullanın.
• Permissions-Policy'de Virgül Yerine Noktalı Virgül: Daha önce, Permissions-Policy, Feature-Policy olarak adlandırılıyordu. Bir Feature-Policy'nin tek öğeleri noktalı virgül yerine virgülle ayrılırdı (Permissions-Policy için standart olan budur). iframe Permissions-Policy hala Feature-Policy sözdizimini takip eder ve bu nedenle virgül kullanır. Sandbox / allow özellikleri hala noktalı virgülle ayrılır (yukarıdaki kod parçacığına bakın).

İpucu: Permission-Policy başlıklarınızın doğru ayarlandığını düzgün bir şekilde test etmek için, tarayıcınızın geliştirici araçlarını açmanızı, Application'a (burada: Chrome geliştirici araçlarında) erişmenizi, Frames'e gitmenizi ve iframe'in kaynağını (burada: passkeys.eu/) aramanızı öneririz. Permissions-Policy doğru ayarlanmışsa, publickey-credential-create ve publickey-credential-get İzin Verilen Özellikler arasında listelenmelidir:

Sorun: Kaynaklar arası iframe Passkey oluşturma veya Passkey ile giriş yapma çalışmıyor ve tarayıcı konsolunuzda aşağıdaki hatayı görüyorsunuz.

"NotAllowedError - The origin of the document is not the same as its ancestors."

Bu hata, Safari tarayıcısını kullanırken ve iframe içinden bir Passkey oluşturmaya çalışırken ortaya çıkar, çünkü Safari kaynaklar arası iframe Passkey oluşturmayı desteklemez (yukarıya bakın).

Çözüm: Burada gerçekten yapabileceğiniz bir şey yok çünkü Safari henüz kaynaklar arası bir iframe içinden bir Passkey oluşturulmasını desteklemiyor (henüz).

Blocked a frame with origin "https://passkeys.eu" from accessing a frame with origin "https://cross-origin-iframe.vercel.app". Protocols, domains, and ports must match.

Bu hata doğrudan Passkey'lerle ilgili değil, daha çok genel olarak Safari'deki kaynaklar arası iframe'lerle ilgilidir. Safari'nin / WebKit'in üçüncü taraf çerezlerini engelleme girişimi veya üçüncü taraf bağlamında LocalStorage'a erişim kapsamında, JavaScript mantığının bazı kısımları bozulabilir.

Çözüm: Burada, iframe'lerinizin içinde üçüncü taraf çerezleri kullanmadığınızdan emin olmanız gerekir, çünkü bu bir hataya neden olur.

Sorun: Farklı tarayıcıların WebAuthn, iframe izinleri ve güvenlik özellikleri için farklı düzeylerde desteğe sahip olması, tutarsız davranışlara yol açtığında iframe tarayıcı uyumluluğu sorunları ortaya çıkar.

Çözüm: Bu iframe tarayıcı uyumluluğu sorunlarını azaltmak için, uygulamayı birden fazla tarayıcıda test ederek uyumluluğu sağlayın ve tarayıcıya özgü sorunları belirleyin.

Adımlar:

1. BrowserStack veya Sauce Labs gibi araçları kullanarak tarayıcılar arası testler yapın.
2. Tarayıcıya özgü düzeltmeler veya geri dönüşler uygulayarak tutarsızlıkları giderin.

Sorun: Yerel uygulamalar içinde Passkey gerektiren iframe'ler kullanırken, birinci taraf ve üçüncü taraf bağlamları arasında önemli bir ayrım yapılmalıdır:

• Birinci taraf bağlamı: Passkey'ler, uygulamayı çalıştıran şirketle aynı alan adına bağlıdır. Örneğin, kullanıcı kimlik doğrulaması için kendi alan adına dayanan bir e-ticaret uygulaması.
• Üçüncü taraf bağlamı: Farklı bir alan adı (örneğin, bir ödeme sağlayıcısı veya kimlik sağlayıcısı) Passkey oluşturma veya giriş akışını yönetir.

iOS üzerinde WKWebView veya bir Android WebView gibi gömülü bir WebView'da (EWV) - çağıran uygulama, web oturumu üzerinde kapsamlı kontrole sahiptir (örneğin, istekleri engelleme). Bu kurulum genellikle Passkey'leri yalnızca Passkey'in alan adı (Relying Party ID) uygulamanın alan adıyla eşleşiyorsa (birinci taraf) destekler. Ancak, bir ödeme sağlayıcısının kaynaklar arası akışı gibi bir üçüncü taraf senaryosunda - gömülü bir WebView genellikle gerekli Passkey kimlik bilgilerine erişemez çünkü satıcının uygulaması ve ödeme sağlayıcısının hizmeti farklı kaynaklardır. Passkey'ler için gerekli "bağlantılar" (alan adı, kimlik bilgisi ve kaynak arasında) gömülü bağlamda eşleşmeyecektir.

Bu sınırlama, birçok uygulamanın bir sistem WebView yaklaşımını benimsemesine yol açar (örneğin, iOS üzerinde ASWebAuthenticationSession veya Android üzerinde Özel Sekmeler). Sistem WebView'ları, üçüncü taraf sitesini (örneğin, ödeme sağlayıcısı) kaynaklar arası Passkey'lere doğru şekilde izin veren güvenli, tarayıcı benzeri bir ortamda izole eder - eğer tarayıcının kendisi bunu destekliyorsa. Bununla birlikte, Safari'nin mevcut iframe sınırlamalarının ASWebAuthenticationSession için de geçerli olduğunu unutmayın, bu nedenle Safari üçüncü taraf iframe'lerde belirli Passkey işlemlerine izin vermiyorsa, aynısı sistem WebView'ında da geçerli olacaktır. Şu anda "yerel" bir çözüm yoktur; karmaşık akışlar için en iyi uygulama - harici ödeme sağlayıcılarını içeren ödemeler gibi - gömülü bir WebView yerine bir sistem WebView'ı açmaktır.

Çözüm: Ödeme sağlayıcıları (ve alan adları arasında Passkey'lere dayanan diğer üçüncü taraflar) için, kullanıcının gömülü bir WebView'dan çıkarılıp bir sistem WebView'ına yönlendirildiğinden emin olmak için entegrasyonu dikkatlice planlayın. Tamamen gömülü bir akıştan daha az sorunsuz bir deneyim olsa da, genellikle Passkey işlevselliğinin üçüncü taraf hizmetleriyle çalışacağını garanti etmenin tek yoludur.

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

Yerel uygulamalar ve WebView'lar içinde üçüncü taraf Passkey'lerini yönetme hakkında daha fazla ayrıntı için, Ödeme Sağlayıcıları için Passkey'ler: Üçüncü Taraf Passkey Ödeme SDK'sı bölümüne göz atın.

Yukarıda tartışılan konular çeşitli senaryolar için geçerli olsa da, çok alan adlı akışların (örneğin, satıcı sitesi ve ödeme ağ geçidi) kullanıcı kimlik doğrulamasını kaynaklar arası iframe'ler içine yerleştirmesi gereken ödeme sağlayıcıları için özellikle önemlidir. Bu kurulumlarda:

• Kullanıcılar, yönlendirme açılır pencereleri olmadan sürtünmesiz, sayfa içi bir ödeme deneyimi ister.
• Ödeme sağlayıcıları, bir satıcının sitesine gömülü olsalar bile, kendi alan adlarında (örneğin, pay.provider.com) Passkey kaydını veya girişini yönetmelidir.
• Safari kısıtlamaları ve gömülü WebView sınırlamaları genellikle iframe'lerde üçüncü taraf Passkey oluşturulmasını engeller.

Bu zorlukların üstesinden gelmek ve Apple Pay'e benzer güvenli, sorunsuz bir deneyim oluşturmak için, ödeme sağlayıcıları genellikle hibrit bir yaklaşım benimser - iframe tabanlı entegrasyonu Safari (veya daha eski tarayıcılar) için bir yönlendirme yedeği ile birleştirir. Bazı durumlarda, gömülü bir WebView'ın Passkey'lere hiç izin vermemesi durumunda sistem tarayıcısı akışları (örneğin, iOS üzerinde ASWebAuthenticationSession) zorunlu hale gelir.

Bu ödemeye özgü senaryolara derinlemesine bir bakış için - iframe vs. yönlendirme karşılaştırmaları, yerel uygulama hususları ve yüksek Passkey benimsenmesi için en iyi uygulamalar dahil - özel makalemize bakın:

60-page Enterprise Passkey Whitepaper:
Learn how leaders get +80% passkey adoption. Trusted by Rakuten, Klarna & Oracle

Get free Whitepaper

Özellikle:

• Strateji A: Kaynaklar Arası bir iframe Gömme Passkey oluşturma ve girişini satır içinde nasıl yöneteceğinizi açıklar ve burada tanıtılan Permissions-Policy ayarlarına atıfta bulunur.
• Strateji B: Daha Geniş Uyumluluk için Yönlendirme Tabanlı Yaklaşım çoğu kaynaklar arası tuzağı atlatan daha basit bir entegrasyon gösterir, ancak satıcının alan adından ayrılma pahasına.
• Sistem WebView yerel uygulamalar için esastır, çünkü gömülü WebView'lar sık sık üçüncü taraf Passkey akışlarını bozar.

Bu tamamlayıcı kılavuz, işlemleri güvence altına almak, Safari'nin kaynaklar arası kısıtlamalarını aşmak ve 3. taraf bağlamlarında Passkey kullanımını optimize etmek için derinlemesine stratejiler sunar. Bu makaledeki teknik adımları bu ödeme odaklı yöntemlerle birleştirerek, çevrimiçi ödemeler için güvenlik ve kullanıcı deneyiminin bir sonraki seviyesini açan, doğrudan bir iframe içinde sürtünmesiz, oltalamaya dayanıklı bir ödeme akışı sunabilirsiniz.

Passkey'leri iframe'ler içinde entegre etmek, hem güvenliği hem de kullanıcı deneyimini iyileştirerek kullanıcı kimlik doğrulamasını önemli ölçüde geliştirir. Bu, yönlendirmelere veya açılır pencerelere gerek kalmadan sorunsuz kimlik doğrulamasına olanak tanır ve çeşitli bölümler ve siteler arasında tutarlı bir kullanıcı deneyimi sağlar.

Shopify'ın Passkey'leri giriş bileşenine entegrasyonu gibi gerçek dünya uygulamaları, bu yaklaşımın pratik faydalarını ve esnekliğini göstermektedir.