Türkçe
  • openid connect
  • oidc
  • oidc yapılandırması
  • openid-yapılandırması
  • oauth

OpenID Connect yapılandırmasını keşfetmek: Anahtar alanlar ve kullanımları

OpenID Connect yapılandırmasının anahtar alanlarını ve pratik uygulamalarını inceliyor.

Yijun
Yijun
Developer

Günümüz dijital dünyasında, kimlik doğrulama web siteleri ve uygulamaları güvence altına almanın merkezi bir bileşeni haline geldi. OAuth 2.0 protokolü üzerine inşa edilmiş bir kimlik doğrulama katmanı olan OpenID Connect (OIDC), kimlikleri doğrulamak için standartlaştırılmış ve basit bir yol sunar.

Ancak, OIDC'yi doğru şekilde entegre etmek özellikle yeni başlayanlar için göz korkutucu olabilir. Genellikle iyi bir başlangıç noktası, OIDC hizmetlerini uygulamak için gerekli tüm ayrıntıları içeren {authServerUrl}/.well-known/openid-configuration URL'sinde bulunan OIDC yapılandırma dosyasıdır.

Bu kılavuz, bu yapılandırmadaki anahtar alanları netleştirmeyi amaçlamakta, geliştiricilere OIDC'yi projelerine daha iyi entegre edebilmeleri için önemini ve pratik uygulamalarını anlamalarına yardımcı olmaktadır.

OIDC yapılandırma alanlarını analiz etmek

OIDC yapılandırması, aşağıdakine benzer bir JSON dosyasıdır:

Şimdi, bazı anahtar alanları daha ayrıntılı olarak inceleyelim.

authorization_endpoint

OIDC hizmetlerini entegre ederken, ilk adım genellikle kullanıcı giriş isteklerini uygulama içinde ele almaktır. Bu süreç, kullanıcıları kimlik doğrulama için giriş sayfasına yönlendiren yetkilendirme sunucusunun authorization_endpoint adresine yönlendirmeyi içerir. Bu uç nokta, yetkilendirme isteklerinin gönderildiği sunucu adresidir.

authorization_endpoint isteği yapılırken, her yetkilendirme için ek sorgu parametreleriyle yapılandırılmalıdır:

  • response_type: Döndürülen yetkilendirme türünü belirtir. Bu genellikle "code" (yetkilendirme kodu akışı için), "token" (örtük akış için) ve "id_token token" veya "code id_token" (karma akış için) gibi türleri içerir ve OIDC yapılandırmasının response_types_supported alanında bulunabilir.
  • client_id: Uygulamanın kayıt sırasında yetkilendirme sunucusu tarafından atanan benzersiz tanımlayıcısıdır. Bu kimlik, yetkilendirme sunucusunun isteği başlatan istemci uygulamayı tanıması için kullanılır.
  • scope: İstenen erişim kapsamını tanımlar, erişilebilir kaynakları veya kullanıcı bilgilerini belirler. Yaygın kapsamlar arasında "openid" (zorunlu), "profile" ve "email" gibi diğerleri yer alır. Desteklenen kapsamları OIDC yapılandırmasının scopes_supported alanında bulabilirsiniz; farklı kapsamlar boşluklarla ayrılmalıdır.
  • redirect_uri: Giriş veya yetkilendirme sonrası, yetkilendirme sunucusu kullanıcıyı uygulama tarafından sağlanan URI'ye geri yönlendirir. Bu URI, uygulamanın kaydı sırasında sağlanan URI ile tam olarak eşleşmelidir.
  • state: İstemciyi çapraz site istek sahtekarlığı (CSRF) saldırılarına karşı korumak için kullanılan rastgele bir dizedir. Güvenliği sağlamak için yetkilendirme isteği ile geri arama arasındaki durumun tutarlılığı korunmalıdır.

Bu parametreler, geliştiricilere OIDC yetkilendirme isteklerinin davranışını tam olarak kontrol etme, güvenlik sağlama ve uygulamanın ihtiyaçlarını karşılama imkanı verir.

authorization_endpoint isteği tamamlandıktan ve kimlik doğrulaması geçtikten sonra, kullanıcılar uygulama tarafından sağlanan redirect_uri'ye yönlendirilir; bu URI çok önemli bir sorgu parametresi olan code içerir. Bu yetkilendirme kodu, yetkilendirme sunucusu tarafından sağlanır ve kullanıcının yetkilendirme sunucusunda bilgilerine erişim yetkisi verdiği anlamına gelir.

