Self-hosted yazılımlarda SSO vergisi nedir?

SSO vergisi nedir

Self-hosted yazılımlardaki SSO vergisi, uygulamanın ücretsiz olup tek oturum açma (SSO) özelliğinin ise satın alınması gereken bir özellik olması durumudur. Tüm sistemi kendi VPS'niz üzerinde, herhangi bir lisans anahtarı veya kullanıcı sınırı olmadan çalıştırabilirsiniz. Ardından dokümantasyondaki kimlik doğrulama sayfasını açtığınızda, OpenID Connect (OIDC) veya SAML (security assertion markup language) özelliklerinin ücretli bir planın arkasında gizlendiğini görürsünüz.

Bu durum, standart bir ücretli özellikten daha önemlidir; çünkü SSO, bir dizi self-hosted servisin tek bir sistem gibi davranmasını sağlayan temel unsurdur. Bir kimlik sağlayıcı (IdP), kişi başına tek bir hesap, tek bir parola politikası, çok faktörlü kimlik doğrulamayı (MFA) açmak için tek bir merkez ve birinin erişimini kesmek için tek bir nokta sağlar. Bu özellik olmadan, her uygulama kendi küçük kullanıcı veritabanını tutar ve siz de her birini manuel olarak yönetmek zorunda kalırsınız.

Bu model, halka açık bir skor tablosu oluşturulacak kadar eskidir. sso.tax adresindeki SSO Wall of Shame, tek oturum açma özelliği için yüksek ek ücret talep eden satıcıları listeler. 2018 yılına kadar uzanan kayıtların bulunduğu bu listede, yazar adil bir kriter belirlemiştir: "Eğer SSO desteğiniz fiyatı %10 oranında artırıyorsa, bu listede değilsiniz." Bu listenin büyük bir kısmı kapalı kaynaklı yazılımlardan oluşmaktadır. Aynı fiyatlandırma mantığı artık kendi sunucunuzda barındırdığınız açık kaynaklı projelerde de karşımıza çıkmaktadır.

Bakımcılar neden tek oturum açma (SSO) özelliğini ücretli katmana koyuyor?

Bunun iki nedeni vardır ve her ikisi de dürüst gerekçelerdir. SSO desteği maliyetlidir ve büyük bir organizasyonun ödeme yapacağı az sayıdaki özellikten biridir.

Destek maliyeti gerçektir çünkü kimlik entegrasyonu asla bitmez. Her IdP, taleplerini (claims) biraz farklı biçimlendirir. Grup eşleme, oturum ömrü, yönlendirme URL'leri ve saat sapması (clock skew) gibi unsurların her biri giriş hatalarına yol açar. Bir giriş hatası tüm kullanıcıları aynı anda sistem dışı bıraktığı için bu tür destek talepleri acildir. Ardından iç içe geçmiş gruplar, rol eşleme, SCIM (etki alanları arası kimlik yönetimi sistemi) ile otomatik provizyon ve uyumluluk ekibinin inceleyeceği denetim günlükleri gibi ek talepler gelir.

Gelir tarafı ise kötü niyetten ziyade aritmetiktir. Uygulamayı kendi IdP'sine bağlayamayan bir şirket, o uygulamayı hiç dağıtmayacaktır; bu nedenle SSO, ödeme yapan kullanıcı ile yapmayan kullanıcı arasında net bir çizgi çizer. Açık çekirdekli (open core) bir projenin bu çizgiyi bir yere koyması gerekir. SSO, bu çizgiye diğer neredeyse tüm özelliklerden daha düzgün oturduğu için pek çok proje bu özelliği seçmektedir.

Genel şikayete yönelik bir düzeltme: Bir özelliğin kaldırıldığını varsaymadan önce değişiklik günlüğünü (changelog) kontrol edin, çünkü bir kaldırma işlemi sürüm notlarında görünür. Bu yazı için incelediğim projelerin genelinde, ücretli SSO özellikleri en başından beri ücretli katman için geliştirilmişti. Ücretsiz çalışan bir SSO özelliğinin geri alındığı bir duruma rastlamadım. Grafana bu konuda tipik bir örnektir. SAML sayfası, "Grafana Enterprise ve Grafana Cloud'da mevcuttur" şeklinde tek satırlık bir not içerirken, kendi sağlayıcınıza karşı genel OAuth kullanımı açık kaynak sürümünde çalışmaya devam eder.

SSO vergisinin size gerçek maliyeti

