ARCA Yazılım
Yazılım Mimarisi & Güvenlik

Kullanıcı Girişi ve Kimlik Doğrulama Yöntemleri: Şifreden Passkey'e, Sosyal Girişten SSO'ya

Şifreden passkey'e, sosyal girişten kurumsal SSO entegrasyonuna kadar modern web ve mobil uygulamalarda kimlik doğrulama yöntemlerini ve en iyi pratikleri keşfedin.

Şifre, sosyal giriş, OTP, Magic Link, passkey ve SSO etiketli anahtarların tek bir anahtarlıkta toplandığı, kimlik doğrulama yöntemlerini temsil eden kapak görseli.

Şifreden passkey'e, “Google ile giriş” butonundan kurumsal SSO'ya kadar bugün kullanılan giriş yöntemlerini, hangisinin ne zaman doğru seçim olduğunu ve web ile mobil uygulamalarda bunları nasıl güvenle kurabileceğinizi anlattık.

Kullanıcı girişi neden önemlidir?

Bir uygulamada kullanıcının ilk karşılaştığı ekran çoğu zaman giriş ekranıdır. Bu ekran iki işi aynı anda yapmak zorundadır: kapıyı yetkisiz kişilere sıkı sıkıya kapatmak ve doğru kişiyi hiç yormadan içeri almak.

Birinde başarısız olursanız bedelini ya bir güvenlik açığıyla ya da uygulamayı terk eden kullanıcılarla ödersiniz.

Kimlik doğrulamanın ne kadar kritik olduğunu sahadaki veriler de gösteriyor. Verizon'un 2025 Veri İhlali Araştırmaları Raporu'na (DBIR) göre çalınmış kimlik bilgileri, saldırganların sisteme ilk giriş yolları arasında yine ilk sırada yer aldı.


%22: İhlallerin yaklaşık beşte biri, kimlik bilgilerinin kötüye kullanılmasıyla başladı. Temel web uygulaması saldırılarında bu oran %88'e çıkıyor. (Verizon 2025 DBIR)

“Assume access, ready defenses.” (Verizon, 2025 Data Breach Investigations Report, s. 59)
Türkçesi: “Erişildiğini varsay, savunmanı hazırla.”

Yani iyi bir giriş sistemi yalnızca bir form değil; ürün deneyiminin, güvenlik mimarisinin ve çoğu zaman KVKK ile ISO 27001 gibi uyumluluk gerekliliklerinin kesiştiği yerdir. Aşağıda en yaygın yöntemleri tek tek ele alıyoruz.

E-posta ve şifre ile giriş

En tanıdık yöntem. Kullanıcı bir e-posta adresi ve şifre belirler, uygulama da şifreyi doğrudan değil, tuzlanmış ve yavaş bir özet fonksiyonundan geçirilmiş hâliyle saklar. Bugün önerilen algoritmalar Argon2id, scrypt veya bcrypt'tir; MD5 ya da SHA-1 gibi hızlı özetler şifre saklamak için kullanılmamalıdır.

E-posta ve şifre ile girişte şifrenin HTTPS üzerinden sunucuya iletilip Argon2id ile tuzlanarak özetlendiğini ve veritabanındaki özetle karşılaştırıldığını gösteren akış şeması.

Şifre hiçbir zaman düz metin olarak saklanmaz; veritabanında yalnızca tuzlanmış özet bulunur.

Şifre politikaları konusunda da ezberler değişti. ABD Ulusal Standartlar ve Teknoloji Enstitüsü'nün (NIST) Ağustos 2025'te yayımlanan güncel dijital kimlik rehberi, “en az bir büyük harf, bir rakam, bir sembol” türü kuralları artık açıkça yasaklıyor.

“Verifiers and CSPs SHALL NOT impose other composition rules … for passwords.” (NIST, SP 800-63B-4 Digital Identity Guidelines: Authentication, 2025)
Türkçesi: “Doğrulayıcılar ve kimlik hizmeti sağlayıcıları şifreler için başka bileşim kuralları dayatmamalıdır.”

