## Arka Plan Logto'yu inşa etmeye başladım çünkü Kimlik ve Erişim Yönetimi (IAM) zamanla giderek daha karmaşık ve geniş hale geldiğini fark ettim. IAM kavramı, WIAM (İş Gücü IAM) ve CIAM (Müşteri IAM) gibi yeni kavramlara yol açacak kadar geniş. WIAM ve CIAM aynı temeli paylaşırken farklı kullanım alanlarına sahiptirler: WIAM genellikle iç kullanıcılar için kullanılırken, CIAM dış müşteriler için kullanılır. Bazı örnekler: - **WIAM** Şirketiniz, çalışanlar için birleşik bir kimlik sistemine sahiptir, bu nedenle herkes aynı hesabı kullanarak şirket kaynaklarına, yazılım abonelikleri, bulut bilişim hizmetleri gibi erişebilir. - **CIAM** Çevrimiçi kitapçınız, müşteriler ve satıcılar için bir kullanıcı kimlik sistemine ihtiyaç duyar. Giriş deneyimi, dönüşüm hunisinin başında yer aldığı için işe alımın kritik bir parçasıdır. Logto, çeşitli nedenlerle CIAM ile başladı (bu konuda başka bir makalemiz olacak). Geliştirme sırasında, ürünümüzü bir sonraki seviyeye taşımadan önce ekip arasında birleşik bir anlayış oluşturmanın faydalı olacağını fark ettik. Umarız bu, IAM dünyasını daha iyi kavramanıza da yardımcı olur. Hadi başlayalım! ## CIAM'in Temelleri WIAM ve CIAM'in farklarına rağmen, her ikisinin de aynı temeli vardır: kimlik doğrulama ve izin verme. Bu iki kavram, özelliklerinin çekirdeğini oluşturur. Bu makalede, CIAM'in temel kavramlarına ve kimlik doğrulama akışı sırasında veya sonrasında karşılaşabileceğimiz sorunlara odaklanacağız. Ayrıca tek oturum açma (SSO) ve onunla ilgili senaryoları da tartışacağız. ### Kimlik Doğrulama ve İzin Verme - Kimlik Doğrulama (AuthN) “Hangi kimliğe sahipsiniz?” sorusunu yanıtlar - İzin Verme (AuthZ) “Ne yapabilirsiniz?” sorusunu yanıtlar > 💡 Kimlik doğrulama başlangıçta "Kimsin sen?" olarak tanımlanır. Ancak, dijital kimlikleri tartışırken, kimlik doğrulamayı "kimliğin sahipliğini kanıtlamak" olarak göstermek daha doğrudur. ([Calm-Card-2424](https://www.reddit.com/r/programming/comments/10uycg0/comment/j7eyhrb/) 'ya teşekkürler) Eğer bu iki kategoriden birine uymayan bir şey keşfederseniz, kimlik işinde muhtemelen gerekli değildir. - **Kimlik doğrulama için örnekler** - Şifre ile oturum açma, şifresiz oturum açma, sosyal giriş vb. - Makineden makineye kimlik doğrulama - **İzin verme için örnekler** - Rol Tabanlı Erişim Kontrolü - Öznitelik Tabanlı Erişim Kontrolü - **İstisnalar için örnekler** - Kimlik dışı veriler - Web kancaları ### Kimlik ve Kiracı Kimlik genellikle bir kullanıcıyı veya bir makineyi temsil eder. Başarılı bir kimlik doğrulama sonrasında, bir Kimlik Belirteci kimlik olarak verilir. Başka bir deyişle, kimlik doğrulamanın ana amacı bir Kimlik elde etmektir. Bir Kiracı, kimlikler grubudur: ```mermaid graph TD Tenant --- A[Kimlik: Kullanıcı 1] Tenant --- B[Kimlik: Kullanıcı 2] Tenant --- C[Kimlik: Makine 1] ``` "Çok kiracılı"ndan bahsettiğimizde, birbirinden kimlik yalıtımlı birden fazla Logto örneğine atıfta bulunuyoruz. Diğer bir deyişle, birden fazla Logto örneği. ```mermaid graph TD T1[Kiracı 1] --- A[Kimlik: Kullanıcı 1] T2[Kiracı 2] --- B[Kimlik: Kullanıcı 1] T2[Kiracı 2] --- C[Kimlik: Makine 1] subgraph IS2[Kimlik sistemi 2] T2 B C end subgraph IS1[Kimlik sistemi 1] T1 A end ``` Not olarak, iki **yalıtılmış** kimlik sistemi vardır, yani aynı tanımlayıcıyı (e-posta, telefon vb.) kullanarak bile Kiracı 1'in Kimliği'ni Kiracı 2'de kullanamazsınız. Tıpkı Costco üyeliğinizin Whole Foods'ta geçerli olmaması gibi. 🧱 Kısacası, Kiracılar arasında "fiziksel duvarlar" vardır. "Kiracı" tanımı, CIAM ürünleri arasında farklılık gösterir. Bazıları Logto'da "Organizasyon" terimiyle atıfta bulunur, ki bu daha sonra tanıtılacaktır. ### Uygulama ve Kiracı Kimlik gibi, bir Uygulama da bir Kiraca aittir. Hatırlanması gereken birkaç şey: - Genellikle bir Uygulama ile Bir Kimlik arasında doğrudan bir ilişki yoktur. - Bir Kimlik bir Uygulamayı temsil edebilir, ancak aralarında doğrudan bir bağlantı yoktur. - Kullanıcılar gibi uygulamalar da Kiracı seviyesinde bulunurlar. - Uygulamalar kod iken kullanıcılar insandır. - Uygulamaların tek amacı kimlik doğrulamasını tamamlamak, yani bir Kimlik elde etmektir. ### Kimlik Sağlayıcı (IdP) ve Servis Sağlayıcı (SP) Bu iki sağlayıcı arasındaki fark karmaşık ama önemlidir. - **Kimlik Sağlayıcı**, kimlik doğrulama (AuthN) sağlayan ve kimlikler veren bir hizmettir. Bu konuda Google'dan çeşitli açıklamalar bulabilirsiniz, ancak tatmin edici olmayabilirler. Beni önemsemeyebilir Service Sağlayıcı'nın nispi bir kavram olduğuna düşündüğümde: - **Servis Sağlayıcı (veya [OIDC](https://openid.net/specs/openid-connect-core-1_0.html)'de Güvenen Taraf)**, kimlik doğrulama (AuthN) başlatan ve kimlik sağlayıcılardan sonucun talebini yapan bir hizmet veya klienttir. #### Anket Tipik bir sosyal oturum açma senaryosunu düşünün: ```mermaid graph LR A[iOS Uygulaması] --> |Oturum açmayı başlat| Logto --> |Yönlendir| GitHub GitHub --> |GitHub Kimliğini Döndür| Logto --> |Logto Kimliğini Döndür| A ``` **❓ Bu grafikte kaç Servis Sağlayıcı ve Kimlik Sağlayıcı bulunmaktadır?**