Parasal maliyet, işin daha küçük kısmıdır. Ücretli katmanlar kullanıcı başına satılır; bu nedenle ekip büyüdükçe fatura artar, ancak barındırma ve yükseltme işlemleri sizin sorumluluğunuzda kalmaya devam eder.

Daha büyük maliyet ise manuel kimlik yönetimi iş yüküdür ve bu durum dört alanda kendini gösterir.

• Her uygulama için ayrı bir parola deposu; bu da yeniden kullanılan tek bir parolanın, o parolayı paylaşan tüm uygulamalarda bir güvenlik açığı oluşturması demektir.
• Hafızaya dayalı işten çıkarma (offboarding) süreçleri. Bir kişinin eriştiği her servisi hatırlamanız gerekir; unuttuğunuz servis ise genellikle en kritik olanıdır.
• Uygulama bazında yapılandırılan MFA; tabii uygulama bunu destekliyorsa.
• Paylaşımlı girişler; bu baskı altındaki küçük ekiplerde gerçekte yaşanan durum budur.

Son madde ayrı bir paragrafı hak ediyor. Bir ekip, bir belge yöneticisinde tek bir yönetici hesabını paylaştığında, denetim izi (audit trail) her işlem için tek bir isim kaydeder; bu nedenle faturayı kimin sildiğini tespit edemezsiniz. Kullanıcı bazlı izinler de işlevini yitirir, çünkü sistemde tek bir kullanıcı vardır. SSO vergisinin gerçek zararı budur: küçük ekipleri, diğer tüm alternatiflerden daha kötü olan tek bir paylaşımlı hesap kullanmaya zorlar.

Herhangi bir şeyi benimsemeden önce uygulanacak kontrol listesi

Bunu, uygulama 400 belgeye ulaşmadan önce, docker compose up işleminden önce çalıştırın.

1. Dokümantasyondaki kimlik doğrulama sayfasını açın ve en üstteki katman notunu okuyun. Ücretli özellikler bir rozet veya tek satırlık bir kullanılabilirlik cümlesi ile belirtilir.
2. Uygulamanın sabit bir genel sağlayıcı listesi yerine, kendi sağlayıcınızla OIDC veya SAML üzerinden konuştuğunu doğrulayın.
3. Rol ve grup eşlemesini kontrol edin. Kullanıcıyı oluşturmak işin yarısıdır; on farklı uygulamada izinleri elle atamak ise işin yorucu olan diğer yarısıdır.
4. Uygulamanın güvenilir bir proxy'den gelen kimliği doğrulanmış kullanıcı adını başlık (header) üzerinden kabul edip etmediğini ve hangi proxy'ye güvendiğini sabitleyip sabitleyemeyeceğinizi kontrol edin.
5. Git üzerindeki lisans geçmişini okuyun ve katkıda bulunanların bir CLA (katkıda bulunan lisans sözleşmesi) imzalayıp imzalamadığını kontrol edin.
6. İşten çıkarma (offboarding) sürecini kontrol edin. IdP hesabı devre dışı bırakıldığında API (application programming interface) anahtarlarına ve aktif oturumlara ne olduğunu öğrenin.

1. madde, hayal kırıklıklarının en çok yaşandığı yerdir. "Google ile Giriş Yap" butonu, kimlik sağlayıcınızla yapılan bir OIDC entegrasyonu değildir; tek bir sağlayıcıyla yapılan sabit bir entegrasyondur. Gerçek destek, sizden bir sağlayıcı URL'si ister ve diğer her şey keşif (discovery) süreciyle otomatik olarak gelir. Sağlayıcınızın bu konudaki durumunu tek bir komutla doğrulayabilirsiniz.

curl -s https://id.example.com/.well-known/openid-configuration \
  | jq '.issuer, .authorization_endpoint, .token_endpoint'

Sağlıklı bir sağlayıcıdan üç URL döner. Boş bir sonuç veya 404 hatası genellikle keşif yolunun yanlış olduğu anlamına gelir ve bu yol sağlayıcıya özeldir: Keycloak bunu /realms/<realm>/.well-known/openid-configuration altında yayınlar. Uygulamada sağlayıcı URL'si için bir alan yoksa, özellik listesinde ne yazarsa yazsın, IdP'nizle iletişim kuramaz.

