Google ile Giriş Nasıl Eklenir? OAuth ve SSO Rehberi

Google ile giriş, web sitesine ya da uygulamaya OAuth 2.0 ve onun kimlik katmanı olan OpenID Connect (OIDC) ile eklenir. Kısa cevap: kullanıcı Google’a yönlendirilir, Google kimliği doğrular ve sitenize imzalı bir ID token gönderir; siteniz bu tokenın imzasını ve alıcısını sunucuda doğrular, kullanıcıyı kendi kayıtlarıyla eşleştirir ve kendi oturumunu açar. Siteniz hiçbir zaman Google parolasını görmez ve saklamaz. Teknik kurulum kısa sürer; projeyi uzatan kısım hesap eşleştirme, oturum yönetimi ve kurumsal müşterilerde tek oturum açma (SSO) gereksinimleridir. Bu yazı kurumsal web projelerinde uyguladığımız akışı anlatır; web geliştirme hizmetimizin kimlik doğrulama tarafıdır.

OAuth, OpenID Connect ve SSO: hangisi ne?

Bu üç terim günlük dilde birbirinin yerine kullanılır, ama üç ayrı soruyu cevaplar. OAuth 2.0 bir yetki devri protokolüdür: “Bu uygulama benim adıma takvimimi okuyabilir” der, kim olduğunuzu söylemez. OpenID Connect, OAuth’un üstüne eklenen kimlik katmanıdır: imzalı bir ID token ile “bu kullanıcı şu kimliktir, e-postası doğrulanmıştır” bilgisini taşır. Google ile giriş, pratikte OpenID Connect’tir. SSO (single sign-on) ise bir mimari hedeftir: kullanıcı bir kez oturum açar ve birden çok uygulamaya ayrı parola girmeden erişir. İki farklı ihtiyaç vardır:

• Sosyal giriş (B2C): müşterilerinizin Google, Apple ya da Microsoft hesabıyla kayıt olup giriş yapması. Hedef sürtünmeyi azaltmak ve parola yönetimini üstlenmemektir.
• Kurumsal SSO (B2B / iç uygulama): çalışanların şirketin kimlik sağlayıcısıyla (Google Workspace, Microsoft Entra ID, Keycloak) giriş yapması. Hedef merkezi erişim yönetimidir: işten ayrılan kişinin erişimi tek yerden kesilir.

İkisi aynı protokolü kullanır ama ürün kararları farklıdır. Sosyal girişte kullanıcı sağlayıcıyı kendisi seçer; kurumsal SSO’da sağlayıcıyı müşteri şirket belirler ve çoğu zaman SAML ya da OIDC ile kendi kiracısını bağlamak ister.

Google ile giriş akışı adım adım

Önerilen akış “authorization code + PKCE” akışıdır. Tarayıcıda token üreten eski “implicit” akış artık önerilmez; token her zaman sunucuda alınır ve tarayıcıya yalnızca sizin oturum çerezinizi verirsiniz.

• Google Cloud Console’da bir OAuth istemcisi oluşturulur; izin verilen yönlendirme adresleri (redirect URI) tam eşleşmeyle tanımlanır, joker karakter yoktur.
• Kullanıcı “Google ile giriş” butonuna basınca sunucu rastgele bir state ve PKCE code_verifier üretir, bunları kısa ömürlü bir çerezde saklar ve kullanıcıyı Google’ın yetkilendirme adresine yönlendirir.
• Google kimliği doğrular, kullanıcı hangi bilgileri paylaştığını görür ve onaylar; tarayıcı sizin callback adresinize bir code ile döner.
• Sunucu state’i çerezle karşılaştırır, code’u Google’ın token ucunda ID token ile takas eder (client_secret ve code_verifier ile).
• ID token’ın imzası Google’ın yayımladığı anahtarlarla, iss ve aud alanları ve süresi doğrulanır; e-postanın doğrulanmış olduğu kontrol edilir.
• Kullanıcı veritabanında bulunur ya da oluşturulur, sizin oturum çerezinizle giriş tamamlanır. Google’dan gelen token tarayıcıya gönderilmez.

Örnek: Next.js route handler ile callback

