Etki alanları arası kimlik doğrulaması için JWT kullanarak çoklu oturum açma akışı

Json Web TokenKimlik doğrulama için JWT ( ) kullanımı hakkında web'de pek çok bilgi vardır . Ancak , birden çok etki alanı ortamında tek bir oturum açma çözümü için JWT belirteçlerini kullanırken akışın ne olması gerektiğine dair net bir açıklama bulamadım .

Farklı ana bilgisayarlarda çok sayıda sitesi olan bir şirkette çalışıyorum. Example1.com ve example2.com'u kullanalım . Tek bir oturum açma çözümüne ihtiyacımız var, yani bir kullanıcı example1.com'da kimlik doğrulaması yaparsa , onun da example2.com'da otomatik olarak kimliğinin doğrulanmasını istiyoruz .

OpenId Connect akışını kullanarak, example1.com'da kimlik doğrulamak isteyen kullanıcının önce kimlik doğrulama sunucusuna (veya OP: "OpenId Provider") yönlendirileceğini anlıyorum . Kullanıcı bu sunucuda kimlik doğrulaması yapar ve ardından onu orijinal example1.com sitesine imzalı bir JWT belirteciyle yeniden yönlendirir . (Daha sonra gerçek JWT belirteci ile değiştirilebilecek bir ara belirteç döndüren başka bir akış olduğunu anlıyorum , ancak bunun bizim için gerekli olduğunu düşünmüyorum) ...

Şimdi kullanıcı example1.com'a geri döndü ve kimliği doğrulandı! JWT belirtecini bir Authenticationbaşlıkta ileterek istekte bulunabilir ve sunucu imzalı JWT'yi doğrulayabilir ve bu nedenle kullanıcıyı tanımlayabilir. Güzel!

İlk soru :

JWT belirteci istemcide nasıl saklanmalıdır? Yine, bununla ilgili pek çok bilgi var ve insanlar kullanmanın Web Storageeskiden çok gitmek için bir yol olduğu konusunda hemfikir görünüyorlar cookies. JWT'nin tarayıcı yeniden başlatmaları arasında kalıcı olmasını istiyoruz, bu yüzden kullanalım Local Storage, Session Storage...

Artık kullanıcı tarayıcısını yeniden başlatabilir ve JWT belirtecinin süresi dolmadığı sürece example1.com'da kimliği doğrulanmaya devam edecektir !

Ayrıca, example1.com'un başka bir etki alanımıza Ajax isteği yapması gerekiyorsa, CORS'u yapılandırmanın buna izin vereceğini anlıyorum . Ancak ana kullanım durumumuz, etki alanları arası istekler değil, tek bir oturum açma çözümüne sahip !

Bu nedenle, ana soru:

Şimdi, eğer kullanıcı example2.com'a giderse ve biz onun zaten sahip olduğu JWT jetonunu kullanarak kimliğinin doğrulanmasını istiyorsak akış ne olmalıdır ? Local Storageetki alanları arası erişime izin vermiyor gibi görünüyor, bu nedenle bu noktada tarayıcı example2.com'a istekte bulunmak için JWT belirtecini okuyamıyor !

Meli :

• Kullanıcı kimlik doğrulama sunucusuna yeniden yönlendirilsin mi? Kullanıcı ornek1.com için kimlik doğrulaması yaptığında , kimlik doğrulama sunucusu kullanıcıya bir tanımlama bilgisi ayarlamış olabilir, böylece example2.com için bu yeni kimlik doğrulama isteği , kullanıcının kimliğinin zaten doğrulanmış olduğunu görmek için bu tanımlama bilgisini kullanabilir ve onu hemen ornek2.com'a yönlendirebilir. aynı JWT belirteci ile?
• Veya example2.com'daki tarayıcı, kimlik doğrulama sunucusuna tekrar gitmek zorunda kalmadan JWT belirtecine erişebilir mi? Çapraz depolama çözümleri olduğunu görüyorum , ancak bunlar yaygın olarak kullanılıyor mu? Etki alanları arası SSO ortamı için önerilen çözüm bunlar mı?

Süslü bir şey istemiyoruz, en çok kullanılan çözümden memnun oluruz!