Aynı rehberin öne çıkan önerileri şunlar:

  • Şifre tek doğrulama faktörüyse en az 15 karakter uzunluk istenmeli.
  • En az 64 karaktere kadar uzun şifrelere izin verilmeli.
  • Yeni şifreler sızdırılmış şifre listelerine karşı kontrol edilmeli.
  • Periyodik zorunlu şifre değişikliği kaldırılmalı.

Kısacası: karmaşık değil, uzun ve sızmamış şifre.

Avantajları

  • Herkesin bildiği, üçüncü tarafa bağımlı olmayan yöntem
  • Tüm platformlarda çalışır

Dezavantajları

  • Oltalama ve şifre tekrar kullanımına açık
  • Şifre sıfırlama akışları destek yükü yaratır

Sosyal giriş nasıl çalışır?

“Google ile giriş”, “Apple ile giriş” gibi butonların arkasında aynı mantık vardır: uygulamanız kullanıcıyı bir kimlik sağlayıcıya (Identity Provider, IdP) yönlendirir, kullanıcı orada oturum açıp izin verir, IdP de uygulamanıza kullanıcının kim olduğunu söyleyen imzalı bir kimlik belirteci (ID token) döner. Bu akışın standart adı OpenID Connect'tir ve OAuth 2.0 üzerine kuruludur.

Sosyal girişte kullanıcının uygulamadan kimlik sağlayıcıya yönlendirildiği, onay sonrası tek kullanımlık kodun ID token ile değiştirildiği OpenID Connect Authorization Code ve PKCE akış şeması.

Sosyal girişin arkasındaki OpenID Connect “Authorization Code + PKCE” akışının sadeleştirilmiş hâli.

Kullanıcı açısından büyük kolaylık: yeni şifre yok, form doldurma yok. Sizin açınızdan da şifre saklama sorumluluğu azalır.

Buna karşılık bir dış sağlayıcıya bağımlı hâle gelirsiniz ve aynı kişinin farklı sağlayıcılarla açtığı hesapları birleştirme (account linking) meselesini baştan planlamanız gerekir.

Apple ile devam et, Google ile devam et ve Microsoft ile devam et butonlarının üstte, e-posta ile giriş seçeneğinin altta yer aldığı örnek mobil uygulama giriş ekranı.

Tipik bir sosyal giriş ekranı. Her sağlayıcının kendi buton tasarım kuralları vardır; canlıya çıkmadan önce resmi marka yönergelerine uygun butonları kullanın.

Google ile Giriş

Türkiye'de Android kullanıcılarının ve Gmail/Google Workspace hesabı olanların payı yüksek. Bu yüzden tüketiciye dönük uygulamalarda en yüksek dönüşümü getiren sosyal giriş seçeneği genellikle Google olur.

Web tarafında Google Identity Services kütüphanesiyle tek dokunuşla giriş (One Tap) sunulabilir; Android'de ise Credential Manager API'si şifre, passkey ve Google hesabını tek bir seçim ekranında birleştirir.

Bir e-ticaret sitesinin sağ üst köşesinde açılan, kullanıcının Google hesabını gösteren ve tek tıkla devam etmeyi sağlayan Google One Tap giriş penceresi.

One Tap: kullanıcı tarayıcıda Google'a zaten giriş yapmışsa, sayfanın köşesinde açılan küçük bir pencereyle tek tıkla hesap oluşturur ya da oturum açar.

Android Credential Manager alt panelinde kayıtlı passkey, kayıtlı şifre ve Google hesabı seçeneklerinin aynı listede sunulduğu giriş ekranı.

Android'de Credential Manager, kullanıcının cihazda kayıtlı tüm giriş yollarını tek bir alt panelde sunar; uygulama tarafında tek bir API çağrısıyla yönetilir.

• İpucu: Google Workspace kullanan kurumsal müşterilerde dönen ID token içindeki hd (hosted domain) alanı, kullanıcının hangi şirketten geldiğini anlamanıza yardımcı olur; ancak yetkilendirme kararını yalnızca buna dayandırmayın, sunucu tarafında token imzasını mutlaka doğrulayın.

