Günümüzde düşük kod araçlarının ve bulut hizmetlerinin olgunlaşmasıyla ve AI araçlarının hızla yaygınlaşmasıyla birlikte, uygulama geliştirme eşiği önemli ölçüde düşüyor ve piyasada daha fazla uygulama ortaya çıkıyor. İster karmaşık ister basit uygulamalar olsun, çoğu uygulama, kullanıcıların daha kararlı, güvenli ve özelleştirilmiş hizmetler alabilmesi için kullanıcı kaydı ve oturum açma senaryolarını içerir. Kullanıcı oturumu açma ve kaydını çözmek için ilk adım kimlik sistemi oluşturmaktır. Birçok tüketiciye yönelik uygulama için kimlik modelleri genellikle nispeten basittir ve hatta yalnızca e-posta ve şifre gerektirebilir. Uygulamanın hızlı büyüdüğü ve yeni kullanıcıları çektiği bir dönemde bu yeterlidir; ancak bir iş modeli olduğunda, en basit durumda, örneğin reklam hizmeti verirken, sıradan kullanıcı hesapları ve reklamveren hesapları arasında bir ayrım olması gerekir. Reklamveren hesapları, reklam dağıtım ölçeklerini, içerik vb. özelleştirebilir; sıradan kullanıcılar ise sadece bazı ücretsiz içerik ve reklamlara göz atabilirler. Logto, bulut tabanlı bir kimlik çözümüdür ve özel ihtiyaçları olan kullanıcıların özelleştirme yapabilmesi için bulut hizmetleriyle aynı çekirdeğe sahip bir açık kaynaklı yazılım (OSS) çözümü de vardır. Logto hizmeti, her Logto kullanıcısının kendi hesabını oluşturduğu ve hesap içinde birden fazla kiracı yönetebildiği, çok kiracılı bir sistem üzerine inşa edilmiştir. Diğer çeşitli kimlik bulut hizmetleri de benzer mimarilere sahiptir ve her bulut hizmeti "kiracı" kavramını kendine özgü tanımlar, bu yüzden bu makalede tartışılan kiracı modeli Logto senaryosuna özgüdür ve diğer sağlayıcılarda karşılık gelen diğer kavramlar olabilir. Özellikle, Logto'nun çok kiracılı modelinde, **_kiracılar arasındaki veri (son kullanıcıların tüm bilgileri) izole edilir_**, bu nedenle Logto kullanıcıları kendi iş ihtiyaçlarına göre son kullanıcı hesap verilerini bir Logto hesabı içinde yönetebilirler. Diğer birçok kimlik bulut hizmeti, her hesabın sadece bir kiracıya sahip olmasını destekleyebilir, bu da aynı anda birden fazla kiracı yönetmesi gereken kullanıcıların sık sık hesap değiştirmesine ve dolayısıyla kötü bir deneyim yaşamasına neden olur. Genel kimlik modeli

Tüm bunlardan sonra, uygulamanız için hangi hesap modelini seçmelisiniz? Burada üç duruma bakıyoruz. ## Durum 1: Uygulama doğrudan son kullanıcılara hizmet sunar Bu tür uygulamalardaki kimlik modeli oldukça basittir. Bunun bir örneğini müzik akışı uygulamasıyla verelim - yöneticiyi (bu durumda kiracı sahibi olan Logto kullanıcısı “foo”) dışında sadece son kullanıcılar vardır. Bu senaryoda, son kullanıcılar üç türe ayrılabilir: 1. Ücretsiz plan kullanıcı: Sadece ücretsiz müzik dinleyebilir 2. Ücretli plan kullanıcı: Ücretsiz müzik dinleyebilir ve kendi çalma listelerini oluşturabilir 3. Premium kullanıcı: Ücretsiz müzik çalma ve çalma listeleri oluşturmanın yanı sıra, HiFi müzikleri de çalabilir Yukarıdaki uygulama senaryosunda, yalnızca farklı izinlerle atanmış üç rol (ücretsiz, ücretli, premium) oluşturulması gereklidir. Son kullanıcı oturum açtıktan sonra, Logto onun sahip olduğu role göre belirli hizmetlerin (örneğin HiFi müziklerine erişim) sağlanıp sağlanmayacağına karar verebilir. Bu noktada, gereksinimleri karşılamak için yalnızca tek bir kiracıya ihtiyacımız vardır. Müzik uygulaması kimlik modeli

## Durum 2: eTicaret platformu uygulaması Günümüzde çok yaygın bir 2C iş modeli olan üçüncü taraf hizmet sağlayıcıları ve son kullanıcıları bağlayan bir platform. İki kullanıcı grubu düşünülmelidir - bir e-ticaret uygulaması örneği kullanarak, bunlar satıcılar (hizmet sağlayıcıları) ve alıcılar (son kullanıcılar)dır. Kimlik modelini burada iki şekilde oluşturabilirsiniz: 1. Alıcılar ve satıcılar kullanıcı gruplarını aynı kiracı altında toplayın. eTicaret uygulaması tek kiracı kimlik modeli