token_endpoint

token_endpoint, yetkilendirme sunucusunun yukarıda bahsedilen yetkilendirme kodunu erişim ve yenileme jetonlarına dönüştürmek için kullandığı sunucu uç noktasıdır. OAuth 2.0 yetkilendirme kodu akışında, bu adım kritik öneme sahiptir, çünkü elde edilen yetkilendirme kodunun gerçek erişim jetonlarına dönüştürülmesini içerir, bu jetonlar uygulamanın kullanıcının korunan kaynaklarına erişmesini sağlar.

Yetkilendirme kodunu erişim jetonlarına değiştirme sürecinin nasıl uygulanacağına dair bir örnek şudur (bu örnek client_secret_post kimlik doğrulama yöntemini kullanıyor. Diğer desteklenen kimlik doğrulama yöntemleri için daha sonra

token_endpoint_auth_methods_supported
alanının analizine bakınız):

Bu kodda, önce POST yöntemi kullanarak token_endpoint adresine bir istek gönderiyoruz. İçerik türü, yetkilendirme sunucularının çoğu tarafından gereksinim duyulan application/x-www-form-urlencoded olarak ayarlanır. İstek gövdesi aşağıdaki parametreleri içerir:

  • code: Kullanıcı yetkilendirme sonrasında, giriş yapar yapmaz yetkilendirme sunucusundan elde edilen yetkilendirme kodu, redirectUri üzerinden döndürülür.
  • redirect_uri: Yetkilendirme kodunu almak için kullanılan aynı yönlendirme URI'si, isteğin geçerliliğini doğrulamak için kullanılır.
  • client_id: Uygulamanın istemci tanımlayıcısı, istek yapan uygulamayı belirlemek için kullanılır.
  • client_secret: Uygulamanın istemci gizliliği, uygulamanın kimliğini doğrulamak için kullanılır.
  • grant_type: Yetkilendirmenin türünü belirtir, burada "authorization_code" kullanıyoruz, bu da yetkilendirme koduyla erişim jetonu alındığını gösterir.

Bu fonksiyon, asenkron şekilde çalışır ve uygulamanın kullanıcı verilerine erişmek veya başka işlemler yapmak için kullanabileceği erişim jetonunu içeren bir JSON nesnesi döner.

userinfo_endpoint

userinfo_endpoint, yetkilendirme sunucusu tarafından kimliği doğrulanmış kullanıcılar hakkında ayrıntılı bilgi sağlamak için kullanılan sunucu uç noktasıdır. Kullanıcılar token_endpoint aracılığıyla başarılı bir şekilde yetkilendirildikten ve erişim jetonu aldıktan sonra, uygulama bu uç noktayı kullanıcının profil bilgilerine, örneğin kullanıcı adı ve e-posta adresine erişmek için istekte bulunabilir. Elde edilen spesifik bilgiler, doğrulama isteğindeki scope ile belirtilir.

Bu fonksiyonda, önce GET yöntemini kullanarak userinfo_endpoint isteği yaparız, istek başlığına token_type ve accessToken'dan oluşan Authorization alanı eklenir. Bu, OAuth 2.0 spesifikasyonuna göre standart bir işlemdir, kullanıcı bilgilerini güvenli bir şekilde almayı sağlar. Ek olarak, erişim tokenı aracılığıyla erişilen kullanıcı bilgileri tamamen devreye giren yetkilendirme isteği başlatılırken belirtilen scope parametresine bağlıdır. Örneğin, email kapsamı kullanılırsa, yanıt kullanıcının e-posta adresini içermelidir.

issuer & jwks_uri

İssuer yetkilendirme sunucusunun URL'sini tanımlar, jwks_uri ise JSON Web Key Set'i (JWKS) tanımlayan URI'yi sağlar, bu JWKS JWT imzalarını doğrulamak için kullanılan bir dizi genel anahtardan oluşur. JWT'nin issuer ve imzasını doğrulamak, jeton güvenliğini sağlamak için temel adımlardır, ancak gerçek senaryolarda, doğrulama süreci genellikle jetonun geçerlilik süresi, hedef kitle, yetkilendirme kapsamı ve diğer önemli alanların kontrolünü de içerir.