Apple ile Giriş

“Apple ile giriş”, iOS kullanıcılarına Face ID veya Touch ID ile tek dokunuşta hesap açtırır. En dikkat çekici özelliği “E-postamı Gizle” seçeneğidir: kullanıcı isterse uygulamanıza gerçek adresi yerine Apple'ın ürettiği, gelen postaları kendisine ileten rastgele bir adres verir.

iPhone'da Apple ile giriş onay ekranında ad bilgisi, E-postamı paylaş ve E-postamı gizle seçenekleri ile Face ID ile devam et butonu.

Kullanıcı, uygulamaya gerçek e-posta adresini mi yoksa Apple'ın ürettiği bir aktarma adresini mi vereceğini tek ekranda seçer ve Face ID ile onaylar.

E-postamı Gizle seçildiğinde uygulamanın gönderdiği e-postanın Apple aktarma servisi üzerinden kullanıcının gerçek gelen kutusuna iletildiğini gösteren akış şeması.

“E-postamı Gizle” seçildiğinde uygulamanız kullanıcının gerçek adresini hiç görmez; iletişim Apple'ın aktarma servisi üzerinden yürür.

Geliştiriciler için iki önemli not var. Birincisi, Apple kullanıcının adını ve e-postasını yalnızca ilk yetkilendirmede gönderir; bu bilgiyi o an kaydetmezseniz sonradan tekrar alamazsınız.

Sahadan not: Test sırasında sık yaşanan bir tuzak: geliştirici aynı Apple hesabıyla ikinci kez giriş yaptığında ad alanı boş gelir ve profil “isimsiz” kaydedilir. Testlerde her seferinde iPhone'da Ayarlar > Apple Kimliği > Apple ile Giriş bölümünden uygulamanın bağlantısını kaldırıp ilk giriş senaryosunu yeniden deneyin.

İkincisi, App Store kuralları, üçüncü taraf bir giriş yöntemi sunan uygulamaların gizlilik odaklı eşdeğer bir seçenek de sunmasını ister; pratikte bu seçenek çoğu zaman Apple ile giriş olur.

Microsoft ile Giriş

Microsoft kimlik platformu, tek bir entegrasyonla hem kişisel Microsoft hesaplarını (Outlook.com, Xbox) hem de iş/okul hesaplarını (Microsoft Entra ID) destekleyebilir. .NET, Angular, iOS ve Android için hazır MSAL kütüphaneleri bulunur.

Kullanıcılarınızın önemli bir kısmı kurumsal çalışanlarsa, “Microsoft ile giriş” butonu aslında kurumsal SSO'ya açılan kapıdır; bu konuyu aşağıda Entra ID başlığında ayrıca ele alıyoruz.

Microsoft ile girişte Microsoft kimlik platformunun kullanıcıyı hesap türüne göre kişisel Microsoft hesabına veya şirketin Entra ID dizinindeki iş hesabına yönlendirdiğini gösteren şema.

Tek entegrasyon, iki kitle: kişisel Microsoft hesabı olanlar ve Microsoft 365 kullanan şirketlerin çalışanları aynı butondan giriş yapar.

Meta/Facebook ile Giriş

Facebook Login, özellikle oyun, sosyal ve kampanya odaklı tüketici uygulamalarında hâlâ kullanılıyor. Kullanıcının profil fotoğrafı gibi verilere (izin verdiği ölçüde) erişim sağlayabilmesi pazarlama tarafında cazip görünebilir.

Ancak iş ve kurumsal uygulamalarda tercih edilme oranı düşüktür. Ayrıca uygulama incelemesi (App Review) ve izin yönetimi süreçleri diğer sağlayıcılara göre daha fazla bakım ister. Hedef kitleniz gerçekten Facebook/Instagram ekosistemindeyse değerlendirin, değilse listenin sonuna koyun.

