Projenize bir OIDC sunucusu entegre etmek için eksiksiz rehber

Kimlik erişim yönetimi (IAM) veya kimlik sağlayıcı (IdP) olarak da bilinen merkezi bir kimlik doğrulama ve yetkilendirme sistemine ihtiyacınız olan bir durumla karşılaşabilirsiniz. Bazen insanlar İş Müşterisi IAM ve İşgücü IAM gibi işleri belirtmek için bir kelime eklerler.

Bu süslü isimleri bir an için bir kenara atalım. IAM ihtiyacı, uygulamanız büyüdüğü için ortaya çıkabilir veya zorlu işleri baştan bir satıcıya devretmeyi planladığınız için ortaya çıkabilir. Her iki durumda da, projenize bir kimlik sistemi tanıtmanız gereken bir noktaya ulaşıyorsunuz.

OAuth 2.0'ın popülaritesini göz önünde bulundurduğumuzda, OIDC (OpenID Connect) birçok geliştirici için doğal bir tercihtir. OIDC, OAuth 2.0'ın üstüne inşa edilmiş bir kimlik doğrulama katmanı olduğu için, OIDC ile çalışmaya başladığınızda kendinizi tanıdık gelebilirsiniz. Hadi başlayalım!

OIDC sunucusu nedir ve neden OIDC sunucusunu entegre etmeliyim?#

Bir OIDC sunucusu veya kimlik sağlayıcısı, kullanıcı kimlik doğrulama ve yetkilendirmeyi yöneten merkezi bir sistemdir. Birden fazla uygulamalı bir iş için merkezi bir kimlik sistemine neden ihtiyacınız var başlığı altında tartıştığımız gibi, merkezi bir kimlik sisteminin birçok faydası vardır.

Diyelim ki projeniz basit bir web uygulaması ile başlıyor ve yerleşik kimlik doğrulaması var:

Projeniz büyüdükçe, mobil bir sürüm tanıtmanız gerekiyor:

Kullanıcılar için her uygulama için bir hesap oluşturmak kötü bir deneyim olurdu. Web uygulaması ile başladığınızdan beri, mobil uygulamanın kimlik doğrulama için web uygulamasıyla iletişim kurmasına izin verdiniz:

Şimdi, yeni bir API hizmeti tanıtılıyor. Ücretli kullanıcılar için olduğu için, kullanıcının hizmete erişmek için kimlik doğrulaması yaptığından ve yetkilendirildiğinden emin olmanız gerekiyor. Bunu başarmak için hizmeti web uygulaması aracılığıyla proxy yapabilirsiniz:

Ya da, kullanıcıyı kimlik doğrulaması yapmak için bir token tekniği kullanabilir ve hizmette web uygulamasıyla konuşarak tokeni doğrulayabilirsiniz. Böylece mobil uygulama hizmeti doğrudan kullanabilir:

İşler karışıyor. Dolayısıyla kimlik doğrulama ve yetkilendirme mantığını ayrı bir hizmete ayırmaya karar veriyorsunuz:

Yeniden yapılandırma süreci sancılı olabilir. Daha fazla uygulama ve hizmet ekledikçe karmaşıklığının üstel olarak artacağını fark edebilirsiniz. Daha da kötüsü, şifresiz oturum açma, sosyal oturum açma, SAML gibi birden fazla kimlik doğrulama yöntemini korumanız gerekebilir.

Bu nedenle, projenizi ölçeklendirme planınız olduğunda baştan itibaren bir kimlik sağlayıcısı tanıtmamız daha iyi olur.

OIDC sunucusunu entegre etmek için en iyi uygulamalar#

Bir OIDC sağlayıcısı bulun#

Piyasada birçok OIDC sağlayıcısı vardır. Gereksinimlerinize ve tercihlerinize göre birini seçebilirsiniz. Sağlayıcı OIDC'ye uygun olduğu sürece projenizde aynı rolü oynayacaktır.

OIDC'de "subject", "client" ve "audience" ne anlama gelir?#

Kavramı basitleştirmek için, subject 'in bir client aracılığıyla bir audience 'a erişim talep eden varlık olduğunu düşünebiliriz.

Bazı tipik senaryolara bir göz atalım:

1. Bir kullanıcı web uygulamasında oturum açma düğmesine tıklar#

Geleneksel ve sunucu tarafı işleme yapan bir web uygulamasında, ön yüz ve arka uç birleştirilmiştir. Diyelim ki web uygulaması hem ön yüz hem arka yüz sunar:

• Subject: Kullanıcı
• Audience: OIDC sunucusu
• Client: Web uygulaması

Audience'ın OIDC sunucusu olması sezgisel olarak ters görünebilir. Aslında, bu son kullanıcılar için SSO (Tek Oturum Açma) deneyimini gerçekleştirmek için anahtardır. Yetkilendirme kodu akışının nasıl çalıştığı için basitleştirilmiş bir sekans diagramına bakalım:

code, erişim tokenı, kimlik tokenı ve yenileme tokenı gibi çeşitli tokenlar için değiştirilebilen tek seferlik bir koddur. Bu tokenların tümünü şu anda anlamasanız da sorun değil. İlerledikçe onları daha iyi anlayacaksınız.

Yukarıdaki durumda, kullanıcı (subject) OIDC sunucusuyla (audience) kimlik doğrulaması yaptığından, başka bir uygulamaya geçtiklerinde tekrar oturum açmaları gerekmez.

2. Kullanıcı bir tek sayfa uygulaması kullanır#

Tek bir sayfa uygulamasında (veya mobil uygulamada), ön yüz ve arka uç ayrıdır. Diyelim ki arka uç bir API hizmetidir:

• Subject: Kullanıcı
• Audience: API hizmeti
• Client: Tek sayfa uygulaması (SPA)

Yetkilendirme kodu akışı ile basitleştirilmiş bir sekans diyagramı:

API hizmeti etkileşimsiz olduğundan, SPA'nın API hizmetini audience (token içindeki aud) olarak kullanması gerekir.

Neden OIDC sunucusu hala bir audience?

Teknik olarak, OIDC sunucusunu audience listesinden çıkarabilirsiniz. Çoğu durumda, OIDC sunucusundan kullanıcı bilgisine ihtiyacınız olacağını düşündüğümüzde (bu OIDC sunucusunun bir audience olmasını gerektirir), kullanıcı etkileşimi içerdiğinde OIDC sunucusunu audience listesine dahil etmek daha iyidir.

Bekle, yetkilendirme isteğinde birden fazla audience'a sahip olabilir miyiz diyorsunuz?

Kesinlikle! OIDC, OAuth 2.0 üzerine inşa edildiği için, yetkilendirme isteğinde birden fazla audience'ı belirtmek için RFC 8707: Resource Indicators for OAuth 2.0'ten yararlanmak mümkündür. Bu, hem hibe hem de OIDC sunucusunun desteğini gerektirir. Logto, bu özelliği yerel olarak destekler.

3. Makineden makineye iletişim#

Diyelim ki A hizmetiniz var ve bunun B hizmetini araması gerekiyor:

• Subject: Hizmet A
• Audience: Hizmet B
• Client: Hizmet A

Müşteri kimlik bilgileri hibe ile basitleştirilmiş bir sekans diyagramı:

B hizmetinin A hizmetini araması gerektiğinde, roller basitçe değiştirilir.

Özet#

• Subject: Bir kullanıcı, bir hizmet veya audience'a erişim sağlaması gereken herhangi bir varlık olabilir.
• Client: Bir web uygulaması, bir mobil uygulama veya talebi başlatan veya subject adına hareket eden herhangi bir varlık olabilir.
• Audience: Bir hizmet, bir API veya subject'a erişim sağlayan herhangi bir varlık olabilir.

Erişim tokenları, kimlik tokenları ve yenileme tokenları nedir?#

OIDC ile çalışırken karşılaşabileceğiniz üç tür token vardır:

• Erişim tokenı: Audience'a erişmek için kullanılır. Bir JWT (JSON Web Token) veya opak bir token olabilir (genellikle rastgele bir dizi).
• Kimlik tokenı: OIDC'ye özgü bir token olup kullanıcı bilgilerinin bulunduğu bir JSON Web Token'dir. İstemci tokenı çözebilir ve kullanıcı bilgilerini elde edebilir.
• Yenileme tokenı: Erişim tokenı veya kimlik tokenı sona erdiğinde yeni bir token seti almak için kullanılır.

Bu tokenlar hakkında ayrıntılı bir açıklama için, OIDC protokolünde yenileme tokenları, erişim tokenları ve kimlik tokenlarını anlamak'ye başvurabilirsiniz.

Yukarıdaki senaryo 1 ve 2'de, yetkilendirme isteği terimi, belirli bir hibe yoluyla bir dizi token elde etme isteğini ifade eder.

Her şey yolunda gittiğinde, "code kullanarak token değişimi" adımında bir dizi token geri döndürülecektir. Dizedeki mevcut tokenlar, özellikle yetkilendirme isteğindeki scope parametresi gibi birçok faktöre bağlıdır. Basitlik açısından, tüm tokenların dizide geri döneceğini varsayıyoruz. Erişim tokenı sona erdiğinde, istemci, kullanıcı etkileşimi olmadan yeni bir token seti almak için yenileme tokenını kullanabilir.

Senaryo 3 için, istemci kimlik bilgileri hibe sadece bir erişim tokenı döndürdüğü için daha basittir.

OIDC'de birden fazla audience nasıl ele alınır?#

Yalnızca bir erişim tokenı bir seferde döndürüldüğünü fark edebilirsiniz. İstemcinin birden fazla audience'a erişmesi gerektiği durumu nasıl ele alabiliriz?

İki yaygın çözüm vardır:

Kod değiştirme isteğinde "resource" belirtin#

İstemci, kodu tokenlarla değiştirirken istekte "resource" parametresini belirtebilir. OIDC sunucusu, geçerliyse belirtilen audience için bir erişim tokenı döndürecektir.