1. madde, bir çalışan ayrıldıktan haftalar sonra sorun yaratır. Hesabı IdP'de devre dışı bırakmak yeni girişleri durdurur. Ancak bu işlem, uygulamanın daha önce verdiği bir API anahtarını iptal etmez; çünkü uygulama bu anahtarı kendi içinde doğrular ve IdP'ye sormaz. Bu nedenle işten çıkarma süreci iki adımdan oluşur: IdP'deki hesabı devre dışı bırakın ve ardından her uygulama içindeki kullanıcıyı veya anahtarlarını silin.

Kademe rozetlerinin gerçek anlamı

Bu bilgiler, Ağustos 2026 itibarıyla her projenin kendi dokümantasyonu kontrol edilerek derlenmiştir. Ücretli taraftan başlayalım.

Grafana, SAML özelliğini "Grafana Enterprise ve Grafana Cloud'da mevcuttur" şeklinde tanımlar; buna ekip senkronizasyonu ve SCIM provizyonu da dahildir. Genel OAuth, GitHub OAuth, LDAP (hafif dizin erişim protokolü) ve auth proxy özellikleri açık kaynak sürümde yer aldığından, küçük ölçekli self-host kullanıcıları kendi sağlayıcıları üzerinden giriş yapabilirler. Ücretli özellik sınırı, genel olarak tek oturum açma (SSO) sisteminde değil, SAML noktasında başlar; "SSO vergisi" ifadesinin genellikle göz ardı ettiği nüans budur.

Metabase ise daha net bir tutum sergiler. Dokümantasyonunda, "SAML kimlik doğrulaması yalnızca Pro ve Enterprise planlarında (hem self-hosted hem de Metabase Cloud için) mevcuttur" ifadesi yer alır. Açık kaynak sürüm, parola ile giriş ve LDAP desteğini korur.

Passbolt, SSO dokümantasyonunu Pro ve Cloud olarak işaretlediğinden, topluluk sürümünde bu özellik bulunmaz. Dokümante edilen sağlayıcılar arasında Keycloak ve Entra ID yer alır.

Şimdi diğer tarafa bakalım, çünkü bu model evrensel olmaktan çok uzaktır.

• GitLab Self-Managed, SAML sayfasında "Kademe: Free, Premium, Ultimate" ibaresini taşır; dolayısıyla kendi GitLab kurulumunuzda SAML kullanmak ücretsizdir.
• Paperless-ngx, OIDC yapılandırmasını PAPERLESS_SOCIALACCOUNT_PROVIDERS üzerinden yapar, PAPERLESS_DISABLE_REGULAR_LOGIN ile yerel giriş formunu gizler ve PAPERLESS_SOCIAL_ACCOUNT_SYNC_GROUPS ile talepleri (claims) gruplara eşler.
• Planka, OIDC_ISSUER, OIDC_CLIENT_ID ve OIDC_CLIENT_SECRET parametrelerini alır, kapsamları varsayılan olarak openid profile email şeklinde ayarlar ve OIDC_ADMIN_ROLES ile bir rol talebinden yönetici ataması yapar.
• BookStack, AUTH_METHOD=oidc ile geçiş yapar, ardından sağlayıcı gruplarını kendi rolleriyle OIDC_USER_TO_GROUPS=true ve OIDC_GROUPS_CLAIM üzerinden eşler.
• Vaultwarden, 27 Aralık 2025 tarihinde yayınlanan 1.35.0 sürümüyle "OpenID Connect ile SSO desteği" özelliğini sunmuştur; bu özellik, daha önce bir fork üzerinde tutulan bir katkıdan gelmiştir.
• listmonk, v4.0.0 sürümünden bu yana kullanıcı rolleriyle birlikte OIDC giriş desteğine sahiptir.

Bu bilgileri, sisteme dahil olmadan önce seçim yaparken kullanın. Bir Planka kanban panosu ve diğer self-hosted Trello alternatifleri kimlik doğrulamasını aynı şekilde ele almaz; aynı durum BookStack, Wiki.js ve Outline için de geçerlidir. Ücretsiz OIDC, depolama limitleri veya mobil istemciler gibi değerlendirebileceğiniz bir özelliktir. Eğer hala listenizi oluşturuyorsanız, 2026 yılında neler self-host edilir makalesi makul bir başlangıç noktasıdır; ayrıca hem Paperless-ngx belge yöneticisi hem de Vaultwarden bugün size ücretsiz OIDC imkanı sunar.

Uygulama önündeki reverse proxy neden tek oturum açma (SSO) değildir