Facebook Login izin ekranında uygulamanın ad, profil fotoğrafı ve e-posta adresi istediği, arkadaş listesi izninin kapalı olduğu ve izinlerin düzenlenebildiği onay penceresi.

Kullanıcı izinleri tek tek kapatabilir; uygulamanız istenen e-posta adresinin gelmediği durumu da karşılayabilmelidir.

Google, Apple, Microsoft ve Meta/Facebook ile girişin tüketici (B2C) ve kurumsal (B2B) kitlelerde ne kadar işe yaradığını temsili çubuklarla karşılaştıran grafik.

Temsili karşılaştırma: çubuk uzunluğu, sağlayıcının o kitlede ne kadar işe yaradığına dair saha deneyimimizi yansıtır; ölçülmüş bir pazar verisi değildir.

Telefon Numarası ve SMS ile Giriş

Kullanıcı telefon numarasını girer, uygulama SMS ile tek kullanımlık bir kod gönderir, kod doğru girilince oturum açılır. Türkiye'de yemek siparişi, mobilite, e-ticaret ve fintech uygulamalarında son derece yaygın; çünkü telefon numarası hem kimlik hem de iletişim kanalı olarak işe yarar.

Güvenlik tarafında ise dikkatli olmak gerekir. SMS, SIM kartı kopyalama/taşıma (SIM swap) saldırılarına ve operatör ağındaki zafiyetlere açıktır. NIST de telefon şebekesi üzerinden gönderilen kodları “kısıtlı” doğrulayıcılar arasında sayar; yani kullanılabilir, ama riskleri kullanıcıya ve sisteme göre değerlendirilerek.

  • SMS kodlarını 3–5 dakikayla sınırlayın ve deneme sayısını kısıtlayın.
  • Aynı numaraya art arda kod gönderimini hız sınırlamasıyla engelleyin; aksi hâlde “SMS pompalama” dolandırıcılığıyla ciddi faturalarla karşılaşabilirsiniz.
  • Ödeme, şifre değişikliği gibi kritik işlemlerde SMS'i tek başına yeterli görmeyin.

Sahadan not: SMS pompalama genellikle gece saatlerinde, yurt dışı numaralara yüzlerce “kod gönder” isteği şeklinde gelir ve fark edildiğinde fatura çoktan oluşmuştur. Yalnızca Türkiye numaralarına hizmet veriyorsanız ülke kodu kısıtı, IP başına saatlik sınır ve SMS sağlayıcı panelinde günlük harcama limiti, bu riski büyük ölçüde kapatır.

OTP ile Giriş

OTP (One-Time Password), tek seferlik şifre demektir ve aslında bir kanal değil bir kavramdır. Kod SMS ile, e-posta ile ya da bir doğrulayıcı uygulama (Google Authenticator, Microsoft Authenticator vb.) tarafından üretilebilir.

Doğrulayıcı uygulamaların kullandığı TOTP standardında kod, cihazdaki gizli anahtar ve o anki zamandan hesaplanır ve genellikle 30 saniyede bir değişir; ağ üzerinden hiç gönderilmediği için SMS'e göre daha güvenlidir.

Tek kullanımlık kodun SMS, e-posta ve 30 saniyede bir yenilenen doğrulayıcı uygulama (TOTP) kanallarıyla iletilmesini yan yana gösteren karşılaştırma görseli.

Aynı “tek kullanımlık kod” fikri, üç farklı kanaldan üç farklı güvenlik seviyesiyle sunulabilir.

Magic Link ile Giriş

Magic Link'te kullanıcı yalnızca e-posta adresini yazar; uygulama bu adrese tek kullanımlık, süreli bir giriş bağlantısı gönderir. Bağlantıya tıklayan kullanıcı doğrudan içeri alınır. Şifre olmadığı için unutulan şifre de, sızan şifre de yoktur.

Kullanıcının e-posta adresini girdiği, gelen kutusuna tek kullanımlık giriş bağlantısı düştüğü ve bağlantıya tıklayınca oturum açılıp bağlantının geçersiz olduğu Magic Link akış şeması.