// app/api/auth/google/callback/route.ts
import { createRemoteJWKSet, jwtVerify } from 'jose';

const GOOGLE_JWKS = createRemoteJWKSet(
  new URL('https://www.googleapis.com/oauth2/v3/certs'),
);

export async function GET(req: Request) {
  const url = new URL(req.url);
  const code = url.searchParams.get('code');
  const state = url.searchParams.get('state');

  // state, giriş başlatılırken çereze yazılmıştı: CSRF kontrolü
  if (!code || !state || state !== await readStateCookie()) {
    return new Response('Geçersiz istek', { status: 400 });
  }

  // code -> token takası her zaman sunucuda yapılır
  const tokenRes = await fetch('https://oauth2.googleapis.com/token', {
    method: 'POST',
    headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
    body: new URLSearchParams({
      code,
      grant_type: 'authorization_code',
      client_id: process.env.GOOGLE_CLIENT_ID!,
      client_secret: process.env.GOOGLE_CLIENT_SECRET!,
      redirect_uri: process.env.GOOGLE_REDIRECT_URI!,
      code_verifier: await readVerifierCookie(),
    }),
  });
  const { id_token } = (await tokenRes.json()) as { id_token: string };

  // imza, yayıncı, alıcı ve süre doğrulaması
  const { payload } = await jwtVerify(id_token, GOOGLE_JWKS, {
    issuer: ['https://accounts.google.com', 'accounts.google.com'],
    audience: process.env.GOOGLE_CLIENT_ID,
  });
  if (payload.email_verified !== true) {
    return new Response('E-posta doğrulanmamış', { status: 403 });
  }

  // kimlik e-posta değil, Google'ın kalıcı "sub" değeridir
  const user = await findOrLinkUser({
    provider: 'google',
    subject: payload.sub!,
    email: String(payload.email),
  });

  return createSessionAndRedirect(user.id, '/panel');
}

Hesap eşleştirme: projelerin takıldığı yer

Google ile giriş eklenen sitelerin çoğunda zaten e-posta ve parolayla kayıtlı kullanıcılar vardır. Aynı kişi Google ile girince ne olacağı baştan karara bağlanmazsa ya iki ayrı hesap oluşur ya da yanlış hesap birleştirilir. Üç kural bu sorunu çözer. Birincisi, kullanıcının kimliği e-posta adresi değil, Google’ın gönderdiği kalıcı sub değeridir; e-posta değişebilir, sub değişmez. İkincisi, mevcut hesapla otomatik birleştirme yalnızca e-posta Google tarafından doğrulanmışsa yapılır; aksi hâlde başka birinin e-postasını iddia eden bir hesapla giriş yapılabilir. Üçüncüsü, bir kullanıcı birden fazla sağlayıcı bağlayabilmelidir; bu yüzden sağlayıcı bilgisi kullanıcı tablosuna sütun olarak değil ayrı bir “kimlikler” tablosuna (kullanıcı, sağlayıcı, sub) yazılır.

Kullanıcının anahtarı e-posta değil, sağlayıcının verdiği kalıcı kimliktir. E-postayı anahtar yapan sistem, adres değiştiğinde ya da başka bir sağlayıcı aynı adresi doğrulamadan gönderdiğinde hesapları karıştırır.

Kurumsal SSO: Google Workspace ve Microsoft Entra

Bir B2B ürününde ya da şirket içi panelde SSO istendiğinde iş birkaç adım büyür. Hangi alan adlarının girebileceği kısıtlanmalıdır: Google ID token’ındaki hd alanı kullanıcının Workspace alan adını taşır, ama bu alan yalnızca kontrol içindir, yetkilendirme yerine geçmez. Kullanıcı ilk girişte otomatik oluşturulacaksa (just-in-time provisioning) hangi rolle açılacağı tanımlanmalıdır; rol tasarımını kullanıcı rolleri ve yetkilendirme yazımızda anlattık. Microsoft Entra ya da başka bir kiracı bağlanacaksa müşteri tarafı genellikle SAML ya da OIDC ile kendi uygulama kaydını yapar; sizin tarafınızda her müşteri için ayrı yayıncı ve anahtar seti tutulur. En çok unutulan madde çıkıştır: çalışan şirketten ayrıldığında kimlik sağlayıcıdaki hesabı kapanır, ama sizin açık oturumunuz kendi süresi dolana kadar yaşar. Oturum süresi kısa tutulmalı ya da sağlayıcının çıkış bildirimi dinlenmelidir.

