--- url: 'https://www.corbado.com/tr/blog/iframe-passkeys-webauthn-kullanimi' title: 'Passkeys ve iframe''ler: Bir Passkey ile Nasıl Hesap Oluşturulur ve Giriş Yapılır?' description: 'Rehberimizle kaynaklar arası iframe''lerde Passkey''ler ile nasıl hesap oluşturulacağını ve giriş yapılacağını keşfedin. WebAuthn''da iframe''ler, güvenlik politikaları ve uygulama hakkında bilgi edinin.' lang: 'tr' author: 'Vincent Delitz' date: '2025-07-15T13:22:29.905Z' lastModified: '2026-03-27T07:08:37.303Z' keywords: 'iframe, kaynaklar arası, passkeys, webauthn' category: 'WebAuthn Know-How' --- # Passkeys ve iframe'ler: Bir Passkey ile Nasıl Hesap Oluşturulur ve Giriş Yapılır? ### Hızlı Başvuru: Kaynaklar Arası Passkey Desteği (Temmuz 2025) | Tarayıcı | **Kaynaklar arası giriş**
(`navigator.credentials.get`) | **Kaynaklar arası oluşturma**
(`navigator.credentials.create`) | | --------------- | ---------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | **Chrome/Edge** | ✅ [Chrome 84 (Temmuz 2020)](https://blog.chromium.org/2020/05/chrome-84-beta-web-otp-web-animations.html) | ✅ [Chrome 123 (Mart 2024)](https://groups.google.com/a/chromium.org/g/blink-dev/c/Sq2WAVbPz6g) | | **Firefox** | ✅ [Firefox 118 (Eylül 2023)](https://bugzilla.mozilla.org/show_bug.cgi?id=1460986) | ✅ [Firefox 123 (Şubat 2024)](https://bugzilla.mozilla.org/show_bug.cgi?id=1870863) | | **Safari** | ✅ [Safari 15.5 (Mayıs 2022)](https://bugs.webkit.org/show_bug.cgi?id=222240) | ❌ [Desteklenmiyor](#62-zorluk-2-safaride-kaynaklar-arasi-iframe-sorunlari) | **Açıklama**\ ✅ = destekleniyor ❌ = desteklenmiyor ## 1. Giriş: iframe'de Passkey'ler Nasıl Kullanılır? Her geçen hafta daha fazla kuruluş Passkey kullanıma sunduğunu duyuruyor (örneğin son zamanlarda [Visa](https://www.corbado.com/blog/visa-passkeys), [Mastercard](https://www.corbado.com/blog/mastercard-passkeys) veya [Vercel](https://www.corbado.com/blog/vercel-passkeys)). 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](https://www.corbado.com/blog/iframe-passkeys-webauthn)'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](https://www.corbado.com/tr/blog/tamamen-sifresiz-sisteme-nasil-gecilir) ve WebAuthn bağlamında, [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn)'ler özellikle güvenlik ve kullanıcı etkileşimleri konusunda kendi zorluklarını beraberinde getirir. 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](https://www.corbado.com/blog/iframe-passkeys-webauthn) 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. ## 2. iframe Türleri 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. ### 2.1 Temel iframe **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. `` Bu temel iframe genellikle bir makale gibi statik içeriği bir web sayfasına dahil etmek için kullanılır. ### 2.2 Duyarlı iframe **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. `` CSS medya sorguları, iframe'in görüntü alanı boyutuna göre dinamik olarak ayarlanmasını sağlamak için de kullanılabilir. ### 2.3 Güvenli iframe (Sandboxed iframe) **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. ` ` **sandbox** özelliği, çeşitli kısıtlamalar içerebilir, örneğin: `` **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. ### 2.4 Kaynaklar Arası iframe / Siteler Arası iframe 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. İşte kaynaklar arası ve aynı kaynaklı kavramlarını göstermek için örnekler: **Kaynaklar arası örnek:** **[https://payment.example.com](https://payment.example.com)** adresinden gelen içeriği, **[https://www.mystore.com](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](https://www.example.com/shop)** adresinden gelen içeriği, **[https://www.example.com/blog](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. `` ## 3. iframe'ler Passkey'leri Nasıl Destekler? 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](https://www.corbado.com/tr/blog/digital-credentials-api) 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](https://www.corbado.com/tr/blog/tamamen-sifresiz-sisteme-nasil-gecilir) / 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](https://www.corbado.com/tr/blog/digital-credentials-api) / 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](https://www.corbado.com/tr/blog/digital-credentials-api) işlemleri için) devam eden [WebAuthn Seviye 3](https://www.corbado.com/tr/blog/passkeys-prf-webauthn-uctan-uca-sifreleme) 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. ### 3.1 Kaynaklar Arası iframe'lerde Passkey ile Giriş Yapma 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: | **Tarayıcı/Standart** | **Birinci Taraf Bağlamı** | **Üçüncü Taraf Bağlamı** | | ---------------------------- | ------------------------- | ------------------------ | | WebAuthn Seviye 2'de Gerekli | ✔️ | ✔️ | | WebAuthn Seviye 3'te Gerekli | ✔️ | ✔️ | | Chrome'da Uygulandı | ✔️ | ✔️ | | Firefox'ta Uygulandı | ✔️ | ✔️ | | Safari'de Uygulandı | ✔️ | ✔️ | ### 3.2 Kaynaklar Arası iframe'lerde Passkey Oluşturma 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: | **Tarayıcı/Standart** | **Birinci Taraf Bağlamı** | **Üçüncü Taraf Bağlamı** | | ------------------------------------------------------------------------------- | ------------------------------------------------------------ | -------------------------------------------------------------------------- | | WebAuthn Seviye 2'de Gerekli | ✔️ [Ayrıntılar](https://issues.chromium.org/issues/40258856) | ❌ | | WebAuthn Seviye 3'te Gerekli | ✔️ [Ayrıntılar](https://issues.chromium.org/issues/40258856) | ✔️ [Ayrıntılar](https://issues.chromium.org/issues/40258856) | | Chrome'da Uygulandı | ✔️ [Ayrıntılar](https://issues.chromium.org/issues/40258856) | ✔️ [Ayrıntılar](https://issues.chromium.org/issues/40258856) | | Firefox'ta Uygulandı | ✔️ [Ayrıntılar](https://issues.chromium.org/issues/40258856) | ✔️ [Ayrıntılar](https://github.com/mozilla/standards-positions/issues/964) | | [Safari](https://github.com/WebKit/standards-positions/issues/304)'de Uygulandı | ✔️ [Ayrıntılar](https://issues.chromium.org/issues/40258856) | Uygulama için sinyal bekleniyor | Bu gelişme ve destek hakkında daha fazla bilgi edinmek isterseniz, bu [GitHub konusuna](https://github.com/w3c/webauthn/issues/1656) ve bu [Pull Request'e](https://github.com/w3c/webauthn/pull/1801) göz atmanızı öneririz. ### 3.3 iframe'lerde Passkey Kullanım Senaryoları Kaynaklar arası iframe'lerde Passkey'leri desteklemek için iki ana kullanım senaryosu vardır. #### 3.3.1 Birleşik Kimlik (Federated Identity) 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](https://www.corbado.com/blog/kayak-passkeys) gibi çok uluslu bir şirketsiniz ve farklı bölgeler için farklı alan adlarınız var: - [www.kayak.com](https://www.kayak.com) - [www.kayak.us](https://www.kayak.us) - [www.kayak.de](https://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](http://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](https://www.kayak.com) kaynağından bir iframe kullanırsınız. Yani [www.kayak.us](https://www.kayak.us) ve [www.kayak.de](https://www.kayak.de) üzerinde [www.kayak.com](https://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](https://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)](https://passkeys.dev/docs/advanced/related-origins/) 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. #### 3.3.2 Ödemeler 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](http://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](http://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](https://www.corbado.com/glossary/relying-party) ID'sine, örneğin "[revolut](https://www.corbado.com/blog/revolut-passkeys).com"a bağlı bir Passkey ile bankanın web sitesine giriş yapar. Kullanıcıyı ödeme sürecinde satıcının web sitesinden ([www.amazon.com](https://www.amazon.com)) bankanın web sitesine ([www.revolut.com](https://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](https://www.amazon.com) adresinde kalır ve [www.revolut.com](https://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: | **Tüketiciler** | **Satıcılar** | **Bankalar** | | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | | | Ödeme ve [Passkey'ler](https://www.corbado.com/tr/blog/tamamen-sifresiz-sisteme-nasil-gecilir) bağlamında, Güvenli Ödeme Onayı (SPC) ve Passkey'lerle [dinamik bağlama](https://www.corbado.com/tr/blog/dinamik-baglama-passkeys-spc) 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. ## 4. iframe'lerde Passkey Kullanmanın Faydaları 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](https://www.corbado.com/passkeys-for-payment) 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. ## 5. iframe'lerde Passkey Uygulamak için Adım Adım Kılavuz 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/](https://cross-origin-iframe.vercel.app/) adresindeki örnek uygulamaya da bakın. ![Cross-Origin iframe Passkey Demo](https://www.corbado.com/website-assets/cross_origin_iframe_passkey_demo_8879588a51.png) ### 5.1 İzin Politikasını publickey-credentials-get ve publickey-credentials-create olarak ayarlayı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](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy/publickey-credentials-get) ve [publickey-credentials-create](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy/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. `` 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](https://developer.chrome.com/docs/privacy-security/permissions-policy) da bakın. ### 5.2 HTTP Başlıklarını Yapılandırın iframe'in kaynak URL'sinden gelen HTTP yanıt başlıklarının ilgili ´[Permissions-Policy](https://www.corbado.com/faq/enable-passkeys-iframe)´ 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")` ### 5.3 Kullanıcı Etkinleştirmesini Yönetin 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)](https://developer.mozilla.org/en-US/docs/Glossary/Transient_activation) da denir. ```javascript document.getElementById('loginPasskeyButton').addEventListener('click', async () => { try { const [publicKeyCredentialRequestOptions](https://www.corbado.com/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. ### 5.4 Örnek Uygulama Aşağıda, [https://cross-origin-iframe.vercel.com](https://cross-origin-iframe.vercel.com) adresinde barındırılan ve [https://passkeys.eu](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. ```html Cross-Origin iframe with Passkeys Demo

Cross-Origin iframe with Passkeys Demo

``` ## 6. Sık Karşılaşılan Zorluklar ve Bunların Üstesinden Gelme Yolları 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ış. ### 6.1 Zorluk 1: İzin Politikası Yapılandırması **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: ![passkey iframe permission policy configuration](https://www.corbado.com/website-assets/passkey_iframe_permission_policy_configuration_4819cbebec.png) **Çö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 `` 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: ![passkey permissions policy allowed features](https://www.corbado.com/website-assets/passkey_permissions_policy_allowed_features_ffadbc4302.png) ### 6.2 Zorluk 2: Safari'de Kaynaklar Arası iframe Sorunları **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). ![passkey iframe not allowed error](https://www.corbado.com/website-assets/passkey_iframe_not_allowed_error_a217258310.png) **Çö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](https://passkeys.eu)" from accessing a frame with origin "[https://cross-origin-iframe.vercel.app](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](https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/) veya üçüncü taraf bağlamında LocalStorage'a erişim kapsamında, JavaScript mantığının bazı kısımları bozulabilir. ![passkey iframe third party cookie](https://www.corbado.com/website-assets/passkey_iframe_third_party_cookie_199bb288c3.png) **Çözüm:** Burada, iframe'lerinizin içinde üçüncü taraf çerezleri kullanmadığınızdan emin olmanız gerekir, çünkü bu bir hataya neden olur. ### 6.3 Zorluk 3: Tarayıcı Uyumluluğu **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. ### 6.4 Zorluk 4: Yerel Uygulamalarda iframe'ler **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](https://www.corbado.com/passkeys-for-e-commerce) 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](https://www.corbado.com/blog/how-to-enable-passkeys-ios) üzerinde [WKWebView](https://www.corbado.com/blog/native-app-passkeys) veya bir [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) [WebView](https://www.corbado.com/blog/native-app-passkeys) 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](https://www.corbado.com/blog/native-app-passkeys) 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](https://www.corbado.com/blog/how-to-enable-passkeys-ios) üzerinde [ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys) veya [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) üzerinde Özel Sekmeler). Sistem [WebView](https://www.corbado.com/blog/native-app-passkeys)'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](https://www.corbado.com/blog/native-app-passkeys) 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. 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. ## 7. Ödeme Sağlayıcıları için Ek Not: Kaynaklar Arası iframe'ler ve Üçüncü Taraf SDK'ları 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](https://www.corbado.com/blog/how-to-enable-passkeys-ios) üzerinde [ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys)) 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: Özellikle: - [**Strateji A: Kaynaklar Arası bir iframe Gömme**](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk#51-strategy-a-embedding-a-cross-origin-iframe-pros--cons) 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**](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk#52-strategy-b-redirect-based-approach-for-broader-compatibility) ç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**](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk#63-using-system-webview-or-redirect-for-third-party-passkeys) 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](https://www.corbado.com/passkeys-for-payment) 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. ## 8. Sonuç 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](https://shopify.engineering/supporting-passkeys-in-shop-authentication-flows) gibi gerçek dünya uygulamaları, bu yaklaşımın pratik faydalarını ve esnekliğini göstermektedir.