Seyrek kullanılan uygulamalar (etkinlik kaydı, bayi portalı, anket, müşteri self-servis ekranları) için idealdir. Günde defalarca giriş yapılan uygulamalarda ise her seferinde e-postaya gitmek kullanıcıyı yorar.

Bağlantıyı 10–15 dakikayla sınırlandırın ve tek kullanımlık yapın.

Sahadan not: Kurumsal e-posta sistemlerindeki güvenlik tarayıcıları, gelen bağlantıları kontrol etmek için kullanıcıdan önce açabiliyor. Tek kullanımlık bağlantı bu sırada tüketilirse kullanıcı “bağlantı geçersiz” hatası görür. Çözüm basit: bağlantı açıldığında doğrudan oturum açmak yerine “Giriş yap” onay düğmesi gösterin.

Passkey ile Giriş

Passkey, şifrenin yerini almak için geliştirilen ve FIDO Alliance ile W3C'nin WebAuthn standartlarına dayanan yöntemdir.

Kullanıcı hesap açarken cihazı bir anahtar çifti üretir: gizli anahtar cihazda (veya iCloud Anahtar Zinciri, Google Şifre Yöneticisi gibi bir senkronizasyon hizmetinde) kalır, sunucuya yalnızca açık anahtar gönderilir. Girişte kullanıcı parmak izi, yüz tanıma veya cihaz PIN'i ile onay verir.

Passkey ile girişte gizli anahtarın kullanıcının cihazında kaldığını, sunucunun rastgele meydan okumayı yalnızca açık anahtarla doğruladığını gösteren akış şeması.

Sunucuda çalınabilecek bir sır tutulmaz; sahte bir alan adı imza isteyemez. Passkey'i oltalamaya dayanıklı yapan budur.

Passkey'in en büyük artısı oltalamaya dayanıklı olmasıdır: anahtar yalnızca kaydedildiği alan adında çalışır, kullanıcı sahte bir siteye yönlendirilse bile imza üretilmez.

Sunucunuz sızdırılsa bile saldırganın eline yalnızca işe yaramaz açık anahtarlar geçer. 2026 itibarıyla iOS, Android, Windows ve macOS'un güncel sürümleri passkey'i yerleşik olarak destekliyor.

Geçiş dönemi için pratik önerimiz: passkey'i şifreye ek bir seçenek olarak sunun, başarılı bir şifreli girişten sonra kullanıcıya “Bir dahaki sefere parmak izinizle girin” önerisi gösterin ve hesap kurtarma akışını (kaybolan telefon senaryosu) baştan tasarlayın.

Microsoft Entra ID ile Kurumsal Giriş

Microsoft Entra ID, 2023'e kadar Azure Active Directory (Azure AD) adıyla bilinen bulut tabanlı kurumsal kimlik hizmetidir. Microsoft 365 kullanan şirketlerde çalışanların kimlikleri zaten Entra ID'de durur.

Uygulamanızı Entra ID ile entegre ettiğinizde çalışanlar Outlook'a girdikleri hesapla uygulamanıza da girer.

Entra ID'yi kurumsal müşteriler için cazip kılan şey, kimlik kontrolünün müşterinin elinde kalmasıdır:

  • Koşullu Erişim (Conditional Access): “Yalnızca şirket cihazlarından”, “yurt dışından girişte MFA zorunlu” gibi kuralları müşterinin BT ekibi belirler.
  • Merkezi hesap yönetimi: İşten ayrılan bir çalışanın hesabı Entra ID'de kapatıldığında uygulamanıza erişimi de sona erer.
  • Çok kiracılı (multi-tenant) uygulama kaydı: Tek bir uygulama kaydıyla farklı şirketlerin Entra ID dizinlerinden kullanıcı kabul edebilirsiniz; her müşteri kendi yöneticisi aracılığıyla onay verir.
  • Grup ve rol eşleme: Entra ID'deki grupları uygulamanızdaki rollere bağlayarak yetkileri de merkezi yönetebilirsiniz.