Kullanıcı, kimlik doğrulama sunucusuna yeniden yönlendirilmeli ve özellikle example2.com'u hedefleyen yeni bir belirteç (JWT) almalıdır. OpenID Connect ve diğer tüm etki alanları arası federe SSO protokolü bu şekilde çalışır.

Kullanıcı kimlik bilgilerini istemek ve yeni bir kimlik doğrulama belirteci vermek için oturum açmadığında kullanıcıyı merkezi kimlik doğrulama hizmetine yeniden yönlendirmek, oauth2 veya OpenId Connect gibi iyi bilinen protokolleri kullanan Tek Oturum Açma sistemlerinde yaygın bir senaryodur.

Bununla birlikte, bu şema etki alanları arasında kullanıldığında ana dezavantaj, kullanıcının aynı kökenli politika nedeniyle başka bir etki alanına her gittiğinde yeniden yönlendirilmesi ve kimliğinin doğrulanmasıdır : erişim belirteci etki alanları arasında paylaşılamaz ( example2.comverilere erişilemez) arasında example1.com), böylece hedef etki alanı kullanıcıyı kimliği doğrulanmamış olarak değerlendirecek ve kullanıcıyı merkezi SSO hizmetine yönlendirecektir.

Kimlik doğrulama hizmetinin kimlik bilgilerini yeniden istemesini önlemek için, bir oturum tanımlama bilgisine (erişim belirteci değil) sahip olmak yaygındır, ancak tarayıcı localStorage / tanımlama bilgileri ve bir ara etki alanına işaret eden bir iframe kullanarak etki alanları arasında veri paylaşmak için bir teknik vardır. sso.example.com

1. İçindeki kullanıcının kimliğini doğrulamak için example1.com, onu içindeki kimlik doğrulama sunucusuna yeniden yönlendirin, kimlik doğrulamasını sso.example.comyaptıktan sonra bir JWT yayınlayın ve bu etki alanının localStorage'ında saklayın. Bundan sonra, kullanıcıyı ornek1.com kaynak etki alanına yönlendirin.

2. example2.comİşaret ederek bir iframe oluşturun sso.example.com. Sso.example.com'daki iframe, JWT belirtecini okur ve üst sayfaya bir mesaj gönderir

3. Üst sayfa mesajı alır ve SSO akışına devam eden ekli jetonu alır

Aynı kaynak politikasıyla ilgili bir sorun yoktur çünkü sso.example.comlocalStorage'a erişimi vardır ve kaynak ve hedef etki alanları birbirini tanırsa iframe ile üst sayfa arasındaki iletişime izin verilir (bkz. Http://blog.teamtreehouse.com/cross-domain- mesaj ile mesajlaşma )

Geliştirmeyi basitleştirmek için, yakın zamanda https://github.com/Aralink/ssojwt adresinde JWT ile bir etki alanları arası SSO yayınladık.

Bu yöntem, SSO akışlarıyla mükemmel uyumludur. Bu, kimlik doğrulama belirtecini yeniden yönlendirmeler olmadan paylaşmanın ve etki alanları birleştirilmiş olduğunda gereksiz oturum açmaları önlemenin bir yoludur.

Bunun sorunuzu yanıtlayıp yanıtlamadığından emin değilim, ancak asıl amacınız tek oturum açma ise, basit bir ters proxy'nin sorununuzu çözeceğini düşünüyorum (en azından etki alanları arası depolama olanı).

Yani example1.com example2.com

gibi bir şey olur

example.com/example1

example.com/example2

(Ve kullanıcı tarafından bakıldığında, bu genellikle daha temizdir)

Bu bir seçenek değilse, bir kullanıcı 1 etki alanında kimlik doğrulaması yaptığında, AJAX / gizli iframe'leri kullanarak diğer etki alanlarıyla da kimlik doğrulaması oluşturacak şekilde ayarlamanız gerekebilir (gerekirse url aracılığıyla 1 zaman belirteci göndererek) ).

ve eğer BU bir seçenek değilse, tarayıcılar etki alanları arası etkileşim konusunda daha katı hale geldiğinden kullanıcı adı + pin'e başvurmanız gerekebilir.