OAuth 2.0 ile OpenID Connect Arasındaki Fark Nedir, Ne İçin Kullanılır?

OAuth 2.0 ile OpenID Connect aynı giriş ekranında birlikte kullanıldığı için sıkça aynı protokol sanılır. Oysa çözdükleri temel problem farklıdır. OAuth 2.0, bir istemci uygulamanın kullanıcıya veya kendisine ait korunan kaynaklara hangi yetkilerle erişebileceğini düzenleyen bir yetkilendirme çerçevesidir. OpenID Connect ise OAuth 2.0 akışının üzerine bir kimlik katmanı ekleyerek kullanıcının kimliğinin istemci tarafından doğrulanmasını standartlaştırır.

Pratik ayrım şudur: Bir uygulama “Bu kullanıcı adına takvim verisini okuyabilir miyim?” diye soruyorsa OAuth 2.0 yetkilendirmesi gerekir. “Bu kullanıcı kim ve gerçekten kimlik sağlayıcıda oturum açtı mı?” diye soruyorsa OpenID Connect gerekir. Aynı işlem hem giriş hem API erişimi içeriyorsa iki protokol aynı authorization code akışı içinde birlikte kullanılabilir; fakat access token ile ID token'ın görevleri birbirine karıştırılmamalıdır.

Authorization ve authentication arasındaki fark nedir?

Authentication, bir kullanıcının veya sistemin kimliğini doğrulama işlemidir. Authorization ise doğrulanmış veya tanımlanmış bir tarafın hangi kaynaklara, hangi eylemlerle erişebileceğini belirler. Bu iki kavram ilişkili olsa da aynı değildir. Bir kullanıcının kim olduğunu bilmek, bütün verilere erişmesine izin verildiği anlamına gelmez.

OAuth 2.0'ın temel RFC'si, üçüncü taraf uygulamaların bir HTTP hizmetine kaynak sahibinin adına veya kendi adına sınırlı erişim elde etmesini sağlayan bir yetkilendirme çerçevesi tanımlar IETF RFC 6749. Standart, authorization server'ın kullanıcıyı hangi yöntemle doğruladığını ayrıntılı biçimde tanımlamaz; asıl çıktı korunan kaynağa erişimde kullanılacak access token'dır.

OpenID Connect Core ise OAuth 2.0 üzerinde çalışan bir kimlik katmanı olduğunu açıkça belirtir. İstemci, authorization request içine openid scope'unu eklediğinde kullanıcının kimlik doğrulamasıyla ilgili sonucu ID token üzerinden alabilir OpenID Connect Core 1.0.

OAuth 2.0 kullanıcının kimliğini standart biçimde istemciye kanıtlamak için tasarlanmamıştır. “OAuth ile login” denilen güvenli ve birlikte çalışabilir giriş deneyimi, çoğu durumda OpenID Connect profilidir.

OAuth 2.0 hangi problemi çözer?

OAuth 2.0, kullanıcının parolasını üçüncü taraf uygulamayla paylaşmadan sınırlı API erişimi vermesini sağlar. Kullanıcı authorization server üzerinde oturum açar ve izin kararını verir. İstemci kısa ömürlü authorization code'u token endpoint'te access token ile değiştirir. Access token daha sonra resource server'a gönderilir.

OAuth 2.0 rollerinin görevi

RFC 6749'a göre access token, istemciye verilmiş belirli kapsam ve süreyi temsil eden bir yetkilendirme kimlik bilgisidir. Token opaque olabilir veya doğrulanabilir biçimde yetki bilgisi taşıyabilir. İstemcinin token içeriğini okuyabilmesi zorunlu değildir; access token'ın gerçek tüketicisi resource server'dır.

OAuth 2.0 kullanım örnekleri

• Bir raporlama uygulamasının kullanıcının reklam hesabındaki istatistikleri okuması
• Bir entegrasyon servisinin CRM içine yeni lead kaydı oluşturması
• Bir mobil uygulamanın kullanıcının bulut depolama dosyalarına sınırlı erişmesi
• Backend servisinin kendi adına başka bir servisin API'sini çağırması
• Bir otomasyon sisteminin yalnız belirli webhook veya sipariş işlemlerini yürütmesi

Bu akışların tasarlanması, yalnız login butonu eklemekten daha geniş bir API entegrasyon mimarisi gerektirir. Scope, audience, token süresi, refresh davranışı ve resource server doğrulaması birlikte planlanmalıdır.

OpenID Connect OAuth 2.0'a ne ekler?

OpenID Connect, OAuth 2.0'ın authorization endpoint ve token endpoint akışını kullanır; buna kimlik doğrulama semantiği, standart claim'ler, ID token, UserInfo endpoint'i ve provider metadata'sı ekler. Böylece istemci, kullanıcının authorization server tarafından doğrulandığını birlikte çalışabilir bir yöntemle kontrol edebilir.