Entra ID hem OpenID Connect hem de SAML protokolünü destekler. Yeni geliştirilen uygulamalarda OpenID Connect ve Microsoft'un MSAL kütüphaneleri genellikle en kısa yoldur.

SSO nedir?

SSO (Single Sign-On, Tekli Oturum Açma), kullanıcının tek bir kimlik sağlayıcıda bir kez oturum açarak birden fazla uygulamaya yeniden şifre girmeden erişebilmesidir.

Örneğin sabah bilgisayarını açıp şirket hesabıyla giriş yapan bir çalışan, gün boyunca e-postasına, ERP'sine, CRM'ine ve sizin uygulamanıza aynı oturumla geçebilir.

Merkezdeki tek kimlik sağlayıcı üzerinden e-posta, ERP, CRM, mobil uygulama ve kurumsal uygulamaya tek oturumla erişildiğini gösteren SSO şeması.

SSO'da kimlik tek bir yerde doğrulanır; uygulamalar kullanıcıyı bu merkeze sorar.

SSO'nun faydası yalnızca konfor değildir:

  • Kullanıcının aklında tutması gereken şifre sayısı azalır.
  • MFA ve cihaz politikaları tek noktadan uygulanır.
  • İşten ayrılan çalışanın erişimleri tek hamlede kapatılır.
  • ISO 27001 denetimlerinde erişim yönetimini belgelemek kolaylaşır.

SAML ve OpenID Connect Nedir?

SSO bir kavramdır; onu hayata geçiren protokollerin en yaygın iki tanesi SAML ve OpenID Connect'tir.

SAML 2.0

SAML (Security Assertion Markup Language), 2005'ten beri kullanılan, XML tabanlı bir standarttır. Kimlik sağlayıcı, kullanıcının kim olduğunu ve niteliklerini içeren imzalı bir XML belgesi (assertion) üretir ve bunu tarayıcı üzerinden uygulamaya iletir.

Kurumsal dünyada çok olgundur; birçok eski ve büyük sistem hâlâ SAML ile çalışır.

OpenID Connect (OIDC)

OpenID Connect, 2014'te yayımlanan ve OAuth 2.0 üzerine kurulu bir kimlik katmanıdır. Kimlik bilgisi JSON tabanlı, imzalı bir JWT (ID token) olarak taşınır.

Mobil uygulamalara, tek sayfa uygulamalara (SPA) ve API'lere doğal biçimde uyum sağladığı için yeni projelerde varsayılan tercih hâline gelmiştir. Google, Apple ve Microsoft ile giriş de OIDC'dir.

SAML 2.0 ile OpenID Connect karşılaştırması

Pratik kural: Yeni bir ürün geliştiriyorsanız OpenID Connect ile başlayın. Kurumsal müşterileriniz arasında SAML isteyenler çıkacağını biliyorsanız, kimlik katmanınızı iki protokolü de konuşabilen bir yapı (Keycloak, Duende IdentityServer, Auth0, Entra External ID vb.) üzerine kurun.

B2B Uygulamalarda Hangi Giriş Yöntemi Tercih Edilmeli?

Kurumsal müşteriye satılan bir yazılımda giriş yöntemi artık teknik bir detay değil, satın alma kriteridir.

Sahadan not: Kurumsal satış görüşmelerinde müşterinin BT ekibinden gelen ilk teknik sorulardan biri çoğu zaman “Entra ID ile SSO var mı?” oluyor. Bu soruya “yol haritasında” diye yanıt vermek, bazı ihalelerde ürünü doğrudan elenmiş hâle getirebiliyor.

