İlgili Kaynak İstekleri'nin çözdüğü sorun
Geçiş anahtarları belirli bir web sitesine bağlıdır ve yalnızca oluşturuldukları web sitesinde oturum açmak için kullanılabilir.
Bu, bağlı tarafça belirtilir
ID (RP ID) (example.com alanı için oluşturulan geçiş anahtarları için www.example.com
veya example.com
olabilir).
Kısıtlanmış taraf kimlikleri ise geçiş anahtarlarının her yerde kimlik doğrulaması yapmak şu konularda sorunlara yol açar:
- Birden fazla alan adına sahip siteler: Kullanıcılar, aşağıdaki işlemler için aynı geçiş anahtarını kullanamaz.
ülkeye özgü farklı alan adlarında oturum açmak (örneğin,
example.com
veexample.co.uk
) aynı şirket tarafından yönetiliyor. - Markalı alanlar: Kullanıcılar,
tek bir marka tarafından kullanılan farklı alan adları (örneğin
acme.com
veacmerewards.com
) tıklayın. - Mobil uygulamalar: Mobil uygulamaların genellikle kendi alanı yoktur. Bu durum, zorlayıcı bir hale geldi.
Bazı çözümler, kimlik federasyonuna dayalıdır. ancak bazı durumlarda elverişsizdir. İlgili Kaynak İstekleri teklifi çözmüş olursunuz.
Çözüm
Entegre İlgili Kaynak İstekleri Bir web sitesi, RP kimliğini kullanmasına izin verilen kaynakları belirtebilir.
Bu sayede, kullanıcılar aynı geçiş anahtarını birden fazla sitede tekrar kullanabilir.
İlgili Kaynak İsteklerini kullanmak için
belirli URL: https://{RP ID}/.well-known/webauthn
. example.com
şunu yapmak istiyorsa:
ek kaynakların bunu Kısıtlanmış Taraf Kimliği olarak kullanmasına izin veriyorsa aşağıdaki gibi sunulmalıdır:
dosya: https://example.com/.well-known/webauthn:
{
"origins": [
"https://example.co.uk",
"https://example.de",
"https://example-rewards.com"
]
}
Bu sitelerden herhangi biri bir dahaki sefere geçiş anahtarı oluşturma çağrısı yaptığında
(navigator.credentials.create
) veya kimlik doğrulama (navigator.credentials.get
)
bir kısıtlanmış taraf kimliği olarak example.com
kullanan bir Kısıtlanmış Taraf Kimliği
istekte bulunan kaynakla eşleşmiyor. Tarayıcı, İlgili Kaynak'ı destekliyorsa
istiyorsa, öncelikle bir
https://{RP ID}/.well-known/webauthn
konumunda webauthn
dosyası var. Dosya mevcutsa
tarayıcı, isteği yapan kaynağın
dosyası olarak kaydedebilirsiniz. Bu durumda geçiş anahtarı oluşturma veya kimlik doğrulama adımlarına devam edilir.
Tarayıcı, İlgili Kaynak İstekleri'ni desteklemiyorsa bir SecurityError
atar.
Tarayıcı desteği
- Chrome: Chrome'dan itibaren desteklenir 128'i seçin.
- Safari: macOS 15 beta 3'ten itibaren ve mobil iOS 18 beta 3'ten itibaren desteklenir.
- Firefox: Pozisyon bekleniyor.
İlgili Kaynak İstekleri oluşturma
Aşağıdaki demoda https://ror-1.glitch.me
ve https://ror-2.glitch.me
olmak üzere iki site örneği kullanılmıştır.
.
Kullanıcıların her iki sitede de aynı geçiş anahtarıyla oturum açmasını sağlamak için İlgili Kaynak İstekleri'ni kullanır. Böylece ror-2.glitch.me
, ror-1.glitch.me
adresini RP kimliği olarak kullanır.
Demo
https://ror-2.glitch.me, ror-1.glitch.me'yi RP kimliği olarak kullanmak için İlgili Kaynak İsteklerini uygular. Bu nedenle, hem ror-1
hem de ror-2
, geçiş anahtarı oluştururken veya kimlik doğrulaması yaparken ror-1.glitch.me
kimliğini RP kimliği olarak kullanır.
.
Ayrıca bu siteler genelinde paylaşılan bir geçiş anahtarı veritabanı uyguladık.
Aşağıdaki kullanıcı deneyimini gözlemleyin:
- Kısıtlanmış Taraf kimliği
ror-1
olmasına rağmen (ror-2
değil)ror-2
üzerinde başarıyla geçiş anahtarı oluşturabilir ve bu geçiş anahtarını kullanarak kimlik doğrulaması yapabilirsiniz. ror-1
veyaror-2
cihazlarında geçiş anahtarı oluşturduktan sonra hemror-1
hem deror-2
üzerinde geçiş anahtarıyla kimlik doğrulaması yapabilirsiniz.ror-2
, RP kimliği olarakror-1
değerini belirttiği için bu sitelerin herhangi birinden geçiş anahtarı oluşturma veya kimlik doğrulama isteğinde bulunmak, ror-1'de istekte bulunmayla aynıdır. Kısıtlanmış taraf kimliği, isteği bir kaynağa bağlayan tek şeydir.ror-1
veyaror-2
cihazlarda geçiş anahtarı oluşturduğunuzda hemror-1
hem deror-2
cihazlarda Chrome tarafından otomatik olarak doldurulabilir.- Bu sitelerin herhangi birinde oluşturulan kimlik bilgisinin RP kimliği
ror-1
olur.
![Chrome her iki sitede de otomatik olarak doldurulur.](https://web.dev/static/articles/webauthn-related-origin-requests/image/chrome-autofill.jpg?hl=tr)
Kodu inceleyin:
- ror-1 kod tabanında ayarlanmış
./well-known/webauthn
dosyasını görün. - ror-2 kod tabanında
RP_ID_ROR
oluşumunu görün.
1. Adım: Paylaşılan hesap veritabanını uygulayın
Kullanıcılarınızın aynı geçiş anahtarıyla
site-1
ve site-2
, bu hesaplar arasında paylaşılan bir hesap veritabanını uygular
iki site var.
2. Adım: .well-known/webauthn JSON dosyanızı site-1 konumunda oluşturun
Öncelikle site-1.com
uygulamasını, site-2.com
tarafından bir
Kısıtlanmış Taraf Kimliği. Bunun için webauthn JSON dosyanızı oluşturun:
{
"origins": [
"https://site-2.com"
]
}
JSON nesnesi, değeri 1 dizisi olan kaynak adlı anahtarlar içermelidir veya daha fazla dize içerebilir.
Önemli sınırlama: Maksimum 5 etiket
Bu listenin her öğesi, eTLD + 1 etiketini ayıklamak için işlenir.
Örneğin, hem example.co.uk
hem de example.de
eTLD + 1 etiketlerinin ikisi de
example
. Ancak example-rewards.com
öğesinin eTLD + 1 etiketi example-rewards
.
Chrome'da maksimum etiket sayısı 5'tir.
3. Adım: .well-known/webauthn JSON dosyanızı site-1 içinde sunun
Ardından, JSON dosyanızı site-1.com/.well-known/webauthn
altında sunun.
Örneğin, ekspres modda:
app.get("/.well-known/webauthn", (req, res) => {
const origins = {
origins: ["https://site-2.com"],
};
return res.json(origins);
});
Burada, halihazırdares.json
doğru content-type
('application/json'
);
4. Adım: Site-2'de istediğiniz kısıtlanmış taraf kimliğini belirtin
site-2
kod tabanınızda, gereken her yerde site-1.com
kimliğini kısıtlanmış taraf kimliği olarak ayarlayın:
- Kimlik bilgisi oluşturulduktan sonra:
- Kimlik bilgisi oluşturma sırasında
site-1.com
kimliğini kısıtlanmış taraf kimliği olarak ayarlayın.options
ilenavigator.credentials.create
ön uç çağrısıyla yapılır ve genellikle sunucu tarafında oluşturulur. - Kimlik bilgisini çalıştırırken
site-1.com
öğesini beklenen kısıtlanmış taraf kimliği olarak ayarlayın. doğrulamaları gerekir.
- Kimlik bilgisi oluşturma sırasında
- Kimlik doğrulama sonrasında:
options
kimlik doğrulamasında Kısıtlanmış Taraf Kimliği olaraksite-1.com
değerini ayarlayınnavigator.credentials.get
ön uç çağrısına iletilenler ve tarafından oluşturulur.site-1.com
öğesini şurada doğrulanacak beklenen RP kimliği olarak ayarlayın: sunucu.
Sorun giderme
![Chrome'daki hata mesajı pop-up'ı.](https://web.dev/static/articles/webauthn-related-origin-requests/image/error-file-not-found.jpg?hl=tr)
![Chrome'daki hata mesajı pop-up'ı.](https://web.dev/static/articles/webauthn-related-origin-requests/image/error-file-incorrect.jpg?hl=tr)
Dikkat edilmesi gereken diğer noktalar
Geçiş anahtarlarını siteler ve mobil uygulamalar arasında paylaşma
İlgili Kaynak İstekleri, kullanıcılarınızın geçiş anahtarını birden fazla cihazda tekrar kullanmasına olanak tanır. kullanın. Kullanıcılarınızın geçiş anahtarını bir web sitesinde ve mobil uygulamada yeniden kullanmasına izin vermek için: şu teknikleri kullanın:
- Chrome'da: Dijital Varlık Bağlantılar başlıklı makaleyi inceleyin. Daha fazla bilgiyi şuradan edinebilirsiniz: Dijital varlık bağlantıları için destek ekleyin.
- Safari'de: İlişkili alanlar.
Şifreleri siteler arasında paylaşma
İlgili Kaynak İstekleri, kullanıcılarınızın siteler arasında geçiş anahtarını tekrar kullanmasına olanak tanır. Siteler arasında şifre paylaşımına ilişkin çözümler, şifre yöneticilerine göre değişiklik gösterir. Google Şifre Yöneticisi için Dijital Öğe Bağlantıları 'nı kullanın. Safari'de farklı bir sistem var.
Kimlik bilgisi yöneticilerinin ve kullanıcı aracılarının rolü
Bu, site geliştiricisi olarak sizin kapsamınızın dışında kalır ancak ne kadar uzun sürece teriminde, RP Kimliği, kullanıcı aracısında kullanıcının görebildiği bir kavram olmamalıdır. kimlik bilgisi yöneticisi olarak oturum açın. Bunun yerine kullanıcı aracıları ve kimlik bilgileri Yöneticiler, kullanıcılara kimlik bilgilerinin nerede kullanıldığını göstermelidir. Bu değişiklik zaman alır. Geçici bir çözüm, hem mevcut web sitesi ve orijinal kayıt sitesi.