Kaynak istekleriyle ilgili sorunların çözümü
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ğımlı taraf kimliğinde (RP kimliği) belirtilir. Bu kimlik, example.com alanı için oluşturulan geçiş anahtarları için www.example.com
veya example.com
olabilir.
RP kimlikleri, geçiş anahtarlarının her yerde kimlik doğrulama için tek bir kimlik bilgisi olarak kullanılmasını engellese de aşağıdakiler için sorun oluşturur:
- Birden fazla alan adına sahip siteler: Kullanıcılar, aynı şirket tarafından yönetilen ülkeye özgü farklı alanlarda (ör.
example.com
veexample.co.uk
) oturum açmak için aynı geçiş anahtarını kullanamaz. - Markalı alanlar: Kullanıcılar, tek bir marka tarafından kullanılan farklı alanlarda (örneğin,
acme.com
veacmerewards.com
) aynı kimlik bilgilerini kullanamaz. - Mobil uygulamalar: Mobil uygulamalar genellikle kendi alanlarına sahip olmadığından kimlik bilgisi yönetimini zorlaştırır.
Kimlik federasyonuna dayalı ve iframe'lere dayalı bazı geçici çözümler olsa da bunlar bazı durumlarda uygun değildir. İlgili Kaynak İstekleri bir çözüm sunar.
Çözüm
Web sitesi, İlgili Kaynak İstekleri ile kendi RP kimliğini kullanmasına izin verilen kaynakları belirtebilir.
Bu sayede kullanıcılar, işlettiğiniz birden fazla sitede aynı geçiş anahtarını yeniden kullanabilir.
İlgili Kaynak İstekleri'ni kullanmak için belirli bir URL'de (https://{RP ID}/.well-known/webauthn
) özel bir JSON dosyası sunmanız gerekir. example.com
, ek kaynakların bunu RP kimliği olarak kullanmasına izin vermek istiyorsa https://example.com/.well-known/webauthn:
adresinde aşağıdaki dosyayı yayınlamalıdır.
{
"origins": [
"https://example.co.uk",
"https://example.de",
"https://example-rewards.com"
]
}
Bu sitelerden herhangi biri, RP kimliği olarak example.com
kullanan bir sonraki geçiş anahtarı oluşturma (navigator.credentials.create
) veya kimlik doğrulama (navigator.credentials.get
) çağrısında bulunduğunda tarayıcı, istekte bulunan kaynakla eşleşmeyen bir RP kimliği fark eder. Tarayıcı, İlgili Kaynak İstekleri'ni destekliyorsa önce https://{RP ID}/.well-known/webauthn
adresinde bir webauthn
dosyası arar. Dosya mevcutsa tarayıcı, isteği yapan kaynağın söz konusu dosyada izin verilenler listesine eklenip eklenmediğini kontrol eder. Bu durumda geçiş anahtarı oluşturma veya kimlik doğrulama adımlarına devam edilir.
Tarayıcı, İlgili Kaynak İstekleri'ni desteklemiyorsa SecurityError
hatası verir.
Tarayıcı desteği
- Chrome: Chrome 128 ve sonraki sürümlerde desteklenir.
- Safari: macOS 15 beta 3 ve iOS 18 beta 3 mobil sürümlerinden itibaren desteklenir.
- Firefox: Konum bekleniyor.
İlgili Kaynak İstekleri'ni ayarlama
Aşağıdaki demoda https://ror-1.glitch.me
ve https://ror-2.glitch.me
adlı iki site örneği kullanılmaktadır.
Kullanıcıların bu iki sitede de aynı geçiş anahtarıyla oturum açabilmesini sağlamak için ror-2.glitch.me
'ın RP kimliği olarak ror-1.glitch.me
kullanmasına izin vermek üzere İlgili Kaynak İstekleri'ni kullanır.
Demo
https://ror-2.glitch.me, ror-1.glitch.me'yi RP kimliği olarak kullanmak için İlgili Kaynak İstekleri'ni 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 sitelerde paylaşılan bir geçiş anahtarı veritabanı da uyguladık.
Aşağıdaki kullanıcı deneyimini gözlemleyin:
- RP kimliği
ror-1
(ror-2
değil) olsa bileror-2
'te geçiş anahtarı oluşturabilir ve bu anahtarla 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. RP kimliği, bir isteği bir kaynağa bağlayan tek öğedir.ror-1
veyaror-2
cihazlarda geçiş anahtarı oluşturduğunuzda hemror-1
hem deror-2
cihazlarda Chrome tarafından otomatik olarak doldurulabilir.- Bu sitelerden herhangi birinde oluşturulan kimlik bilgilerinin RP kimliği
ror-1
olur.
Kodu göster:
- ror-1 kod tabanında oluşturulan
./well-known/webauthn
dosyasına bakın. - ror-2 kod tabanında
RP_ID_ROR
oluşumunu görebilirsiniz.
1. Adım: Paylaşılan hesap veritabanını uygulayın
Kullanıcılarınızın site-1
ve site-2
platformlarında aynı geçiş anahtarıyla oturum açabilmesini istiyorsanız bu iki site arasında paylaşılan bir hesap veritabanı uygulayın.
2. adım: site-1'de .well-known/webauthn JSON dosyanızı oluşturun
Öncelikle site-1.com
'ü, site-2.com
'un RP kimliği olarak kullanmasına izin verecek şekilde yapılandırın. Bunun için webauthn JSON dosyanızı oluşturun:
{
"origins": [
"https://site-2.com"
]
}
JSON nesnesi, değeri web kaynaklarını içeren bir veya daha fazla dizenin dizisi olan origins adlı bir anahtar içermelidir.
Önemli sınırlama: Maksimum 5 etiket
Bu listenin her öğesi, eTLD + 1 etiketini ayıklamak için işlenir.
Örneğin, example.co.uk
ve example.de
için eTLD + 1 etiketleri example
'dir. Ancak example-rewards.com
için eTLD + 1 etiketi example-rewards
.
Chrome'da maksimum etiket sayısı 5'tir.
3. adım: .well-known/webauthn JSON dosyanızı site-1'de yayınlayın
Ardından, JSON dosyanızı site-1.com/.well-known/webauthn
altında yayınlayın.
Örneğin, express'te:
app.get("/.well-known/webauthn", (req, res) => {
const origins = {
origins: ["https://site-2.com"],
};
return res.json(origins);
});
Burada, doğru content-type
('application/json'
) değerini zaten ayarlayan express res.json
kullanıyoruz;
4. adım: site-2'de istediğiniz RP kimliğini belirtin
site-2
kod tabanınızda, gereken her yerde RP kimliği olarak site-1.com
değerini ayarlayın:
- Kimlik bilgisi oluşturulduktan sonra:
- Kimlik bilgisi oluşturma işleminde RP kimliği olarak
site-1.com
'ü ayarlayın. Bu kimlik,navigator.credentials.create
ön uç çağrısına aktarılır ve genellikle sunucu tarafında oluşturulur.options
- Veritabanınıza kaydetmeden önce kimlik bilgisi doğrulamalarını çalıştırırken
site-1.com
değerini beklenen RP kimliği olarak ayarlayın.
- Kimlik bilgisi oluşturma işleminde RP kimliği olarak
- Kimlik doğrulamasından sonra:
site-1.com
kimliğini,navigator.credentials.get
ön uç çağrısına iletilen ve genellikle sunucu tarafında oluşturulan kimlik doğrulamaoptions
'da RP kimliği olarak ayarlayın.- Kullanıcının kimliğini doğrulamadan önce kimlik bilgisi doğrulama işlemlerini çalıştırdığınızda
site-1.com
değerini, sunucuda doğrulanması beklenen RP kimliği olarak ayarlayın.
Sorun giderme
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 birden fazla sitede geçiş anahtarını yeniden kullanmasına olanak tanır. Kullanıcılarınızın bir geçiş anahtarını web sitesinde ve mobil uygulamada yeniden kullanmasına izin vermek için aşağıdaki teknikleri kullanın:
- Chrome'da: Dijital Varlık Bağlantıları. Daha fazla bilgi için Dijital Öğe Bağlantıları için destek ekleme başlıklı makaleyi inceleyin.
- 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ı yeniden kullanmasına olanak tanır. Siteler arasında şifre paylaşımı için sunulan çö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 farklı bir sisteme sahip.
Kimlik bilgisi yöneticilerinin ve kullanıcı aracılarının rolü
Bu, site geliştiricisi olarak kapsamınızın dışındadır ancak uzun vadede RP kimliğinin, kullanıcı aracısında veya kullanıcılarınızın kullandığı kimlik bilgisi yöneticisinde kullanıcı tarafından görülebilen bir kavram olmaması gerektiğini unutmayın. Bunun yerine kullanıcı aracıları ve kimlik bilgisi yöneticileri, kullanıcılara kimlik bilgilerinin nerede kullanıldığını göstermelidir. Bu değişikliğin uygulanması zaman alacaktır. Geçici bir çözüm, hem mevcut web sitesini hem de orijinal kayıt sitesini görüntülemektir.