Deneyimlerimize göre sağlıklı bir B2B kurgusu şu katmanlardan oluşur:

  • Kurumsal SSO (OIDC + SAML): Her müşteri kendi kimlik sağlayıcısını (Entra ID, Okta, Google Workspace) bağlayabilmeli. Kullanıcının e-posta alan adına göre doğru sağlayıcıya otomatik yönlendirme (home realm discovery) deneyimi çok iyileştirir.
  • Yedek yöntem: SSO kullanmayan küçük müşteriler, taşeronlar ve bayiler için e-posta + şifre veya passkey, mutlaka MFA ile birlikte.
  • Otomatik kullanıcı yönetimi: Büyük müşteriler SCIM ile kullanıcı açma/kapatma işlemlerinin kendi dizinlerinden otomatik yapılmasını isteyecektir.
  • Çok kiracılı veri izolasyonu: Kimlik doğrulaması başarılı olsa bile, token'daki kiracı (tenant) bilgisi her istekte kontrol edilmeli.
Senaryoya göre önerilen giriş yöntemleri

Web ve Mobil Uygulamalar için Giriş Mimarisi

Giriş yöntemlerini tek tek uygulamanın içine gömmek yerine, kimlik doğrulamayı ayrı bir katmanda toplamak uzun vadede büyük zahmetten kurtarır. Aşağıdaki şema, .NET tabanlı bir API ile Angular web uygulaması ve mobil uygulamanın bulunduğu tipik bir yapıyı gösteriyor.

Angular web uygulamasının BFF üzerinden, mobil uygulamanın PKCE ile kimlik sunucusuna bağlandığı; kimlik sunucusunun Google, Apple ve Entra ID ile federasyon kurduğu web ve mobil giriş mimarisi şeması.

Kimlik sunucusu tüm giriş yöntemlerini tek noktada toplar; uygulamalar yalnızca OIDC konuşur.

Web Uygulamaları için

Angular, React gibi tarayıcıda çalışan uygulamalarda token'ları localStorage'da tutmak, XSS açığı durumunda token'ların çalınmasına zemin hazırlar.

Güncel öneri BFF (Backend for Frontend) desenidir: OIDC akışını sunucu tarafındaki ince bir katman yürütür, token'lar sunucuda kalır, tarayıcıya yalnızca HttpOnly, Secure ve SameSite işaretli bir oturum çerezi verilir.

Mobil Uygulamalar için

Mobilde giriş ekranı uygulama içindeki bir WebView'da değil, sistem tarayıcısında (iOS'ta ASWebAuthenticationSession, Android'de Custom Tabs) açılmalıdır. Bu hem güvenlik hem de mevcut oturumları paylaşma açısından şarttır.

Akış olarak Authorization Code + PKCE kullanılmalı, refresh token'lar iOS Keychain veya Android Keystore'da saklanmalıdır.

.NET Tarafında

ASP.NET Core ekosisteminde kimlik sunucusu için Duende IdentityServer, OpenIddict veya açık kaynak Keycloak; bulut tarafında Microsoft Entra External ID gibi yönetilen hizmetler öne çıkan seçeneklerdir. API tarafında ise JWT Bearer doğrulaması ile issuer, audience, imza ve süre kontrollerinin eksiksiz yapılması yeterlidir.

Güvenli Kimlik Doğrulama için Dikkat Edilmesi Gerekenler

Hangi yöntemi seçerseniz seçin, aşağıdaki kontrolleri canlıya çıkmadan önce gözden geçirmenizi öneririz. Bu listeyi OWASP Uygulama Güvenliği Doğrulama Standardı (ASVS) ve NIST rehberinden derledik.

Kimlik doğrulama güvenliğini saklama, doğrulama, oturum ve izleme katmanları ile her katmandaki temel önlemler üzerinden anlatan katmanlı şema.

