OpenID Connect (OIDC) Nedir?

OAuth'un yanıtlamadığı soru: “Bu kişi kim?”

OAuth 2.0, bir uygulamaya “şu API'de, şu izinlerle işlem yapabilirsin” diyen bir yetkilendirme çerçevesidir. Ortaya çıkan erişim token'ı API için üretilir; istemci uygulamaya kullanıcının kimliğini standart ve doğrulanabilir bir biçimde söylemez. Buna rağmen pek çok uygulama yıllarca “token aldıysam kullanıcı giriş yapmıştır” varsayımıyla OAuth'u giriş sistemi gibi kullandı. Bu yaklaşım, başka bir uygulama için alınmış bir token'ın sizin uygulamanıza sunulması gibi hatalara açıktır.

OpenID Connect bu boşluğu standart bir yanıtla kapatır. Rolleri de kendi adlarıyla anar: kimliği doğrulayan taraf OpenID Provider (OP), kimlik bilgisine güvenen uygulama Relying Party (RP)'dir.

Akış: openid kapsamı ve ID token

OIDC ayrı bir protokol kurmaz, OAuth akışlarına küçük eklemeler yapar. En yaygın kullanılan authorization code akışında istemci kullanıcıyı yönlendirirken scope değerine openid ekler; bu değer olmadan istek bir OIDC isteği sayılmaz. Gerekirse profile ve email gibi kapsamlar da istenir ve tekrar saldırılarına karşı bir nonce değeri gönderilir. Kullanıcı kimlik sağlayıcıda giriş yapıp onay verdikten sonra istemci kodu token endpoint'inde takas eder ve şu yapıda bir yanıt alır:

{
  "access_token": "SlAV32hkKG",
  "token_type": "Bearer",
  "expires_in": 3600,
  "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.eyJpc3Mi..."
}

ID token'ın içinde ne var?

ID token her zaman bir JWT'dir. Spesifikasyona göre iss (token'ı üreten kimlik sağlayıcı), sub (kullanıcının o sağlayıcıdaki kalıcı kimliği), aud (token'ın kime üretildiği; istemcinin client_id değerini içermek zorundadır), exp ve iat alanları zorunludur. Duruma göre auth_time (girişin ne zaman yapıldığı), nonce, acr ve amr (hangi doğrulama yöntemlerinin kullanıldığı, örneğin parola ile birlikte tek kullanımlık kod) da eklenir.

Pratik bir kural: kullanıcıyı kendi veritabanınızda iss ve sub ikilisiyle eşleştirin, e-posta adresiyle değil. E-posta değişebilir, hatta bir sağlayıcıda başka bir kişiye yeniden atanabilir; sub ise spesifikasyon gereği o sağlayıcı içinde hiçbir zaman başka birine verilmez.

ID token'ı doğrulamak

1. İmzayı, sağlayıcının yayınladığı açık anahtarlarla (JWKS) doğrulayın. Anahtarların ve endpoint'lerin adresleri /.well-known/openid-configuration keşif belgesinde bulunur.
2. iss değerinin beklenen sağlayıcıyla birebir eşleştiğini kontrol edin.
3. aud içinde kendi client_id'nizin bulunduğundan emin olun.
4. exp geçmişte kalmışsa token'ı reddedin.
5. İstekte nonce gönderdiyseniz, token'daki değerin sizin oturumunuzda sakladığınız değerle aynı olduğunu kontrol edin.

Doğrulama başarılıysa uygulama kendi oturumunu başlatır. Ad, profil fotoğrafı gibi ek bilgilere ihtiyaç varsa erişim token'ıyla UserInfo endpoint'i çağrılabilir. Ayrıntılar OpenID Connect Core 1.0 spesifikasyonundadır.

ID token ile access token aynı şey değildir

ID token'ı API çağrılarında taşıyıcı token gibi kullanmak sık yapılan bir hatadır; API'ler kendileri için üretilmiş erişim token'ını beklemelidir. Kurumsal tek oturum açma tarafında aynı ihtiyacı XML tabanlı SAML 2.0 da karşılar; yeni web ve mobil projelerinde ise OIDC daha yaygın tercihtir.