Türkçe

oidc
oauth
authentikasyon
yetkilendirme
jwt

Projenize bir OIDC sunucusu entegre etmek için eksiksiz rehber

Projenize bir OIDC (OpenID Connect) sunucusu entegre etmenin en iyi uygulamalarını öğrenin ve bileşenlerin sahnede nasıl birbirleriyle etkileşimde bulunduğunu anlayın.

Gao

Founder

9/29/2024

Kullanıcı kimlik doğrulamasına haftalar harcamayı bırakın

Logto ile güvenli uygulamaları daha hızlı yayınlayın. Kullanıcı kimlik doğrulamasını dakikalar içinde entegre edin ve temel ürününüze odaklanın.

Başlayın

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:

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.

Logto Cloud'u ücretsiz deneyin

OIDC sunucusu nedir ve neden OIDC sunucusunu entegre etmeliyim?#

OIDC sunucusunu entegre etmek için en iyi uygulamalar#

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

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

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

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

3. Makineden makineye iletişim#

Özet#

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

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

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

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

İstemci kimlik bilgileri hibe#

API hizmetinizi koruyun#

İddiaları değerlendirin#

Yetkilendirme#

Kapanış notları#

OIDC sunucusu nedir ve neden OIDC sunucusunu entegre etmeliyim?#

OIDC sunucusunu entegre etmek için en iyi uygulamalar#

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

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

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

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

3. Makineden makineye iletişim#

Özet#

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

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

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

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

İstemci kimlik bilgileri hibe#

API hizmetinizi koruyun#

İddiaları değerlendirin#

Yetkilendirme#

Kapanış notları#

OIDC sunucusu nedir ve neden OIDC sunucusunu entegre etmeliyim?

OIDC sunucusunu entegre etmek için en iyi uygulamalar

Bir OIDC sağlayıcısı bulun

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

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

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

3. Makineden makineye iletişim

Özet

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

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

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

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

İstemci kimlik bilgileri hibe

API hizmetinizi koruyun

İddiaları değerlendirin

Yetkilendirme

Kapanış notları

OIDC sunucusu nedir ve neden OIDC sunucusunu entegre etmeliyim?

OIDC sunucusunu entegre etmek için en iyi uygulamalar

Bir OIDC sağlayıcısı bulun

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

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

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

3. Makineden makineye iletişim

Özet

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

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

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

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

İstemci kimlik bilgileri hibe

API hizmetinizi koruyun

İddiaları değerlendirin

Yetkilendirme

Kapanış notları