• openid scope: İsteğin OpenID Connect authentication isteği olduğunu belirtir.
• ID token: Kullanıcının kimlik doğrulaması hakkında imzalı claim'ler taşır.
• Standard claims: sub, name, email ve benzeri profil alanları için ortak isimler tanımlar.
• UserInfo endpoint: Yetkili scope'lara göre ek kullanıcı bilgisi sunabilir.
• Discovery metadata: Endpoint, issuer, desteklenen akışlar ve imza algoritmalarını yayımlayabilir.
• nonce: Belirli authentication isteği ile ID token arasında bağ kurmaya yardımcı olur.

OpenID Connect Discovery standardı, provider'ın issuer, authorization endpoint, token endpoint, UserInfo endpoint ve anahtar bilgileri gibi metadata'yı standart bir belge üzerinden yayımlamasını sağlar OpenID Connect Discovery 1.0. Böylece endpoint'lerin kod içine gelişigüzel yazılması ve yanlış issuer yapılandırması riski azaltılabilir.

Access token ile ID token arasındaki fark nedir?

Access token ve ID token aynı token response içinde dönebilir; ancak farklı hedef kitlelere ve güvenlik kontrollerine sahiptir. En yaygın entegrasyon hatalarından biri, access token'ı kullanıcı login kanıtı olarak yorumlamak veya ID token'ı API çağrısında kullanmaktır.

ID token içinde hangi claim'ler önemlidir?

ID token genellikle imzalı JWT biçimindedir. İstemci token'ı yalnız base64 decode ederek kabul etmemeli; imzayı ve protokol claim'lerini doğrulamalıdır. OpenID Connect Core, ID token'ın authentication hakkında claim'ler içeren bir güvenlik token'ı olduğunu tanımlar.

Kullanıcı hesabını yalnız e-posta adresiyle eşleştirmek risklidir. E-posta değişebilir, doğrulanmamış olabilir veya farklı issuer'larda aynı adres bulunabilir. Yerel hesap ilişkisi için çoğunlukla issuer + subject birleşimi kararlı kimlik olarak kullanılmalıdır. E-posta, kullanıcıya gösterilen ve gerektiğinde ayrıca doğrulanan profil alanıdır.

Authorization code akışında OAuth ve OIDC birlikte nasıl çalışır?

Modern web, mobil ve browser tabanlı uygulamalarda genel yaklaşım authorization code akışı ve PKCE kullanmaktır. RFC 9700, public client'ların PKCE kullanmasını zorunlu tutar; confidential client'lar için de PKCE'yi önerir. Aynı belge implicit grant yerine access token'ın token endpoint'ten döndüğü authorization code yaklaşımının tercih edilmesini belirtir IETF RFC 9700.

1. İstemci authorization request oluşturur. response_type=code, client_id, redirect_uri, state, PKCE code_challenge ve OIDC için openid scope'u eklenir.
2. Kullanıcı authorization server'a yönlendirilir. Kimlik doğrulaması provider üzerinde gerçekleşir.
3. Kullanıcı izin verir. API scope'ları isteniyorsa provider onay ekranı gösterebilir.
4. Authorization server code döndürür. Code kısa ömürlüdür ve redirect URI ile client'a bağlıdır.
5. İstemci token endpoint'e gider. Code ve PKCE code_verifier ile token talep edilir.
6. Token response alınır. OIDC isteğinde ID token; API erişimi gerekiyorsa access token ve politikaya göre refresh token dönebilir.
7. İstemci ID token'ı doğrular. İmza, issuer, audience, expiration ve nonce kontrol edilir.
8. İstemci kendi session'ını oluşturur. Tarayıcı uygulamasında güvenli cookie ve session yaşam döngüsü ayrıca yönetilir.
9. API çağrısı access token ile yapılır. Resource server audience, scope, süre ve imza/introspection kontrolünü uygular.

Kullanıcının authorization server ekranında parola girmesi, OAuth 2.0'ın tek başına authentication protokolü olduğu anlamına gelmez. OAuth, provider'ın kullanıcıyı nasıl doğruladığını standartlaştırmaz; OIDC authentication sonucunu istemciye ID token ile taşır.

OAuth 2.0 tek başına login için neden yeterli değildir?

Saf OAuth 2.0 akışında istemci access token alabilir. Fakat access token'ın biçimi, içindeki kullanıcı bilgisi ve istemcinin onu kimlik kanıtı olarak nasıl doğrulayacağı OAuth 2.0 tarafından standartlaştırılmaz. Token tamamen opaque olabilir; subject client uygulamayı temsil edebilir; farklı resource server için üretilmiş olabilir.

Access token ile bir profil API'si çağırıp gelen cevaba göre login oluşturmak sağlayıcıya özel bir yaklaşım olabilir; ancak standart OpenID Connect güvenlik kontrollerini otomatik olarak sağlamaz. Token substitution, yanlış audience ve farklı issuer'dan token kabulü gibi riskler oluşabilir. Interoperable “Sign in with...” akışı için provider OpenID Connect destekliyorsa OIDC kullanılmalıdır.

Client Credentials akışı kullanıcı girişi midir?