İşte normatif olmayan bir örnek:

Bu durumda, OIDC sunucusu API_SERVICE audience için bir erişim tokenı döndürecektir, eğer geçerliyse.

Bir yenileme tokenı kullanarak yeni bir erişim tokenı almak#

RFC 8707 ile birlikte, istemci aynı anda birden fazla audience'ı resource parametresini birden fazla kez kullanarak belirtebilir. Şimdi, istemcide yenileme tokenları mevcutsa, yenileme yaparken audience'ı resource parametresinde belirtebilir.

İşte normatif olmayan bir örnek:

Bu, önceki çözümle aynı etkiye sahiptir. Bu arada, diğer tanınmış audience'lar gelecekteki token isteklerinde hala kullanılabilir.

İstemci kimlik bilgileri hibe#

İstemci kimlik bilgileri hibesinde audience belirtmek için resource parametresini de kullanabilirsiniz. Bu hibe için bir sorun yoktur çünkü farklı bir audience için her zaman yeni bir erişim tokenı almak için başka bir token isteği gönderebilirsiniz.

API hizmetinizi koruyun#

Senaryo 2'deki "API hizmeti" ve senaryo 3'teki "Hizmet B"'nin ortak bir noktası vardır: İsteğin yetkilendirilmiş olup olmadığını belirlemek için erişim tokenını doğrulamaları gerekir. Erişim tokenının formatına bağlı olarak doğrulama süreci değişebilir.

• Opak token: API hizmeti, tokenı doğrulamak için OIDC sunucusunu aramalıdır. OIDC sunucusu genellikle bu amaçla bir inzersanasyon noktası sağlar.
• JWT: API hizmeti, tokenın imzasını ve token içindeki iddiaları kontrol ederek imzasını doğrulayabilir. OIDC sunucusu genellikle API hizmetinin imzayı doğrulamak için genel anahtar elde etmesi için bir JSON Web Anahtarı Seti (JWKS) uç noktası (jwks_uri) sağlar.

JWT'ye yeniyseniz, JSON Web Token (JWT) nedir? konusuna başvurabilirsiniz. Aslında, genellikle imzayı doğrulamak ve iddiaları manuel olarak değerlendirmek zorunda değilsiniz çünkü bunu sizin için yapacak birçok kütüphane mevcuttur, örneğin Node.js ve web tarayıcıları için jose.

İddiaları değerlendirin#

JWT imzasını doğrulamanın yanı sıra, API hizmeti token içindeki iddiaları her zaman kontrol etmelidir:

• iss: Tokenın düzenleyicisi. OIDC sunucusunun düzenleyici URL'siyle eşleşmelidir.
• aud: Tokenın audience'ı. API hizmetinin audience değeriyle (genellikle geçerli bir URI) eşleşmelidir.
• exp: Tokenın sona erme zamanı. API hizmeti tokenı bitmişse reddetmelidir.
• scope: Tokenın kapsamları (izinler). API hizmeti, gerekli kapsamın tokenda mevcut olup olmadığını kontrol etmelidir.

Diğer iddialar, örneğin sub (subject) ve iat (verilme saati), bazı durumlarda da önemlidir. Ek güvenlik önlemleriniz varsa, iddiaları uygun şekilde değerlendirin.

Yetkilendirme#

Henüz yanıtlanmamış bir soru var: Bir scope'un (yani izin) bir subject'a verilip verilemeyeceğini nasıl belirleriz?

Bu tek soru, bu makalenin kapsamı dışındaki tüm bir yetkilendirme dünyasına kapı açar. Kısacası, RBAC (Rollere Dayalı Erişim Kontrolü) ve ABAC (Özniteliklere Dayalı Erişim Kontrolü) gibi bazı yaygın yaklaşımlar bulunmaktadır. Başlamak için bazı kaynaklar şunlardır:

• RBAC ve ABAC: Bilmeniz Gereken Erişim Kontrol Modelleri
• Logto'da RBAC'i Mastery Etme: Kapsamlı Bir Gerçek Dünya Örneği

Kapanış notları#

Projenize bir OIDC sunucusu tanıtmak büyük bir adımdır. Projenizin güvenliğini ve ölçeklenebilirliğini önemli ölçüde artırabilir. Bununla birlikte, kavramları ve bileşenler arasındaki etkileşimleri anlamak biraz zaman alabilir.

Gereksinimlerinizi ve tercihlerinizi karşılayan iyi bir OIDC sağlayıcısı seçmek, entegrasyon sürecinin karmaşıklığını önemli ölçüde azaltabilir, çünkü sağlayıcı genellikle gelecekte ihtiyaç duyabileceğiniz OIDC sunucusu, yetkilendirme mekanizmaları, SDK'lar ve kurumsal özellikler dahil bütün bir paketi sunar.

Bu rehberin size bir OIDC sunucusi entegre etmenin temellerini anlamada yardımcı olmasını umuyorum. Başlamak için birini arıyorsanız, bencil bir öneriyle Logto, geliştiriciler için kimlik altyapımızı öneririm.