Tek bir önlem yeterli değil; güvenlik birbirini tamamlayan katmanlardan oluşur.

  • MFA'yı varsayılan yapın. Özellikle yönetici hesaplarında istisnasız zorunlu olsun; mümkünse passkey veya TOTP tercih edin.
  • Hesap tespitini (account enumeration) engelleyin. “Bu e-posta kayıtlı değil” yerine her durumda aynı genel mesajı gösterin.
  • Hız sınırlaması ve kilitleme uygulayın. IP ve hesap bazında deneme sınırı koyun, kaba kuvvet ve credential stuffing saldırılarını yavaşlatın.
  • Sızdırılmış şifreleri reddedin. Yeni şifreleri bilinen ihlal listelerine karşı kontrol edin.
  • Token ömürlerini kısa tutun. Access token dakikalar, refresh token günler mertebesinde olsun; refresh token'ları her kullanımda yenileyin.
  • Token'ları eksiksiz doğrulayın. İmza, issuer, audience, süre ve (OIDC'de) nonce kontrolü atlanmamalı.
  • Şifre sıfırlama akışını da giriş kadar ciddiye alın. Sıfırlama bağlantıları tek kullanımlık ve kısa ömürlü olmalı; güvenlik soruları kullanılmamalı.
  • Olayları kaydedin. Başarılı/başarısız girişler, MFA değişiklikleri ve yeni cihaz girişleri denetim kaydına yazılmalı, kullanıcıya bildirim gitmeli.
  • Kişisel veriyi minimumda tutun. Sosyal girişte ihtiyacınız olmayan izinleri istemeyin; KVKK kapsamında aydınlatma metninizi güncel tutun.

Sık Sorulan Sorular

SSO nedir, ne işe yarar?
SSO, kullanıcının tek bir kimlik sağlayıcıda bir kez oturum açarak birden fazla uygulamaya yeniden şifre girmeden erişmesini sağlar. Kullanıcı deneyimini iyileştirir, şifre sayısını azaltır ve erişim yönetimini merkezileştirir.

SAML ile OpenID Connect arasındaki fark nedir?
SAML XML tabanlı ve kurumsal web uygulamalarında yaygın, daha eski bir standarttır. OpenID Connect ise OAuth 2.0 üzerine kurulu, JSON/JWT kullanan ve mobil ile API senaryolarına daha iyi uyum sağlayan modern protokoldür.

Passkey şifreden daha mı güvenli?
Evet. Passkey'de sunucuda çalınabilecek bir sır tutulmaz ve anahtar yalnızca kayıtlı alan adında çalıştığı için oltalamaya karşı dayanıklıdır.

SMS ile giriş güvenli mi?
Kullanışlıdır ancak SIM swap gibi saldırılara açıktır. Düşük riskli senaryolarda tek başına, yüksek riskli senaryolarda ise yalnızca yedek yöntem olarak kullanılmasını öneriyoruz.

B2B uygulamalarda hangi giriş yöntemi seçilmeli?
Müşterinin kendi kimlik sağlayıcısıyla OIDC veya SAML üzerinden SSO desteği ve SSO kullanmayan kullanıcılar için MFA destekli yedek bir yöntem en sağlıklı kurgudur.

Sonuç

Tek bir “doğru” giriş yöntemi yok; doğru olan, kullanıcı kitlenize, risk seviyenize ve iş modelinize uygun kombinasyon.

Tüketici uygulamalarında Google ve Apple ile giriş dönüşümü artırırken, kurumsal ürünlerde Entra ID ile SSO satışın ön koşulu hâline geliyor. Passkey ise önümüzdeki yıllarda şifrenin yerini alacak en güçlü aday. Hepsinin ortak noktası, iyi tasarlanmış bir kimlik mimarisine ihtiyaç duymaları.

Uygulamanız için Doğru Giriş Altyapısını Birlikte Kuralım

Arca Yazılım olarak web ve mobil uygulamalarınızda sosyal giriş, passkey, Microsoft Entra ID entegrasyonu ve kurumsal SSO altyapısını .NET, Angular ve mobil teknolojilerle uçtan uca tasarlayıp hayata geçiriyoruz.

Bu konu hakkında daha fazla bilgi almak için 0312 256 72 78 numaralı telefondan bize ulaşabilir, detaylı bilgi ve diğer çözümlerimiz için www.arcayazilim.com adresini ziyaret edebilirsiniz.

Projenizi konuşalım

Bu konuyla ilgili ihtiyaçlarınızı ekibimizle paylaşın.

WhatsApp'tan yazın