Hayır. Client Credentials grant, bir uygulamanın kendi adına access token alması için kullanılır. Akışta son kullanıcı bulunmaz. Örneğin gece çalışan raporlama servisi, kendi kimliğiyle stok API'sini çağırabilir. Token içindeki subject veya client kimliği kullanıcı hesabı gibi yorumlanmamalıdır.

Scope, claim ve role arasındaki fark nedir?

• Scope: İstemcinin hangi API yetkisini istediğini veya OIDC'de hangi kimlik kapsamını talep ettiğini belirtir.
• Claim: Token veya UserInfo yanıtında bir subject ya da işlem hakkında taşınan veri alanıdır.
• Role: Uygulamanın kendi yetkilendirme modelindeki görev veya izin grubudur.
• Permission: Belirli kaynak üzerinde belirli eyleme izin veren uygulama kuralıdır.

openid, OIDC akışını başlatan özel scope'tur. profile ve email gibi scope'lar belirli standart claim gruplarını istemeye yarar. API tarafındaki orders:read gibi scope ise korunan kaynağa erişim yetkisini temsil edebilir. ID token içindeki claim'leri doğrudan bütün uygulama rollerine dönüştürmek yerine issuer güveni, tenant politikası ve yerel yetki modeli ayrıca değerlendirilmelidir.

OAuth ve OIDC entegrasyonunda sık yapılan hatalar

• Access token'ı kullanıcı login kanıtı olarak kabul etmek
• ID token'ı API çağrısında bearer token olarak göndermek
• JWT yalnız decode edilerek imzayı doğrulamamak
• Issuer ve audience kontrolünü atlamak
• E-posta adresini tek ve değişmez kullanıcı kimliği saymak
• Redirect URI için wildcard veya gevşek eşleşme kullanmak
• Authorization code akışında PKCE uygulamamak
• State ve nonce değerlerini sabit veya yeniden kullanılabilir üretmek
• Eski implicit ya da resource owner password akışını yeni projede seçmek
• Access token'ı yanlış API audience'ına göndermek
• Refresh token'ı tarayıcıda güvensiz depolamak
• Logout işlemini yalnız istemci session'ını silmek sanmak

RFC 9700, resource owner password credentials grant'in kullanılmaması gerektiğini ve bu yöntemin kullanıcı parolasını istemciye açarak saldırı yüzeyini büyüttüğünü belirtir. Yeni sistemlerde provider'ın kendi authentication ekranını kullanan authorization code + PKCE yaklaşımı tercih edilmelidir.

Hangi senaryoda OAuth, hangi senaryoda OIDC kullanılmalı?

Güvenli entegrasyon kontrol listesi

1. İhtiyacın authentication mı, API authorization mı yoksa ikisi birden mi olduğunu yazılı hale getirin.
2. Provider'ın issuer ve discovery metadata adresini doğrulayın.
3. Authorization code akışını ve PKCE S256 yöntemini kullanın.
4. Redirect URI'leri tam değerlerle önceden kaydedin.
5. OIDC isteğinde openid scope'u ve işlem bazlı nonce kullanın.
6. CSRF ve işlem bağlama için state/PKCE politikasını doğru uygulayın.
7. ID token imzasını provider'ın güncel anahtarlarıyla doğrulayın.
8. Issuer, audience, expiration ve nonce claim'lerini kontrol edin.
9. Yerel kullanıcıyı issuer + subject üzerinden eşleştirin.
10. Access token'ı yalnız hedef resource server'a gönderin.
11. API tarafında audience, scope ve izinleri her istekte doğrulayın.
12. Client secret'ı browser veya mobil paket içine gömmeyin.
13. Refresh token'ları kısa kapsam, rotasyon ve güvenli saklama politikasıyla yönetin.
14. Kimlik provider'ı erişilemediğinde session ve hata davranışını test edin.
15. Login, token yenileme, logout ve hesap bağlama olaylarını audit kaydına alın.

OAuth ve OIDC akışları, hazır kütüphaneler kullanılsa bile yanlış yapılandırılabilir. Redirect URI, issuer, token audience, session ve hesap eşleştirme kararları yazılım geliştirme sürecinde tehdit modeliyle birlikte ele alınmalıdır.

Sonuç: Token'ın ne olduğunu hedef tüketicisi belirler

OAuth 2.0, istemci uygulamanın korunan API'ye sınırlı erişim almasını düzenler. OpenID Connect ise bu çerçevenin üzerine standart authentication katmanı ekler. Access token resource server için yetkilendirme kimlik bilgisidir; ID token ise client uygulamanın kullanıcının authentication sonucunu doğrulaması içindir.

Doğru mimari, login için ID token doğrulamasını; API erişimi için audience ve scope kontrollü access token kullanımını ayırır. Kullanıcı ve servis akışları birbirine karıştırılmamalı, modern yönlendirmeli akışlarda authorization code + PKCE tercih edilmelidir. Çoklu uygulama ve servis yapılarında bu ayrım, özel yazılım mimarisinin güvenli ve sürdürülebilir kalması için temel bir karardır.