Cevap

Her ikisi de ikiye sahip. iOS Uygulaması Logto'ya karşı bir servis sağlayıcıdır, Logto ise bir kimlik sağlayıcıdır. Logto, GitHub'a karşı hem servis sağlayıcı hem kimlik sağlayıcıdır.

## Vaka Çalışması: Bir Teknoloji Çözüm Şirketi Bir teknoloji çözüm şirketinin CTO'susunuz, 100'den fazla iş ortağınız ve 300'den fazla projeniz var. - Her proje, bir web uygulaması veya bir arka uç hizmete sahip bir mobil uygulama. - Her iş ortağı için kullanıcı sistemini yeniden düzenlemek ve projeleri arasında SSO sağlamak istiyorsunuz. **❓ Logto (veya bir CIAM ürünü) size nasıl yardımcı olabilir?**

Cevap

Her iş ortağı için bir Logto örneği oluşturun. Her ortağın bir Kiracı vardır. Projeler, Logto'da "Uygulamalar"a eşlenir. ```mermaid graph TD T1[Kiracı 1] --- A[Uygulama 1] T1 --- B[Uygulama 2] T1 --- C[Uygulama 3] T1 --- U1[Kullanıcı 1] T1 --- U2[Kullanıcı 2] T2[Kiracı 2] --- D[Uygulama 1] T2 --- E[Uygulama 2] T2 --- U21[Kullanıcı 1] T2 --- U22[Kullanıcı 2] ``` Logto, Kiracı içinde evrensel bir giriş deneyimi (yani SSO) sunuyor, bu nedenle kullanıcılar, aynı Kiracıda başka bir uygulamaya erişirken tekrar oturum açmalarına gerek kalmaz.