Aşağıdaki kod, JWT'yi doğrulamak için issuer ve jwks_uri'yi birlikte nasıl kullanılacağını gösterir:

scopes_supported & claims_supported

claims_supported ve scopes_supported alanları, yetkilendirme sunucusu tarafından desteklenen kullanıcı özelliklerini (talep) ve erişim kapsamlarını (scope) belirtir. Bu, istemcilerin yetkilendirme isteklerini etkili bir şekilde oluşturup yanıtları ayrıştırmasına olanak sağlar.

Bir yetkilendirme isteği oluştururken, istemciler uygulamanın ihtiyaçlarına göre gerekli scope'u belirtebilir. Scope, istemcinin erişmek istediği kaynakları ve işlemleri tanımlar, örneğin openid, email, profile ve diğerleri.

Yetkilendirme sırasında erişilebilen spesifik taleplerin, yetkilendirme isteği başlatılırken belirtilen scope değerlerine göre değiştiğini unutmamak önemlidir. Örneğin, e-posta kapsamı, kullanıcının e-posta adresine erişim sağlar, telefon kapsamı ise telefon numarasına erişim izni verir. Bu nedenle, istemciler yetkilendirme isteği hazırlarken uygulamanın ihtiyaçlarına uygun ilgili scope'u dikkatlice seçmelidir, böylece gerekli kullanıcı bilgilerini elde edebilirler:

token_endpoint_auth_methods_supported

token_endpoint_auth_methods_supported
alanı, token uç noktası tarafından desteklenen kimlik doğrulama yöntemlerini belirtir. Bu yöntemler, istemcinin yetkilendirme kodunu erişim jetonlarına dönüştürmek için yetkilendirme sunucusuyla kimlik doğrularken kullanılır.

Token uç noktası ile kimlik doğrulama sırasında yaygın kullanılan kimlik doğrulama yöntemleri arasında client_secret_post, client_secret_basic ve client_secret_jwt bulunur.

  • client_secret_post: İstemci, müşteri tanımlayıcısını ve müşteri sırrını form-kodlu bir gövde halinde oluşturur ve bu, istek gövdesinin bir parçası olarak gönderilir. Bu yöntemin bir örneğini yukarıdaki token_endpoint bölümünde görmüştük.

  • client_secret_basic: İstemci, müşteri tanımlayıcısını ve müşteri sırrını kullanarak temel bir kimlik doğrulama başlığı oluşturur, bu başlık istek başlığına eklenir.

  • client_secret_jwt: İstemci, kimlik doğrulama için bir JWT (JSON Web Token) kullanır. Bu JWT, istemci tanımlayıcısını ve bazı ek meta verileri içerir ve müşteri sırrı kullanılarak imzalanır. İsteği aldıktan sonra, yetkilendirme sunucusu kimlik doğrulaması için JWT'nin imzasını doğrular.

Pratik uygulamalarda, istemciler yetkilendirme sunucusu tarafından desteklenen yöntemleri baz alarak uygun kimlik doğrulama yöntemini seçmeli ve kimlik doğrulama bilgilerinin isteğe doğru şekilde eklendiğinden emin olmalı, böylece yetkilendirme kodunu güvenli bir şekilde erişim jetonlarıyla değiş tokus yapmalıdır.

Özet

Artık OIDC yapılandırmasındaki anahtar alanları keşfettik ve amaçları ve uygulamaları üzerinde durduk. Bu ayrıntıları anlamak, OpenID Connect'in kavranmasını artırır ve onu projelerinizde daha etkin bir şekilde entegre ve kullanmanıza olanak tanır. Bu bilgiyle donanmış olarak, OIDC'nin tam potansiyelini daha güvenli ve verimli kullanıcı kimlik doğrulama çözümleri için kullanmaya hazırsınız.

OIDC üzerine inşa edilmiş bir kimlik doğrulama servisi olarak Logto, çeşitli dillerde kapsamlı bir SDK seti sunar ve birçok entegrasyon eğitimi ile uygulamalarınıza OAuth / OIDC girişlerini sadece birkaç dakika içinde sorunsuz bir şekilde entegre etmenizi sağlar. Güvenilir ve kullanımı kolay bir OIDC servisi arıyorsanız, Logto'yu bugün deneyin!