Bir kimlik sağlayıcısı nasıl seçilir: Mühendislik ekibinin değerlendirme çerçevesi

Çoğu kimlik sağlayıcı karşılaştırma makalesi, kimlik sağlayıcılar tarafından yazılır. Şaşırtıcı, değil mi? Ürünlerinde olan özellikleri listeler, olmayanları atlarlar, sonra da buna "nesnel bir rehber" derler.

Bu öyle bir rehber değil.

Satıcılara verilen onlarca gerçek kurumsal değerlendirme talebini — tedarik ekiplerinin gönderdiği gerçek tablo ve RFP belgelerini — inceledik. Kalıplar net: mühendislik ekipleri en önemli kriterleri yeterince dikkate almıyor, önemsiz kriterlere fazla ağırlık veriyor.

Sonuç? Ekipler bir IdP'yi bir tanıtıma bakarak seçiyor, altı ay sonra geçişin kabus gibi olduğunu fark ediyor ve yeniden değerlendirmeye başlıyor.

Keşke biri başlamadan önce bize bu değerlendirme çerçevesini verseydi. B2B SaaS şirketlerindeki mühendislik ekipleri için hazırlandı — çalışanlarına işyeri SSO alanlar için değil, ürün geliştirenler için.

Hızlı cevap: Bir IdP kararını ne bozar ne yapar#

Sadece göz gezdiriyorsan, kısası şudur:

1. Protokol derinliği, özellik sayısından daha önemlidir. "OAuth2 destekliyoruz" hiçbir şey ifade etmez. Hangi izin türleri? Jeton claim'lerini özelleştirebilir misin? Kendi OIDC sağlayıcın olabilir misin?
2. Geçiş yeteneği en az değer verilen kriterdir. Mevcut kullanıcılarını şifre sıfırlamaya zorlamadan taşıyamıyorsan, IdP kullanılamaz — diğer her şey ne kadar iyi görünürse görünsün.
3. Çok kiracılı yapı doğal olmalı, sonradan eklenmemeli. Organizasyon modelleri ve kiracıya özel yapılandırmalar için geçici çözümler gerekiyorsa, sistemle hep boğuşacaksın.
4. Yapay zeka uyumluluğu gelecek planı değil — 12 ay içerisinde şarttır. Jeton değişimi, ajan kimliği, devredilen kapsamlar. IdP bunları desteklemiyorsa, önümüzdeki yıl yine burada olacaksın.

Bu rehberin geri kalanı, her bir değerlendirme boyutunu ayrıntılı olarak ele alıyor, sorulacak özel sorular ve bakılması gereken tehlike sinyalleriyle birlikte.

Bu rehber kimlere uygun (ve kimlere uygun değil)#

Senin için UYGUNSA:

• 50-300 kişilik bir B2B SaaS şirketinde CTO, Mühendislik Başkan Yardımcısı veya platform mimarısın
• 100.000'den fazla mevcut kullanıcın var ve yıkıcı bir geçişi karşılayamazsın
• Kurumsal müşterilere yöneliyorsun ve bunlar SSO, organizasyon modelleri, denetim kayıtları istiyor
• Teknik bir değerlendirme raporu yazman gerekiyor ve satıcıdan olmayan bir çerçeve arıyorsun

SENİN için UYGUN DEĞİLSE:

• İşyeri IAM (çalışanların dahili araçlara SSO'su) arıyorsun — bu başka bir satın alma kararı
• 500 kullanıcılı bir girişimsin ve henüz kurumsal müşterin yok — en iyi SDK'ya sahip olanı seç ve devam et
• Kimlik doğrulama (KYC/KYB) arıyorsun — bu tamamen başka bir kategoridir

Boyut 1: Protokol yetenekleri — Sadece "OAuth2 destekliyor" değil#

Piyasadaki her IdP, OAuth2 ve OIDC desteklediğini söyler. Bu asgari gerekliliktir. Asıl sorular derinlikle ilgilidir.

Yetkilendirme türleri: Hangileri ve neden önemli#

Olmazsa olmazlar:

• Authorization Code + PKCE — Tarayıcı tabanlı ve mobil uygulamalar için kullanman gereken tek akış. Bir satıcı Hala Implicit akışı öneriyorsa, uzak dur. PKCE zorunludur — bir güvenlik gereksinimidir.
• Client Credentials — Servisler arası iletişim için. Arka plan servislerin bir kullanıcı olmadan birbirini kimliklendirmeli.
• Refresh Token — Basit görünür, ama uygulama ayrıntıları büyük farklılık gösterebilir. Rotasyon yapılandırılabilir mi? Süresi? Belirli bir refresh token'ı tüm oturuma dokunmadan iptal edebilir misin?

Giderek kritikleşen:

• Token Exchange (RFC 8693) — AI ajan kimlik doğrulaması, vekalet akışları ve delege işlemleri sağlar. Bugün yoksa, yol haritasında var mı sor. Eğer yoksa, bu kırmızı bayraktır.

OIDC Sağlayıcı yeteneği#

Takımların çoğunun sormayı aklına getirmediği bir soru: Bu IdP'yi bir OIDC Sağlayıcısı olarak kullanabilir misin — sadece OIDC tüketicisi olarak değil?

Neden önemli: SaaS'in büyüdükçe, ortakların ve müşterilerin senin kimlik sistemini kendi araçlarına giriş için kullanmak istemesi olası. Jeton dağıtman, onay yönetmen, üçüncü taraf uygulama kayıtlarını işlemen gerekiyor. IdP sadece dış kimlik sağlayıcıları tüketmeye izin veriyor ama kendisi sağlayıcı olamıyorsa, dışa federasyon gerektiğinde duvara çarparsın.

Sorular:

• IdP, beyaz etiketlenebilir bir OpenID Discovery uç noktası sunuyor mu?
• Farklı güven seviyelerine sahip birinci ve üçüncü taraf uygulamaları kaydedebilir misin?
• Birinci taraf uygulamalar onay ekranını atlayabilirken, üçüncü taraflar için zorunlu kılabilir misin?

JWT özelleştirme#

Jeton, IdP'nin servislerinle yaptığı sözleşmedir. Özelleştiremiyorsan, her alt servis kullanıcının ne yapmaya yetkili olduğunu anlamak için ek API çağrısına muhtaç olur.

Sorular:

• Erişim ve ID jetonlarına özel claim ekleyebilir misin?
• Organizasyon bağlamını (kullanıcının hangi kiracıda çalıştığı) jetona doğrudan ekleyebilir misin?
• Uygulamanın yetki modeline karşılık gelen özel kapsamlar tanımlayabilir misin?
• Claim'ler jeton verilme zamanında mı hesaplanıyor, yoksa webhook veya betikle dinamik mi doldurulabiliyor?

{ "org_id": "org_123", "role": "admin", "auth_level": 2 } taşıyan bir jeton, API ara katmanının tek satırda yetkilendirme kararı almasını sağlar. { "sub": "user_456" } taşıyan bir jetonda ise her servis IdP ya da bir veritabanına tekrar sorgulama yapar. Ölçekte bu 2ms ile 200ms'lik bir fark doğurur.

Boyut 2: Kimlik doğrulama akışları — Sizi batıran ayrıntılar#

Her IdP e-posta/şifre ve sosyal giriş destekler. Tebrikler, adaylarınız... hepsi!

Fark yaratansa çoğu demo senaryosunda olmayan ayrıntılarda gizli.

Kayıt akışı#

• Kayıt sonrası otomatik oturum açma: Kullanıcı kaydolduktan sonra otomatik olarak oturum açılıyor mu? Yoksa tekrar giriş ekranı mı görünüyor? Kaydolur kaydolmaz kullanıcıdan tekrar oturum açmasını istemek, dönüşüm oranını öldürür. Kaç IdP'nin hâlâ bunu yanlış yaptığını görünce şaşıracaksınız.
• Özel kayıt alanları: Rol, şirket adı veya kullanım amacı gibi bilgiler kayıtta toplanabiliyor mu? Yoksa sonradan ek bir onboarding akışına mı ihtiyacın var?
• Aşamalı profil oluşturma: Tüm bilgilerin tek seferde istenmesi yerine, birden çok oturumda ek bilgi toplamak mümkün mü?

Giriş akışı#

• login_hint desteği: Kullanıcı bir pazarlama e-postasındaki linke tıkladığında e-posta adresini önceden doldurabiliyor musun? Önemsiz görünebilir. Değil. E-posta kampanyalarında %40 ile %60 dönüşüm oranı farkı yaratır.
• Kuruluşa özgü kimlik doğrulama politikaları: A Organizasyonu SAML SSO isterken, B Organizasyonu e-posta/şifre mi kullanıyor? Yalnızca kurumsal kiracılar için MFA zorunlu kılabiliyor musun? Kiracıya özel kimlik doğrulama politikalarında kod değişikliği gerekiyorsa, her kurumsal müşteri getirdiğinde mühendislik kaynaklarını yakarsın.
• Marka özelleştirmesi: Giriş deneyimini kiracıya göre özelleştirebilir misin? Sadece logo ve renkler değil — tam CSS kontrolü, özel alan adları ve beyaz etiketli e-posta gönderimi. "Barındırılmış UI mı yoksa kendi UI'ni getir" seçimini sen yapabilmelisin.

Çoğu kontrol listesinin atladığı noktalar#

• Sessiz kimlik doğrulama: Jeton süresi dolunca, uygulama kullanıcının fark etmeden sessizce yenileyebilir mi? Yenileme jetonu da geçersizse ne oluyor — (ör. iframe üzerinden kayan oturum gibi) bir yedek var mı?
• Hesap birleştirme: Kullanıcı Google ile kaydolup sonra e-posta ile giriş yapmayı denerse iki ayrı hesap mı olur, yoksa bir mi? IdP kimlik birleştirmeyi nasıl idare ediyor? Yanlış kurarsan ömür boyu hayalet, çoğaltılmış kullanıcı hesapların olur.
• Şifresiz seçenekler: Sihirli bağlantılar, passkey'ler, WebAuthn. Bugün herkesin ihtiyacı olmayabilir, ancak kurumsal müşteriler 6 ay içinde bunu istemeye başlar.

Boyut 3: Oturum ve jeton yönetimi — Derin sular#

İşte burada değerlendirmeler, tanıtımlardan ayrılır. Oturum ve jeton yönetimi sıkıcıdır, ta ki bozulana kadar — bozulunca tüm kullanıcı tabanınız anında oturumu kapatır.

Çerez güvenliği#

Parıltılı değildir ama hayati derecede önemlidir.

• HttpOnly, Secure, SameSite nitelikleri: Üçünün de doğru ayarlanması gerekir. Oturum çerezlerinde HttpOnly ayarlamayan bir IdP, üretime hazır değildir.
• Alt alan adı desteği: Uygulaman app.seninurun.com'da, API ise api.seninurun.com'daysa, oturumlar alt alanlarda geçiş yapabilir mi? Nasıl?
• Üçüncü taraf çerezlerinin terk edilişi: Chrome bunları aşamalı olarak kaldırıyor. IdP üçüncü taraf çerezleri olmadan çapraz orijinli kimlik doğrulama akışını nasıl yönetiyor? Yanıt "üzerinde çalışıyoruz" ise, bu yeterli değil.

Beni hatırla ve kalıcı oturumlar#

Kullanıcıların haftalarca oturum açık kalmak ister, dakikalarca değil. Ama 180 günlük kalıcı bir oturumun, 30 dakikalık oturumdan çok farklı güvenlik sonuçları vardır.

Sorular:

• Oturum süresi ile jeton ömrünü bağımsız olarak ayarlayabilir misin?
• "Beni hatırla" ile oturumu uzatıp jeton süresini kısa tutabilir misin?
• Hassas işlemler için yeniden kimlik doğrulama (ör. MFA) isteyip oturumu sonlandırmadan yapabilir misin?

Yenileme jetonu güvenliği#

• Jeton rotasyonu: IdP, her kullanımda yenileme jetonunu döndürüyor mu? (Dönmeli.)
• Şifreli depolama: Yenileme jetonları beklemede şifreli mi?
• İptal hassasiyeti: Tek bir cihazın oturumunu, tüm oturumları iptal etmeden kaldırabilir misin?
• Yapılandırılabilir süre: Farklı uygulamalar farklı yenileme jetonu ömürleri ister. Bunu uygulama bazında ayarlayabilir misin, yoksa küresel ayar mı?

Boyut 4: Yetkilendirme modeli — Temel RBAC'ın ötesinde#

Rollere Dayalı Erişim Kontrolü (RBAC) asgari gerekliliktir. Eğer IdP RBAC desteklemiyorsa değerlendirmeye değmez. B2B SaaS için ise RBAC tek başına yeterli değildir.

Organizasyona özgü izinler#

Kullanıcıların organizasyonlara aittir. Her organizasyon içindeki yetkileri — platform seviyesindekinden farklıdır.

Bir kullanıcı A Organizasyonunda yönetici, B Organizasyonunda izleyici olabilir. Aynı kullanıcı, iki farklı rol bağlamı. IdP bunu doğal olarak modelleyemiyorsa, uygulamada paralel bir yetki sistemi kurarsın — o zaman iki farklı gerçeklik yaratmış olursun.

Sorular:

• Rolleri kullanıcı seviyesinde değil, organizasyon seviyesinde tanımlayabilir misin?
• Bir kullanıcı farklı organizasyonlarda farklı rollere sahip olabilir mi?
• Geçerli organizasyon bağlamı jetonda gömülü, böylece API kullanıcının hangi organizasyonda olduğunu anlayabiliyor mu?

Çok seviyeli yetkilendirme (auth_level)#

Finansal uygulamalar, sağlık sektörü veya belirli işlemlerin daha yüksek risk taşıdığı tüm ürünler için: her kimlik doğrulamış oturum eşit değildir.

Bir gösterge panelini izlemek mi? Oturum çerezi yeter. Havale başlatmak mı? Kullanıcı zaten giriş yapmış olsa da taze MFA doğrulama gerekir.

Bu, "step-up" kimlik doğrulamadır ve jeton sisteminde kimlik doğrulama seviyesi (auth_level) kavramı birinci sınıf vatandaş olmalıdır.

Sorular:

• Jetonda backend'in kontrol edebileceği bir auth_level claim'i taşıyabilir mi?
• Uygulamadan step-up kimlik doğrulamayı tam yeniden oturum açtırmak zorunda kalmadan tetikleyebilir misin?
• auth_level'un kendi süresi var mı, oturumdan bağımsız olarak?

IdP bunu doğal olarak desteklemiyorsa, kendin kurmak zorunda kalacaksın — tam da IdP almakla kurtulmak istediğin kimlik mantığı!

Jeton tabanlı yetkilendirme kararları#

İdeal olan: API ara katmanı jetonu okur, kullanıcının organizasyonu, rolü, auth_level'ı görür ve dış bir servise gitmeden yetkilendirme kararı alır.

Çoğu IdP'de ise: jeton sana kullanıcının kim olduğunu söyler, izinlerini anlamak için ayrı bir API çağrısı gerekir.

Bu ayrı çağrı gecikme ekler, bağımlılık yaratır ve bir hata noktası oluşturur. Saniyede 1.000 istek varken, yetkilendirme kontrolünün ağ üzerinden gitmesini istemezsin.

Boyut 5: Geçiş — Her şeyi belirleyen kriter#

Kimsenin bahsetmek istemediği bir istatistik: Çoğu IdP değerlendirmesi, yeni IdP yetersiz olduğundan değil, ekip mevcut kullanıcılarını nasıl taşıyacağını bulamadığından sona erer.

100.000'den fazla kullanıcın varsa, geçiş bir "olsa iyi olur" değil — tüm projenin kendisidir.

Üç geçiş stratejisi (ve IdP'nin desteklemesi gerekenler)#

1. Mevcut parola hash'leriyle toplu aktarım

Kullanıcıların parolaları bcrypt, argon2 veya başka bir şeyle hash'lenmiştir. IdP bunları doğrudan içe aktarabilir ve bunlara göre parola doğrulaması yapabilir mi?

EVETSE: Kullanıcılar mevcut şifreleriyle giriş yapar, hiçbir şey değişmez. En iyi senaryo.

HAYIRSA: Her kullanıcıya "şifreni sıfırla" e-postası gönderilir. Kullanıcı tabanının %30-50'sini geçişte kaybedersin. Teorik değil — yaşanmış bir durum.

2. Aşamalı (tembel) geçiş

Tüm kullanıcıları bir kerede geçirmek yerine, giriş yaptıkça tek tek geçirirsin. İlk giriş eski sistemden parola doğrularken, yeni IdP'de kullanıcıyı yaratır. Sonraki tüm girişler doğrudan yeniye gider.

Büyük kullanıcı tabanları için en güvenli yaklaşımdır, ama IdP'nin bunu desteklemesi gerekir:

• Eski sistemine çağrı yapan özel bir kimlik doğrulama kancası
• Giriş sırasında anında kullanıcı oluşturabilme
• Kimlerin geçirildiğinin takibi

3. Çift yazma (sistemleri paralel çalıştırma)

Geçiş sürecinde hem eski hem yeni kimlik sistemleri aktif olur. Yazmalar ikisine de, okumalar giderek yeniye kaydırılır. Geriye dönüş yolu sağlar ama operasyonda karmaşıklık getirir.

Geçişte kırmızı bayraklar#

• "CSV ile içe aktarım destekliyoruz" — Bu sadece profil aktarım, parola değil. Yine şifre sıfırlama gerekecek.
• "Geçiş rehberimiz var" — Dikkatli oku. "Kullanıcılar yeni parola ayarlamak zorunda" diyorsa, %30-50 kullanıcı kaybı yaşarsın.
• Hash uyumluluğundan hiç bahsedilmemiş — Satıcı parola hash geçişini düşünmemişse, ölçeğinde ekiplerle çalışmamıştır.

Sorulacak sorular#

• Hangi parola hash algoritmalarında içe aktarımı destekliyorsunuz? (bcrypt, argon2, scrypt, PBKDF2, özel?)
• Girişte kullanıcıları adım adım geçirmek (progressive migration) mümkün mü?
• Geçiş ilerlemesi takip edilebiliyor mu — yüzde kaç kullanıcı geçirildi?
• Geçiş ters giderse geri dönüş stratejisi ne?
• Oturum devamlılığı sağlanabilir mi — geçiş sırasında kullanıcılar oturumdan atılmaz mı?

Satıcı bu soruları kendinden emin yanıtlayamıyorsa, daha önce yapmamış demektir. Devam et.

Boyut 6: Çok kiracılı yapı — Doğal mı, sonradan mı eklenmiş?#

B2B SaaS, çok kiracılı yapı demektir. Müşterileriniz; kullanıcıları, rolleri ve erişim politikaları olan organizasyonlardır. IdP bunun doğrudan farkında olmalıdır.

"Doğal çok kiracılı yapı" ne anlama gelir#

• Organizasyon birinci sınıf varlık: Kullanıcı profilinde özel bir alan değil, kendi ID'si, ayarları ve üye listesi olan düzgün bir veri modeli.
• Kuruluşa özgü kimlik doğrulama politikaları: A Organizasyonu kurumsal IdP'si ile SAML SSO kullanır, B Organizasyonu e-posta/şifre ile zorunlu MFA kullanır. C Organizasyonu Google Workspace ile girer. Hepsi UI veya API üzerinden — kod yazmadan.
• Kuruluşa davet ve üyelik yönetimi: Her organizasyondaki yöneticiler kullanıcı davet edebilir, rol atayabilir, üyeleri kaldırabilir. Davet, e-posta doğrulama ve rol atamasını IdP yönetir.
• Organizasyon-bağlı jetonlar: Kullanıcı bir organizasyon dahilinde işlem yapıyorsa, jeton organizasyon bilgisi taşır. API hangi organizasyonun verisinin döneceğini bilir.

"Özel metadata" geçici çözümü#

Bazı IdP'ler doğal organizasyon modeli sunmaz. Bunun yerine, özel kullanıcı meta verisi (user.app_metadata.org_id = "123") ile geçirici bir çözüm önerir.

Bu çok hızlı bozulur:

• Birden fazla organizasyona üye kullanıcılar için meta veride dizi yönetimi gerekir
• Davet ya da üyelik akışı yoktur
• Organizasyon başına özel kimlik doğrulama politikası yoktur
• Organizasyon-bağlı jeton yok — bağlam başka sinyallerden çıkarılmak zorunda
• Denetim log'larında organizasyon görülmez

Satıcı "organizasyonları metadata alanlarımızla modelleyebilirsiniz" diyorsa, bu ilişkisel verinin JSON kolonunda saklanması gibidir. İşler ta ki işlemez hale gelene kadar çalışır.

Sorulacak sorular#

• Organizasyon modeli doğal mı, kullanıcı meta verisi üzerine mi kurulu?
• Kullanıcılar aynı anda birden fazla organizasyona üye olabilir mi?
• Her organizasyon için farklı kimlik doğrulama gereksinimleri ayarlayabiliyor muyuz?
• Organizasyon-bağlı roller ve izinler doğal olarak destekleniyor mu?
• Organizasyon yöneticileri üyeleri self-servis UI ile yönetebiliyor mu?
• Jeton organizasyon bağlamı içeriyor mu?

Boyut 7: Yapay zeka uyumluluğu — Henüz kimsenin sormadığı kriter#

On iki ay önce, "AI ajan kimlik doğrulaması" hiçbir değerlendirme listesinde değildi. Bugün, ürünü AI özellikleri ile geliştiriyorsan — yardımcılar, otonom ajanlar, AI ile otomasyon — IdP'nin yeni bir kimlik türünü işlemesi gerekir: ajan.

Neden ajanlar geleneksel modeli bozar?#

Geleneksel kimlik doğrulamada iki aktör vardı: kullanıcı ve uygulama. OAuth2 bunun etrafında tasarlandı.

AI ajanları üçüncüyü ekler: belirli bir kullanıcı adına, kısıtlı izin ve kendi denetim iziyle hareket eden, insan olmayan varlık.

• Bir ajan kullanıcı değildir — şifresi veya tarayıcı oturumu yoktur
• Bir ajan makine-makine servisi değildir — belirli bir kullanıcı adına hareket eder
• Bir ajan sınırlandırılmış, zaman kısıtlı izinlere ihtiyaç duyar — kullanıcının tüm erişimi değil

IdP'nin desteklemesi gerekenler#

Jeton Değişimi (RFC 8693): Ajan kendi kimliği artı kullanıcının yetkisini sunar, IdP kapsamlı bir token verir. Jeton şunları taşır: kim (kullanıcı), ne (ajan), kapsam (izin sınırı), ne zaman (süre).

Ajan bir istemci türü olarak: Ajan düzgün bir OAuth2 istemcisi (client_id) olarak modellenmeli, API anahtarı ya da paylaşılan kullanıcı jetonuyla geçici çözüm değil.

Delege kapsam yönetimi: Kullanıcı, ajana belirli izinler verebilmeli — okuma ama yazma yok, belirli kaynaklara erişim, diğerlerine değil.

Denetim ayrımı: Kayıtlarınızda "kullanıcı X yaptı" ile "ajan, kullanıcı adına X yaptı" ayrımı olmalı. Bunu ayırt edemiyorsan, bir sonraki SOC2 denetiminde "bu değişikliği kim yaptı?" sorusunda kalırsın.

MCP (Model Context Protocol) uyumluluğu#

MCP, AI ajanlarının hizmetlerle protokol tabanlı kimlik doğrulamayla iletişimi için standart halini alıyor. IdP'nin MCP sunucuları için OAuth tabanlı kimlik doğrulama desteği varsa, ajanlar doğru şekilde protokol katmanında kimlik doğrulaması başlatabilir, API anahtarı ya da paylaşılan sır ile değil.

Sorulacak sorular#

• OAuth2 Jeton Değişimi desteğiniz var mı?
• Ajanlar ayrı istemci türü olarak modellenebiliyor mu?
• Jetonlar delege bilgisi taşıyor mu (ajanı kim yetkilendirdi, kapsam ne)?
• Denetim log'ları, ajan ve insan işlemlerini ayırıyor mu?
• Ajan-araç kimlik doğrulaması için MCP sunucu entegrasyonu veya OAuth desteği var mı?

Satıcı bu konuları hiç düşünmemişse, onlar 2020'ye, sen ise 2026'ya hazırlanıyorsun.

Boyut 8: Fonksiyonel olmayan gereksinimler — Geceleri uykunu kaçıranlar#

Özellikler satış sağlar. Operasyonlar ise yenilemene sebep olur.

Performans#

• Kimlik doğrulama kapasitesi: Sistem zirvede 100+ kimlik doğrulama isteğini kaldırabilir mi? 1.000+ ne olacak?
• Jeton doğrulama gecikmesi: Servislerin JWT'leri yerelde doğruluyorsa (öyle olmalı), bu mikrosaniyelerde olur. Ama IdP introspection çağrısı gerektiriyorsa, P99 gecikmesi nedir?
• Ölçek tavanı: Maksimum aylık aktif kullanıcı (MAU) nedir? Hedeflediğin ölçekte referans var mı?

Uyumluluk#

• SOC2 Tip II: Tip I değil. Tip II, bir süre boyunca denetlenmiş olmak demektir. Yalnızca Tip I varsa, Tip II ne zaman beklenmeli diye sorun.
• Denetim log'ları: Her kimlik doğrulama olayı, izin değişimi ve yönetici işlemi kaydedilmeli. SIEM ile logları dışa aktarabiliyor musun? Loglar değiştirilemez mi?
• Veri bölgeliliği: Kullanıcı verisinin hangi bölgede tutulacağı ayarlanabiliyor mu? AB müşterileri için bu zorunludur.

Güvenilirlik#

• Çalışma süresi SLA'sı: %99,9 iyi görünüyor olabilir, fakat yılda 8,7 saat kesinti demek. %99,99 ise 52 dakika. Kimlik doğrulama — uygulamanın ana kapısı — için bu fark önemlidir.
• Failover: Sağlayıcı kesintisinde ne olur? Yedek mekanizma var mı? Çoklu bölge dağıtımı?
• Olay geçmişi: Statü sayfalarında geçmişe bak. Sözde değil, gerçekten ne olmuş?

Veri taşınabilirliği#

• Kullanıcı dışa aktarımı: Tüm kullanıcı verisini, meta datayı, organizasyon üyelikleri ve rolleriyle dışa aktarabilir misin? Hangi formatta?
• Standartlara uygunluk: Farklı bir sağlayıcıya geçişi kolaylaştıran standart protokolleri (OIDC, SCIM) kullanıyorlar mı?
• Bağımlılık sinyalleri yok: Özelleşmiş API'ler, özel protokoller, standart dışı token formatları — bunlar kilitlenme göstergeleridir. Entegre ne kadar özelse, ayrılmak o kadar zordur.

Değerlendirme matrisi: Pratik bir puanlama çerçevesi#

Tüm boyutlarda değerlendirdikten sonra karşılaştırmak için yönteme ihtiyacın var. İşte öncelik çerçevesi:

P1 — Sonuç belirleyiciler (geçmezse elenir)#

P2 — Şiddetle tercih edilen (eksikse yüksek mühendislik maliyeti)#

P3 — Önemli (12 ay içinde planlanmalı)#

P4 — Olursa iyi (kararı engellemez)#

Nasıl Kullanılır: Önce P1 ile başla. Bir satıcı herhangi bir P1 kriterini karşılamazsa, değerlendirmeyi bırak. Sonra P2 ve P3 kategorilerini puanla. En iyi P2+P3 toplamına sahip satıcı cevabın olur.

Yaygın değerlendirme hataları#

Takımların tekrar tekrar aynı hataları yaptığını gördük. Nasıl önüne geçeceğin burada:

Hata 1: Özelliklere, mimariye bakmadan değerlendirme#

Özellik karşılaştırma tablosu neyin var olduğunu söyler. Nasıl inşa edildiğini göstermez. Bir IdP, organizasyon desteği kutusunu user metadata'da org ID tutarak işaretleyebilir. Tabloyu doldurur ama üretimde sorun çıkarır.

Çözüm: Her özelliğe "nasıl uygulandı?" diye sor — sadece "var mı?" değil.

Hata 2: Geçişi seçimden sonraya bırakmak#

Takımlar en "iyi" IdP'yi seçer, uygulamaya başlar, sonra kullanıcılarını şifresiz taşıyamadıklarını fark ederler. Ya kötü bir geçişle devam ya da başa dönmek zorunda kalırlar.

Çözüm: Geçiş yeteneğini ilk filtre yap, sonuncu değil.

Hata 3: Sadece tanıtıma fazla odaklanmak#

Her satıcı demolarını cilalar. Tertemiz veritabanı ile sorunsuz senaryolar gösterir. Üretimde ise birleştirilmiş hesaplar, profilde tuhaf unicode karakterler, olmaması gereken oturumlar vardır.

Çözüm: Gerçek verinle bir kavramsal ispat iste. 1.000 gerçek kullanıcıyı aktar, gerçek akışlarını koş.

Hata 4: Doğru kişileri dahil etmemek#

Sadece platform ekibi değerlendirirse, teknik olarak en temiz olanı seçer. Sadece ürün değerlendirirse, entegresi en kolay olanı seçer. Sadece güvenlik değerlendirirse, en çok uyum kutusu olanı seçer.

Çözüm: Değerlendirme ekibinde platform mühendisliği, ürün ve güvenlik olmalı. Her biri farklı P1/P2 kriterini sahiplenir.

Hata 5: Bir gün ayrılmanın gerekeceğini unutmak#

Satıcıya bağımlılık gerçektir. Özelleşmiş SDK'lar, özel API'ler, standart dışı token formatları — bunlar geçişi ileride zorlaştırır.

Çözüm: Standart (OIDC, OAuth2, SCIM) protokolleri kullanan IdP'leri tercih et. Gelecekte kendine dua edeceksin.

SSS#

Bir IdP değerlendirmesi genellikle ne kadar sürer?#

Kavramsal ispat testlerini de içeren kapsamlı bir değerlendirme için 4-8 hafta ayırmalısınız. Acele etmek yukarıda saydığımız hatalara — özellikle de geçiş göz ardı edilmesine — neden olur. 2 hafta gereksinim toplama, 2-3 hafta satıcı değerlendirmesi ve PoC, 1-2 hafta paydaşlarla uyum için ayırın.

Kendi kimlik servisimiz/kimlik doğrulamamız neden olmasın?#

Aşamadaki durumuna bağlı. 10.000'den az kullanıcılı ve kurumsal müşterin yoksa hafif bir kimlik kütüphanesi yetebilir. Ama SSO, çok kiracılı yapı, MFA, uyumluluk gereği doğunca, ev yapımı kimlik sisteminin bakımı IdP ücretini fersah fersah geçer. Mühendislik ekiplerinin kendi kimlik sistemini bakmak için 2-3 tam zamanlı mühendis harcadığını gördük — fırsat maliyeti yılda 300-500 bin dolar.

CIAM ile işyeri IAM farkı ne?#

Müşteri Kimlik ve Erişim Yönetimi (CIAM) ürününün son kullanıcılarının gördüğü şeydir — kayıt, giriş, profil yönetimi. İşyeri IAM ise, çalışanlarının dahili araçlara erişimi için kullanılır (şirket Slack'in için Okta, Google Workspace vb.). Farklı satın alma kararları, farklı değerlendirme kriterleri vardır. Bu rehber CIAM içindir.

Açık kaynak mı, sahipli mi daha önemli?#

Açık kaynak IdP'ler şeffaflık (kodu denetleyebilirsin), taşınabilirlik (gerekirse kendin barındırırsın) ve topluluk katkısı sunar. Sahipli IdP'ler daha cilalı arayüz ve yönetilen hizmetlerle gelir. Burada asıl soru "açık vs. kapalı" değil — "gerekirse ayrılabilir miyim?" Açık kaynak çözümler, veri modeli ve API'ler kamusal olduğu için ayrılmayı kolaylaştırır.

AI ajan kimlik doğrulaması ne zaman P1, ne zaman P3 olmalı?#

AI özelliklerin zaten kullanıcı adına veri erişimi (yardımcılar, otomasyon, AI asistanlar) için varsa, P1'e al. AI özellikleri 6-12 ay içinde yol haritanda ise, P3'te bırak ama ağırlığını arttır. AI şimdilik gündeminde yoksa P4'te kalabilir — 6 ay sonra tekrar değerlendir.

Satıcılar farklı modeller kullandığında fiyatlandırmayı nasıl karşılaştırmalı?#

Çoğu IdP aylık aktif kullanıcı (MAU) bazında fiyatlar. Ama "MAU" tanımı değişir — bazıları her oturumu, bazıları benzersiz kullanıcıyı, bazıları M2M jetonları ayrı sayar. Satıcıdan kendi senaryon için teklif iste: X kullanıcı, Y organizasyon, Z M2M bağlantısı, beklediğin kimlik doğrulama hacmiyle. Birim fiyat değil, toplam maliyeti karşılaştır.

Sonuç#

Kimlik sağlayıcı seçimi, altyapı kararıdır; özellik kararı değil. Ürününe gelen her kullanıcının ilk etkileşimini, API'ndeki her izin kontrolünü, her uyumluluk denetim kaydını bu sisteme emanet ediyorsun.

Yukarıdaki değerlendirme çerçevesi gerçekten önemli olanları ele alır — pazarlama maddelerini değil. Adayları hızlı filtrele (önce P1!), derin değerlendir (P2 ve P3 kriterleriyle, kavramsal ispat testleriyle), yıllarca dayanacak karar ver.

Bunu doğru yapan ekiplerin ortak noktası: kimliği bir altyapı gibi yönetmek; çıkarılacak bir özellik gibi değil.