Yaygın geçici çözüm forward auth yöntemidir. Reverse proxy'niz her isteği bekletir, bir kimlik doğrulama servisine bu tarayıcının oturum açıp açmadığını sorar ve ancak o zaman isteği uygulamaya iletir. authentik buna proxy sağlayıcısı adını verir; tek bir uygulama için forward auth modu ve tüm alan adı için başka bir modu bulunur. Authelia ve oauth2-proxy de aynı işi yapar.

Bir Caddy site bloğu, authentik'in kendi örneğini takip ederek şu şekilde görünür:

app.example.com {
  forward_auth http://authentik-outpost:9000 {
    uri /outpost.goauthentik.io/auth/caddy
    copy_headers X-Authentik-Username X-Authentik-Email X-Authentik-Groups
    trusted_proxies private_ranges
  }
  reverse_proxy app:8000
}

Caddy'de bu başlık isimlerinin büyük/küçük harf kullanımı önemlidir, çünkü eşleşmeyen bir isim boş olarak ulaşır. Onayladığı her istekte outpost X-authentik-username, X-authentik-email, X-authentik-groups ve birkaç başlık daha ayarlar.

Bu size şunları kazandırır: Kimse kimlik sağlayıcınızdan geçmeden uygulamaya ulaşamaz; bu nedenle yamalanmamış bir giriş formu artık internete açık değildir ve MFA, proxy arkasındaki her şeye aynı anda uygulanır.

Bu size şunları kazandırmaz: Uygulama içinde kimlik yönetimi. Uygulama hala kendi hesaplarına ve kimin oturum açtığına dair kendi fikrine sahiptir. Herkes proxy'den geçip tek bir paylaşılan yönetici hesabına düşerse, güçlü bir ön kapınız ve arkasında anonim bir oturumunuz olur. Denetim günlüğü hala tek bir isim gösterir. İzinler kişiler arasında farklılık gösteremez. Bu düzenlemeye SSO demek bir güvenlik hatasıdır, çünkü işten çıkarma süreci sadece yarı yarıya doğrudur: kişiyi IdP'nizden kaldırmak ön kapıyı kapatır, ancak uygulama içinde oluşturdukları bir API anahtarı, uygulamaya doğrudan ulaşabilen herkes için çalışmaya devam eder.

Başlık tabanlı kimlik doğrulamanın güvenli hale getirilmesi

Bazı uygulamalar, proxy üzerinden gelen kullanıcı adını kabul eder; bu da ücretli bir SSO hizmeti olmadan kullanıcı bazlı kimlik yönetimi sağlar. Bu ayarın ismi her projede farklıdır.

Grafana, bu özelliği auth proxy olarak adlandırır ve devre dışı bırakılmış şekilde sunar. Başlık ismi varsayılan olarak X-WEBAUTH-USER değerindedir ve bunu proxy'nizin ayarladığı herhangi bir başlığa yönlendirebilirsiniz.

[auth.proxy]
enabled = true
header_name = X-authentik-username
header_property = username
auto_sign_up = true
whitelist = 10.0.0.5

whitelist, kullanıcıların atladığı satırdır. Grafana belgeleri, bu ayarın kullanıcıların başlığı taklit etmesini engellemek için var olduğunu açıkça belirtir; bu nedenle bu satır, yalnızca proxy'nizin adresini içermelidir. Gitea da aynı özelliğe farklı isimlerle sahiptir ve daha güvenli bir varsayılan ayarla gelir.

[security]
ENABLE_REVERSE_PROXY_AUTHENTICATION = true
REVERSE_PROXY_AUTHENTICATION_USER = X-WEBAUTH-USER
REVERSE_PROXY_TRUSTED_PROXIES = 10.0.0.5/32
REVERSE_PROXY_LIMIT = 1

REVERSE_PROXY_TRUSTED_PROXIES varsayılan olarak 127.0.0.0/8,::1/128 değerindedir ve REVERSE_PROXY_LIMIT, Gitea'nın zincirde güveneceği proxy sayısını belirler. Bu sınırı sıfıra ayarlamak, başlık işleme özelliğini tamamen kapatır.

Paperless-ngx, PAPERLESS_HTTP_REMOTE_USER_HEADER_NAME ile birlikte PAPERLESS_ENABLE_HTTP_REMOTE_USER seçeneğini sunar ve belgelerinde, bu tür tüm ayarlar için geçerli olan şu uyarıyı belirtir:

Bu, bir isteğe sadece Remote-User: <username> başlığı ekleyerek kimlik doğrulamaya izin verecektir. Dikkatli kullanın!