Güvenlik kontrol listesi

• state ve PKCE her istekte zorunlu; state tek kullanımlıktır ve callback’te çerezle karşılaştırılır.
• Redirect URI tam eşleşmeyle kayıtlıdır; test ve canlı ortam için ayrı istemci kullanılır, client_secret tarayıcıya ya da mobil pakete konmaz.
• ID token yalnızca kimlik için kullanılır; API’lere yetki vermek için kendi oturumunuz ya da kendi ürettiğiniz token kullanılır. ID token’ı erişim anahtarı gibi başka servislere göndermek yaygın bir hatadır.
• Kapsam (scope) asgari tutulur: openid, email ve profile çoğu site için yeterlidir. Takvim ya da Drive erişimi gerekiyorsa ayrı ve sonradan istenir.
• Google hesabını kaybeden kullanıcının kurtarma yolu baştan tasarlanır: e-posta ile tek kullanımlık bağlantı ya da ikinci bir sağlayıcı. Tek sağlayıcıya bağlı hesap, destek taleplerinin en sık nedenidir.
• Giriş uçlarına hız sınırı konur ve başarısız girişler loglanır; diğer saldırı yüzeyleri için web sitesi güvenliği yazımıza bakın.

Yüksek riskli işlemlerde (ödeme onayı, yetki değişikliği) Google girişi tek başına yeterli sayılmamalı, işlem anında ikinci bir doğrulama istenmelidir; bu tarafı SMS OTP doğrulama yazısında ele aldık.

Hazır kimlik servisi mi, kendi kurulumunuz mu?

Auth0, Firebase Authentication, Clerk gibi barındırılan servisler ve Keycloak gibi kendi sunucunuzda çalışan ürünler bu akışın tamamını, parola sıfırlamayı ve çok faktörlü doğrulamayı hazır verir. Tek sağlayıcı ve basit bir kullanıcı modeli için Auth.js gibi bir kütüphaneyle kendi kurulumunuz yeterlidir; kullanıcı verisi kendi veritabanınızda kalır. Çok kiracılı SSO, SAML desteği, çok faktörlü doğrulama ve denetim kayıtları birlikte isteniyorsa hazır servis ya da Keycloak projeyi haftalar kısaltır. Karar verirken iki soru sorulur: kullanıcı verisi nerede duracak ve servisten çıkmak istendiğinde kullanıcılar parola özetleriyle birlikte dışa aktarılabiliyor mu? Kullanıcı tablosu kendi veritabanınızdaysa ikinci soru kendiliğinden çözülür; bu yaklaşım SaaS ürünü geliştirme yazısındaki çok kiracılı modelle de uyumludur.

KVKK ve aydınlatma

Google ile girişte sizin tarafınıza ad, e-posta ve profil fotoğrafı gelir; bu kişisel veridir ve aydınlatma metninde kaynağı (kimlik sağlayıcı) ile işleme amacı yazılmalıdır. Yalnızca girişte kullanılacak veriyi isteyin, profil fotoğrafını gerekmiyorsa saklamayın. Ayrıntıları KVKK uyumlu web sitesi yazımızda bulabilirsiniz; bu yazı hukuki danışmanlık değildir.

Sonuç

Google ile giriş, doğru kurulduğunda hem kullanıcıya sürtünmesiz bir kayıt hem de sitenize parola saklamama kolaylığı verir. Teknik akış standarttır; projeyi belirleyen şey hesap eşleştirme kuralları, oturum ömrü ve kurumsal müşterilerin SSO beklentisidir. Mevcut sitenize sosyal giriş ya da kurumsal SSO eklemek istiyorsanız ihtiyacınızı teklif formundan iletin; akışı mevcut kullanıcı tablonuzla birlikte planlayalım.