## SSO'dan Bahsettiğimizde Ne Söyleriz “SSO” teriminin genellikle kafa karışıklığına neden olduğunu bulduk. Biz, tek oturum açmayı (SSO) bir davranış olarak görüyoruz, bir iş konsepti olarak değil. Bu nedenle, SSO “WIAM'deki SSO” ile eşdeğer değildir. SSO'ya ihtiyaç var dediğimizde, aşağıdaki durumlardan birine işaret edebilir: ### SSO Durumu 1 > 👉🏽 Büyük bir şirkette, çalışanlar tüm şirket lisanslı kaynaklarına (örneğin e-posta, İM, bulut hizmetleri) aynı kimlik bilgileriyle giriş yaparlar. Bu tipik bir WIAM senaryosu. Bu durumda, yalnızca bir Kimlik Sağlayıcı bulunur. Şimdilik ilgilenmiyoruz. ### SSO Durumu 2 > 👉🏽 Son kullanıcılar, aynı şirket tarafından geliştirilen tüm hizmetlere aynı kimlik bilgileriyle giriş yaparlar (örneğin GSuite). Logto şu anda yukarıda ana hatları belirtilen yaklaşıma odaklanıyor. Bir üçüncü parti sosyal oturum açma sağlayıcı gibi birden fazla dış kimlik sağlayıcısı bağımsız olarak ve bağlantısız bir şekilde var olabilir. Buna rağmen, Logto Kimlikler için tek doğru kaynak olmaya devam eder, onları yalnızca diğer sağlayıcılardan "ödünç alır". Bu durumda, Logto hem bir Kimlik Sağlayıcı (GSuite uygulamalarına) hem de bir Servis Sağlayıcı (dış Kimlik Sağlayıcılara) olarak hizmet eder. ### SSO Durumu 3 > 👉🏽 Son kullanıcılar, kimlik doğrulamasını tamamlamak için yalnızca belirli e-posta alanı içinde belirli Kimlik Sağlayıcısını kullanabilirler. Örneğin, Google Workspace ile Figma'ya oturum açma. Bu, CIAM'de SSO için en yaygın kullanım durumudur. Daha yakından bakalım. @silverhand.io e-posta adresimizi kullanarak Figma'ya oturum açmak istiyorsak, Sosyal oturum açma veya SSO kullanabiliriz. Aşağıdaki şekiller iki yöntemin farkını göstermektedir:

Sözcüklerle: - Sosyal oturum açma sonrasında, kullanıcılar Figma'da bir şifre ayarlama veya e-posta adresini değiştirme özgürlüğüne sahiptir - SSO sonrasında, kullanıcılar şifre ayarlayamaz veya e-posta adresi dahil olmak üzere kişisel bilgileri değiştiremez, çünkü kimlikleri Google Workspace tarafından yönetilir Bu durumda, Logto hem bir Kimlik Sağlayıcı hem bir Servis Sağlayıcıdır. Görünüşe göre SSO, normal bir oturum açma sürecinden daha karmaşıktır. Kimlik sahibine olan faydaları nelerdir? - **Merkezi Kontrol:** Kimlik bilgilerini ve kimlik doğrulama süreçlerini tek bir yerde tutmak ve kullanıcı bilgilerinin her zaman güncel olmasını sağlamak. Değişiklikler için farklı uygulamalarda lisans eklemeye ve kaldırmaya gerek yoktur. - **Gelişmiş Kullanıcı Deneyimi:** SSO gerektiren kimlik sahipleri genellikle kurumsal kuruluşlardır. Çalışanları, Figma, Zoom, Slack vb. gibi şirketler arası uygulamalar için aynı kimlik bilgilerini ve paylaşılan oturumları kullanabilirler. - **Geliştirilmiş Güvenlik:** Bazı kuruluşların, dinamik doğrulama kodları gibi belirli oturum açma yöntemlerini zorunlu kıldığını fark etmiş olabilirsiniz. SSO'nun kullanımı, tüm kaynaklara erişim için her çalışan tarafından kullanılan aynı oturum açma yöntem kombinasyonunu garantileyebilir. > 🤔 Siz gibi zeki biri, bunun aslında **SSO Durumu 1** olduğunun farkındasınızdır. SaaS perspektifinden. SSO grafiğindeki "X"i tartışma zamanı geldi. Bu Figma'nın e-posta alanını belirli bir Kimlik Sağlayıcıyla bağlama sürecini temsil eder. Ama, nasıl çalışır? ## SSO Haritalama Talep genellikle kurumsal müşterilerden geldiği için, önceki bölümdeki "SSO Durumu 3" sürecine "Kurumsal SSO" olarak başvuruyoruz. Naif bir çözüm tasarlayabiliriz: e-posta alanları ve SSO yöntemleri arasında bir haritalama oluşturun, ardından manuel olarak güncelleyin. "X" işleminin eylemi şimdi net: > 🔍 **Belirtilen e-posta alanının eşlenmiş Kurumsal SSO yöntemini bulun** Bu nedenle, belirli bir Google Workspace SSO URL'si ile bağlanan geçerli bir e-posta alanı olarak `silverhand.io`yu ayarlarsanız, `@silverhand.io` e-postayla oturum açmayı deneyen kullanıcılar, içeriği yerinde işlemek yerine ilgili Google Workspace oturum açma sayfasına yönlendirilir. Yalnızca birkaç düzine işletme SSO istemcisi olduğunda, haritayı elle yönetmek iyi olabilir. Ancak dikkate almanız gereken daha fazla şey var: 1. _Yüzlerce veya binlerce Kurumsal SSO müşterisi varsa ne olur?_ 2. _"Normal kullanıcılar" ve "Kurumsal SSO kullanıcıları" arasındaki ilişki nedir?_ 3. _Farklı Kurumsal SSO müşterileri arasında veriler izole edilmeli mi?_ 4. _Kurumsal SSO yöneticilerinin aktif kullanıcıları, denetim günlüklerini vb. görmek için bir gösterge tablosu sağlanmalı mı?_ 5. _Bir Kurumsal SSO Kimlik Sağlayıcısından bir kullanıcı kaldırıldığında hesaplar otomatik olarak nasıl devre dışı bırakılabilir?_ Ve daha birçoğu. Hemen hemen tüm Kurumsal SSO e-posta alanına dayalı olduğundan, hızlı bir şekilde daha iyi bir çözüm bulabiliriz: - Kullanıcı, o alanın mülkiyetini kanıtlayabiliyorsa, o alanın kurumsal SSO'sunu kendi kendine hizmet olarak ayarlayabilir. Bu çözüm ilk iki soruyu ele alıyor: > _1. Yüzlerce veya binlerce Kurumsal SSO müşterisi varsa ne olur?_ - Kurumsal SSO'yu kendi kendine hizmet olarak yapılandırabilirler. > _2. "Normal kullanıcılar" ve "Kurumsal SSO kullanıcıları" arasındaki ilişki nedir?_ - Tüm normal kullanıcılar için tüm olası oturum açma yöntemlerini açarız; Kurumsal SSO kullanıcılarına ise yalnızca yapılandırılmış alanlarla oturum açma yöntemini sınırlandırırız. Üçüncü soruya gelince: > _3. Farklı Kurumsal SSO müşterileri arasında verileri izole etmeli miyim?_ - Evet ve hayır. Organizasyonu tanıtma zamanı. ## Organizasyon Belirtilen Kurumsal SSO yöntemini kullanacak belirli e-posta alanlarını tanımak için e-posta alanlarının kullanılmasını belirtmiştik; başka bir deyişle, belirli bir kullanıcı grubu için belirli bir muamele uygulanması. Bununla birlikte, müşteri gereksinimleri genellikle yalnızca Kurumsal SSO'dan fazlasıdır; örneğin, önceki bölümdeki soru 4 ve 5. Yıllar içinde, bu tür sorunları ele almak için olağanüstü SaaS şirketleri tarafından olgun bir model geliştirilmiştir: Organizasyonlar. **Organizasyonların Kuralları** 1. Bir organizasyon, kimliklerin bir grubudur, genellikle bir Kiracıdan daha küçüktür. 2. Tüm organizasyonlar bir Kiracı ile ilişkilidir. Yazılımda "Çalışma Alanı", "Takım" veya hatta "Kiracı" gibi diğer terimleri görebilirsiniz. Tartıştığımız konsept olup olmadığını belirlemek için, "kimlikler grubunu" temsil edip etmediğini kontrol edin. Bu makalede, tutarlılık sağlamak için "Organizasyon" terimini kullanacağız. 🤹🏽‍♀️ Çoğu durumda "kimlikler grubu", "kullanıcılar grubu" ile eşdeğerdir. Ancak, **aynı Kimlik birden fazla Organizasyonda var olabilir**. Notion'da, aynı e-posta adresiyle birden çok çalışma alanı (yani Organizasyon) oluşturabilir ve katılabilir ve bunlar arasında kolayca geçiş yapabilirsiniz. Slack için de aynısı geçerli gibi görünüyor, ancak her çalışma alanı için yeni bir hesap oluşturduğumuz için arka planda farklı Kimlikler kullandığını düşünüyoruz.