Başlık tabanlı kimlik doğrulamanın güvenli kalmasını sağlayan iki kural vardır ve her ikisi de erişilebilirlik ile ilgilidir. Birincisi, uygulama proxy dışında hiçbir yerden erişilemez olmalıdır; çünkü uygulamaya soket açabilen herkes bu başlığı göndererek istediği kullanıcı gibi davranabilir. Docker'da ports: ["8000:8000"] tüm arayüzlerde yayın yapar, bu yüzden uygulamayı ports: ["127.0.0.1:8000:8000"] ile loopback adresine bağlayın veya yayınlanan portu kaldırıp proxy'yi aynı Docker ağına dahil edin. İkincisi, proxy istemciden gelen başlığın tüm kopyalarını silmelidir; böylece uygulama yalnızca proxy'nizin kimlik doğrulama sonrası atadığı değeri görür.

Her ikisini de kontrol edin. İlk komutu VPS'nizin dışındaki bir makineden, ikincisini ise sunucunun kendisinden çalıştırın.

curl -si -H "Remote-User: admin" http://203.0.113.10:8000/ | head -n 1
ss -ltnp | grep 8000

curl komutu bağlantı kuramamalı ve ss, 0.0.0.0:8000 yerine 127.0.0.1:8000 çıktısını vermelidir. HTTP/1.1 302 Found ile başlayan bir satır, uygulamanın doğrudan genel internete yanıt verdiğini gösterir; bu durumda herkes, bir başlıkta isim belirterek istediği kullanıcı olarak giriş yapabilir.

Ücretsiz SSO seçeneği olmadığında şikayet etmek yerine karar verin

Denediğim sırayla dört seçenek.

1. OIDC içeren uygulamayı seçin. İki proje aynı işi yapıyorsa ve biri kimlik sağlayıcınızla ücretsiz konuşabiliyorsa, bu işletme maliyetinde gerçek bir fark yaratır.
2. Forward auth yöntemini dürüstçe kullanın. Tek hesaplı ve tek operatörlü bir yönetim aracı için ön taraftaki bir proxy yeterlidir; uygulama içindeki kullanıcı bazlı kimlik doğrulama bir fayda sağlamaz.
3. Ödeme yapın. Uygulama işiniz için merkezi bir öneme sahipse ve kullanıcı başına düşen fiyat ekibinizin büyüklüğüne uygunsa, ödenen para projenin bakımını sağlar; aksi takdirde bu bedeli akşam saatlerinizden feragat ederek ödersiniz.
4. Sorun takip sistemini arattıktan sonra geliştirici ekibe danışın. Vaultwarden'ın OIDC desteği, bir katkıcının fork'u ve uzun süredir bekleyen bir pull request aracılığıyla geldi; bu nedenle çalışan bir uygulama ile desteklenen özellik talepleri bazen ücretsiz sürüme dahil edilir.

Bunların hiçbiri kendi kimlik sağlayıcınız olmadan çalışmaz; bu yüzden önce bu parçayı oluşturmalısınız. VPS üzerinde authentik çalıştırmak, size yukarıda kullanılan OIDC ve SAML sağlayıcısı ile forward auth outpost'unu sunar; Keycloak, authentik ve Zitadel karşılaştırması ise henüz karar vermediyseniz seçeneklerin avantaj ve dezavantajlarını kapsar.

Lisans geçmişi ve kontrol listesinde neden yer aldığı

Son kontrol listesi maddesi gelecekle ilgilidir, çünkü bugünkü katman düzeni yalnızca anlık bir görüntüden ibarettir. İyi belgelenmiş iki vaka, zeminin her iki yönde de ne kadar hızlı değişebileceğini göstermektedir. HashiCorp, 10 Ağustos 2023 tarihinde gelecekteki tüm sürümler için Business Source License 1.1'i benimsemiş, daha önceki sürümler ise MPL 2.0 (Mozilla Public License) kapsamında kalmıştır. Redis, Mart 2024'te SSPL'ye (server side public license) geçmiş, ardından 1 Mayıs 2025'te Redis 8'in de AGPLv3 (GNU Affero General Public License) altında sunulacağını duyurmuştur.