eTicaret uygulaması tek kiracı kimlik modeli

2. Alıcılar ve satıcıları sırasıyla iki farklı kiracıya yerleştirin. eTicaret uygulaması çok kiracılı kimlik modeli

Örneği daha anlaşılır hale getirmek için, alıcıların sipariş verebildiğini veya ürün açıklamalarını görüntüleyebildiğini; satıcıların ürün fiyatlarını değiştirme, ürün açıklamalarını değiştirip ürün stoğunu görüntüleyebildiğini varsayıyoruz. Satıcılar, ürün açıklamalarını görüntüleyerek sorunları bulup ürün bilgilerini zamanında güncelleyebilirler. Kimlik modeli 1 için, yalnızca bir uygulama vardır. Kaydolan tüm kullanıcılar alıcı olur. Birisi bir şey satmak isterse, kendi ürünlerini satmak için ekleyebilir, bu nedenle bu tür son kullanıcılar alıcı izinlerine ek olarak kendi ürünlerini yönetmek için satıcı izinleri kazanır. Kimlik modeli 2 için, her kiracının kendine özgü kimlik bilgisi ve ayrı bir yetkilendirme geçidi olduğundan, her kiracının kendine ait ayrı bir uygulamaya ihtiyacı vardır. Örnek olayda, bir alıcı uygulaması ve bir satıcı uygulaması olurdu. Alıcı hesapları satıcı olamaz ve satıcı hesapları da alıcı olamaz. Eğer satıcılar model 1'de olduğu gibi kendi ürün açıklamalarını bir alıcı perspektifinden kontrol etmek isterlerse, satıcı uygulamasında aynı işlevselliği yeniden uygulamaları ya da görüntülemek için bir alıcı uygulama hesabı kaydetmeleri gerekir. Bu karmaşıklığı artırır, ancak avantajı alıcı ve satıcı kimliklerinin tamamen izole edilmiş olmasıdır. Eğer satıcıların yönetmek için birçok farklı ürünü varsa, kimlik modeli 2'yi kullanıp daha özel bir satıcı uygulaması geliştirmek daha iyi bir seçenek olmalıdır. Model 1, eBay gibi satıcıların çok fazla ürünü olmadığı ve çok karmaşık ürün yönetim işlevselliğine ihtiyaç duymadığı platformlar için daha uygundur. ## Durum 3: BT danışmanlık şirketi tarafından yapılan uygulamalar Bir BT teknik danışmanlık şirketinin, kendileri IT sistemleri geliştirme yeteneğinde olmayan müşterileri olduğunu varsayın, bu nedenle bu şirketten teknik hizmetler sağlamalarını istiyorlar. Şirketin iki müşterisi olduğunu varsayalım, biri bir kitap dükkanının iç yönetim sistemi, diğeri ise bir otel rezervasyon sistemidir. Kitap dükkanı sahibi perspektifinden bakıldığında, otel misafirlerinin rastgele kitap yönetim sistemi giriş yapabilmelerini istemem, çünkü bu çok güvensiz olurdu. Bu nedenle, gizliliği koruma açısından, her müşteri için ayrı bir kiracı ayarlamak, kiracı bilgi izolasyonu mekanizmasını kullanarak, müşteri verilerinin diğer müşterilere görünmez olmasını sağlamak gerekir. BT danışmanlık şirketi için kimlik modeli

BT danışmanlık şirketi için kimlik modeli

Daha önce bahsettiğimiz gibi, birden fazla kiracı oluşturma ihtiyacınız olsa bile, Logto size bir hesap içinde birden fazla kiracı yönetmenize yardımcı olabilir, bu da başka hizmetlerin gerektirdiği gibi birden fazla hesap oluşturup yönetmeyi gerektirmekten daha kullanışlı ve güvenlidir. Yukarıda gösterilen örnekler sayesinde, kesinlikle birden fazla kiracı oluşturmanız gereken durumları belirlemiş olmalı, hangi senaryolarda tek bir kiracı veya birden fazla kiracı bulunabilir ve kendi iş ihtiyaçlarınıza göre size uygun kimlik modelini seçmelisiniz. Logto ekibi, "birden fazla kiracı oluşturulmalı mı" sorusunun hiçbir iş için bir engel olmamasını sağlamayı amaçlamaktadır. İş senaryonuzun tek bir kiracı ile gerçekleştirilebilir olup olmadığından emin değilseniz, danışma için [Logto topluluğuna katılın](https://discord.gg/UEPaF3j5e6). Sorularınız başka birinin de sorusu olabilir, bu yüzden karşılaştığınız zorlukları bizimle paylaşarak Logto ürünlerinin ölçeklenebilirliğini artırmaya yardımcı olun. Uygulamanız için bir kimlik çerçevesi seçiyorsanız, Logto'yu denemeye değer. Küçük işletmelerden büyük ölçekli uygulamalara kadar çeşitli iş senaryolarına uygun kullanıma hazır bir çözüm sunar! Logto'yu Bugün Deneyin