![Slack çalışma alanları](https://uploads.strapi.logto.io/1/slack_workspaces_b4f0bcc978.png) _Slack çalışma alanları_ ![Notion çalışma alanları](https://uploads.strapi.logto.io/1/notion_workspaces_5bdc2b7e9b.png) _Notion çalışma alanları_

Notion'da bir “Kişisel Plan” mevcuttur, bu genellikle kılıf altında bir Organizasyon, içinde sadece siz olan tek kullanıcıyla. Notion'un kesin uygulamasını bilmiyoruz, ancak bu açıklama modelimiz için makul ve arşivlenebilir. Her Organizasyon'un ayrıca bir tanımlayıcısı vardır, genellikle "Organizasyon alanı" olarak adlandırılır. Bir "Organizasyon alanı", Organizasyonları ayırt etmek için kullanılan dahili bir tanımlayıcıdır. "e-posta alanı"nın tanımlayıcısından farklı olabilir, zira ilki Servis Sağlayıcı tarafından yönetilirken, ikincisi genellikle dış bir Kimlik Sağlayıcı tarafından sağlanır. Örneğin, Slack'te Organizasyon alanı olarak `foo`yu kullanabilirsiniz, ancak bu Organizasyon için e-posta alanı olarak `@bar.io`yu kullanabilirsiniz. ### Anket **❓ Bir uygulama bir Organizasyonla ilişkilendirilebilir mi?**

Cevap

Evet evet. Başlangıçta tartıştığımız gibi, bir uygulama bir Kimliğe sahip olabilir. Bunu açıklayan bir iş senaryosu sağlayabilir misiniz?

## Kalan Sorular > _3. Farklı Kurumsal SSO müşterileri arasında veriler izole edilmeli mi?_ - **Evet:** İş mesajları ve belgeleri gibi iş verilerini Organizasyon düzeyine kadar izole etmek. - **Hayır:** Kimlikleri bağımsız tutmak, çünkü bir Organizasyon ile ilişkilendirilmelerine gerek yoktur. - Dikkat çekici bir şekilde karmaşıklığı artıran üç farklı öne çıkan var: Kimlikler, Organizasyonlar ve Kurumsal SSO yapılandırmaları; bu soru kendisi yeterince spesifik değil. > _4. Kurumsal SSO yöneticilerinin aktif kullanıcıları, denetim günlüklerini vb. görmek için bir gösterge tablosu sağlanmalı mı?_ > > _5. Bir Kurumsal SSO Kimlik Sağlayıcısından bir kullanıcı kaldırıldığında hesaplar otomatik olarak nasıl devre dışı bırakılabilir?_ - Bu talepler daha iş odaklıdır ve Organizasyon düzeyinde uygulanabilir. Burada açık bırakalım. ## Kapanış Notları Çeşitli kavramları tanıttık: Kimlik Doğrulama (AuthN), İzin Verme (AuthZ), Kimlik, Kiracı, Uygulama, Kimlik Sağlayıcı (IdP), Servis Sağlayıcı (SP), Tek oturum açma (SSO) ve Kurumsal SSO (Organizasyon). Hepsini anlamak biraz zaman alabilir. Bu makaleyi yazarken fark ettim ki, ilginç bir şekilde, çevrimiçi hizmetlerin en pahalı planları genellikle izin verme ile ilgili özel özellikler içeriyor, bu makalede tamamen bahsedilmemiş olan. İzin verme hakkında bazı sorularınız olabilir, örneğin: - Bir kullanıcıya izinleri nasıl atayabiliriz ve bunları nasıl doğrulayabiliriz? - Hangi izin modelini kullanmalıyım? - Bir yetkilendirme modelini uygulamanın en iyi uygulaması nedir? 🔥 Bir mola verin ve CIAM 102'de görüşürüz!