Bunların her ikisini de motivasyondan ziyade mekanizmaya dair kanıt olarak okuyun. Bugün okuduğunuz lisans, bugün kurduğunuz sürüme uygulanır ve tüm telif haklarını elinde bulunduran bir proje, bir sonraki sürümün şartlarını tek başına değiştirebilir. CLA sorusunun kontrol listesinde yer almasının nedeni budur; çünkü geniş kapsamlı telif hakkı devri, tek taraflı lisans değişikliğini mümkün kılan şeydir.

Bir projeyi temel almadan önce projenin geçmişini kendiniz inceleyin.

git clone --filter=blob:none https://github.com/paperless-ngx/paperless-ngx.git
cd paperless-ngx
git log --follow --oneline -- LICENSE

Çoğunluğu ilk içe aktarımdan gelen kısa bir commit listesi iyiye işarettir. Lisans dosyasındaki birkaç yeniden yazım, mevcut şartlara göre plan yapmadan önce her bir commit mesajını okumanız gerektiği anlamına gelir.

FAQ

SSO vergisi nedir?

SSO vergisi, ürünün geri kalanı ücretsiz veya ucuzken, tek oturum açma (single sign-on) özelliğinin premium bir özellik olarak ücretlendirilmesi uygulamasıdır. Kendi kendine barındırılan (self-hosted) yazılımlarda bu durum, lisans anahtarı olmadan çalıştırabileceğiniz açık kaynaklı bir uygulama gibi görünürken, OIDC veya SAML girişinin ücretli bir katmanda yer alması şeklinde ortaya çıkar. İsim, bunun için büyük bir prim talep eden satıcıları takip eden sso.tax adresindeki SSO Utanç Duvarı'ndan (SSO Wall of Shame) gelmektedir. Kendi kendine barındıran bir kullanıcı için sonuç, her uygulamanın kendi kullanıcı veritabanını tutması ve bu nedenle hesapların elle oluşturulup silinmesi zorunluluğudur.

Forward auth kullanan bir reverse proxy, SSO ile aynı şey midir?

Hayır. Forward auth ön kapıyı korur: proxy'niz, herhangi bir istek uygulamaya ulaşmadan önce kimlik sağlayıcı ile kontrol yapar. Arkasındaki uygulama hala kendi hesaplarını kullanır; bu nedenle herkes tek bir ortak girişe yönlendirilirse, tek bir anonim oturumunuz ve içinde tek bir ismin bulunduğu bir denetim günlüğünüz olur. Gerçek kullanıcı bazlı kimlik, yalnızca uygulama kullanıcı adını bir başlıktan (header) okuduğunda gerçekleşir; Grafana'nın auth proxy'si, Gitea'nın reverse proxy kimlik doğrulaması ve Paperless-ngx'in PAPERLESS_ENABLE_HTTP_REMOTE_USER özelliği bunu yapabilir. Bu ayarlar, uygulama yalnızca proxy üzerinden erişilebilir olduğunda güvenlidir; çünkü başlık, herhangi bir istemcinin gönderebileceği düz bir metin dizisidir.

Hangi self-hosted uygulamalar ücretsiz sürümde OIDC içerir?

Ağustos 2026 itibarıyla proje belgeleri üzerinden kontrol edilmiştir: Paperless-ngx, Planka, BookStack, Gitea, listmonk ve Vaultwarden'ın tümü ücretsiz sürümlerinde OIDC'yi destekler ve GitLab Self-Managed, SAML'ı Tier: Free altında listeler. Grafana'nın açık kaynaklı sürümü kendi sağlayıcınıza karşı genel OAuth işlemlerini yönetirken, SAML orada bir Enterprise özelliğidir. Kurulum yapmadan önce projenin kendi kimlik doğrulama sayfasından doğrulayın, çünkü bu listeler yeni sürümlerle birlikte değişebilir.

Tek oturum açma özelliğinin kilidini açan katman için ödeme yapmalı mıyım?

Buna iki sayı ile karar verin: kaç kişinin hesaba ihtiyacı var ve aksi takdirde kaç uygulamayı elle yönetmeniz gerekecek? Bir veya iki yönetici için, yerel bir hesabın önünde forward auth yeterlidir ve ücretli katman çok az değer katar. İnsanların katıldığı ve ayrıldığı bir ekip için, işten çıkarma sırasında gözden kaçan tek bir hesap, lisans ücretinden daha maliyetlidir ve yapılan ödeme, güvendiğiniz bakım sürecini finanse eder. Eğer fiyat uygun değilse, pratik hareket, OIDC içermeyen bir uygulama ile uğraşmak yerine OIDC içeren bir uygulamayı seçmektir.