가이드

작성자 Matt Connor 2026-08-15

셀프 호스팅 소프트웨어의 SSO 세금이란 무엇인가

오픈 소스 프로젝트가 OIDC와 SAML 기능을 유료 티어로 분리하는 이유를 분석합니다. 유지보수 비용과 기업용 기능의 상관관계를 살펴보고, 설치 전 반드시 확인해야 할 체크리스트를 정리했습니다.

SSO 세금이란 무엇인가

셀프 호스팅 소프트웨어에서 SSO 세금이란 애플리케이션 자체는 무료이지만, 싱글 사인온(SSO) 기능만큼은 유료로 구매해야 하는 패턴을 의미합니다. 라이선스 키나 사용자 수 제한 없이 자신의 VPS에서 전체 서비스를 운영할 수 있지만, 문서의 인증 페이지를 열어보면 OpenID Connect(OIDC)나 SAML(Security Assertion Markup Language)이 유료 플랜에 포함되어 있는 것을 발견하게 됩니다.

이 문제는 일반적인 유료 기능보다 더 중요합니다. SSO는 여러 셀프 호스팅 서비스를 하나의 시스템처럼 동작하게 만드는 핵심 요소이기 때문입니다. ID 공급자(IdP)를 사용하면 사용자당 하나의 계정, 하나의 비밀번호 정책, 한 곳에서의 다중 인증(MFA) 활성화, 그리고 한 곳에서의 계정 차단이 가능해집니다. 이 기능이 없다면 각 애플리케이션이 자체적인 사용자 데이터베이스를 유지하게 되며, 관리자는 이를 일일이 수동으로 관리해야 합니다.

이 패턴은 이미 공개적인 기록이 존재할 정도로 오래되었습니다. sso.tax의 'SSO 수치스러운 벽(SSO Wall of Shame)'은 싱글 사인온에 과도한 비용을 청구하는 공급업체 목록을 2018년부터 기록하고 있으며, 작성자는 다음과 같은 합리적인 기준을 제시합니다. "SSO 지원을 위해 가격을 10% 정도 인상하는 수준이라면 이 목록에 포함되지 않습니다." 해당 목록의 대부분은 폐쇄형 소프트웨어입니다. 이제는 직접 호스팅하는 오픈 소스 프로젝트에서도 동일한 가격 책정 논리가 나타나고 있습니다.

메인테이너가 싱글 사인온(SSO)을 유료 티어에 배치하는 이유

두 가지 이유가 있으며 둘 다 타당합니다. SSO는 지원 비용이 많이 들며, 대규모 조직이 기꺼이 비용을 지불하는 몇 안 되는 기능 중 하나이기 때문입니다.

지원 비용은 실질적인 문제입니다. ID 통합은 결코 한 번에 끝나지 않기 때문입니다. 모든 IdP는 클레임 형식이 조금씩 다릅니다. 그룹 매핑, 세션 수명, 리다이렉트 URL, 클록 스큐(clock skew)는 각각 로그인 버그를 유발합니다. 로그인 버그는 모든 사용자를 즉시 차단하므로 이러한 티켓은 매우 긴급하게 처리됩니다. 이후 중첩 그룹, 역할 매핑, SCIM(System for Cross-domain Identity Management)을 통한 자동 프로비저닝, 규정 준수 팀이 검토할 감사 로그와 같은 추가 요청이 이어집니다.

수익 측면은 악의가 아닌 산술적인 판단입니다. 애플리케이션을 자체 IdP에 연결할 수 없는 기업은 해당 서비스를 도입하지 않을 것이므로, SSO는 비용을 지불하는 사용자와 그렇지 않은 사용자를 구분하는 명확한 기준이 됩니다. 오픈 코어 프로젝트는 이러한 기준선을 어디엔가 설정해야 합니다. SSO는 다른 어떤 기능보다 이 기준선에 적합하게 위치하므로 많은 프로젝트가 이를 선택합니다.

일반적인 불만에 대한 정정 사항이 하나 있습니다. 기능이 제거되었다고 단정하기 전에 변경 로그를 확인하십시오. 제거된 기능은 릴리스 노트에 나타나기 때문입니다. 이 게시물을 위해 확인한 프로젝트 전반에서 유료 SSO 기능은 처음부터 유료 티어를 위해 구축되었습니다. 무료로 제공되던 SSO 기능이 철회된 사례는 찾지 못했습니다. Grafana가 대표적인 예입니다. Grafana의 SAML 페이지에는 "Available in Grafana Enterprise and Grafana Cloud"라는 한 줄의 메모가 있지만, 오픈 소스 빌드에서도 자체 발급자를 대상으로 하는 일반적인 OAuth는 정상적으로 작동합니다.

SSO 세금이 실제로 초래하는 비용

금전적인 비용은 절반에 불과합니다. 유료 티어는 사용자당 요금을 부과하므로 팀 규모가 커질수록 비용도 증가하지만, 호스팅과 업그레이드는 여전히 사용자의 몫으로 남습니다.

더 큰 비용은 수동으로 수행해야 하는 계정 관리 작업이며, 이는 다음 네 가지 영역에서 발생합니다.

애플리케이션마다 별도의 비밀번호 저장소가 필요하므로, 비밀번호를 재사용하면 해당 비밀번호를 공유하는 모든 애플리케이션이 보안 위협에 노출됩니다.
퇴사자 계정 삭제를 기억에 의존해야 합니다. 해당 인원이 사용했던 모든 서비스를 일일이 기억해야 하며, 잊어버린 서비스 하나가 치명적인 보안 구멍이 될 수 있습니다.
애플리케이션별로 MFA를 설정해야 하며, 이마저도 지원하지 않는 애플리케이션이 존재합니다.
계정 공유가 발생합니다. 이는 이러한 압박을 받는 소규모 팀에서 실제로 일어나는 현상입니다.

마지막 항목은 별도로 언급할 가치가 있습니다. 팀이 문서 관리 도구에서 하나의 관리자 계정을 공유하면, 감사 로그에는 모든 작업이 하나의 이름으로 기록되므로 누가 송장을 삭제했는지 확인할 수 없습니다. 사용자별 권한 설정 또한 단일 사용자만 존재하게 되어 무용지물이 됩니다. 이것이 바로 SSO 세금으로 인한 실질적인 피해입니다. SSO 세금은 소규모 팀이 단일 공유 계정을 사용하도록 내몰며, 이는 다른 어떤 대안보다도 위험합니다.

도입 전 확인해야 할 체크리스트

이 작업은 애플리케이션에 400개의 문서가 쌓인 뒤가 아니라, docker compose up 이전에 수행해야 합니다.

문서의 인증 페이지를 열고 상단의 티어 관련 안내를 읽으십시오. 유료 기능에는 배지나 한 줄짜리 가용성 문구가 표시되어 있습니다.
애플리케이션이 고정된 공개 제공자 목록이 아닌, 귀하의 자체 발급자(issuer)와 OIDC 또는 SAML로 통신하는지 확인하십시오.
역할 및 그룹 매핑을 확인하십시오. 사용자를 생성하는 것은 절반의 작업일 뿐이며, 10개의 애플리케이션에서 수동으로 권한을 할당하는 나머지 절반이 더 고통스럽습니다.
애플리케이션이 신뢰할 수 있는 프록시로부터 헤더를 통해 인증된 사용자 이름을 허용하는지, 그리고 신뢰할 프록시를 고정할 수 있는지 확인하십시오.
git에서 라이선스 이력을 읽고, 기여자들이 CLA(기여자 라이선스 계약)에 서명하는지 확인하십시오.
오프보딩 절차를 확인하십시오. IdP 계정이 비활성화될 때 API(application programming interface) 토큰과 활성 세션이 어떻게 처리되는지 파악하십시오.

2번 항목에서 가장 많은 실망이 발생합니다. "Google로 로그인" 버튼은 귀하의 ID 제공자와 연동되는 OIDC가 아니라, 특정 벤더와 고정된 통합일 뿐입니다. 진정한 지원은 발급자 URL을 요구하며, 나머지 모든 정보는 discovery를 통해 가져옵니다. 다음 명령어로 제공자 측의 설정을 확인할 수 있습니다.

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

정상적인 제공자라면 3개의 URL을 반환합니다. 결과가 비어 있거나 404 오류가 발생한다면 discovery 경로가 잘못되었을 가능성이 높으며, 해당 경로는 제공자마다 다릅니다. Keycloak은 /realms/<realm>/.well-known/openid-configuration 경로에 이를 게시합니다. 애플리케이션에 발급자 URL을 입력할 필드가 아예 없다면, 기능 목록에 무엇이 적혀 있든 귀하의 IdP와 통신할 수 없습니다.

6번 항목은 퇴사자가 발생한 지 몇 주가 지난 후에 문제를 일으킵니다. IdP에서 계정을 비활성화하면 새로운 로그인은 차단됩니다. 하지만 애플리케이션이 이전에 발급한 API 토큰은 취소되지 않습니다. 애플리케이션이 토큰을 자체적으로 검증하며 IdP에 확인을 요청하지 않기 때문입니다. 따라서 오프보딩은 IdP에서 계정을 비활성화한 뒤, 각 애플리케이션 내부에서 사용자나 토큰을 삭제하는 두 단계로 진행해야 합니다.

티어 배지가 실제로 의미하는 것

이 내용은 2026년 8월 기준 각 프로젝트의 자체 문서를 바탕으로 확인되었습니다. 유료 서비스 측면부터 살펴봅니다.

Grafana는 SAML을 "Grafana Enterprise 및 Grafana Cloud에서 사용 가능"하다고 명시하며, 팀 동기화 및 SCIM 프로비저닝도 함께 제공합니다. 일반 OAuth, GitHub OAuth, LDAP(Lightweight Directory Access Protocol) 및 인증 프록시는 오픈 소스 빌드에 포함되어 있으므로, 소규모로 직접 호스팅하는 사용자도 자신의 공급자를 통해 로그인할 수 있습니다. 유료화의 경계는 SSO 전체가 아닌 SAML에서 갈리며, 이는 "SSO 세금"이라는 표현이 흔히 간과하는 미묘한 차이입니다.

Metabase는 더 단호합니다. 문서에 따르면 "SAML 인증은 Pro 및 Enterprise 플랜(자체 호스팅 및 Metabase Cloud 모두)에서만 사용할 수 있습니다." 오픈 소스 에디션은 비밀번호 로그인과 LDAP만 유지합니다.

Passbolt는 SSO 문서를 Pro 및 Cloud 전용으로 표시하므로 커뮤니티 에디션에는 해당 기능이 없습니다. 문서화된 공급자로는 Keycloak과 Entra ID가 있습니다.

이제 반대편 사례를 살펴봅니다. 이 패턴이 모든 곳에 적용되는 것은 아니기 때문입니다.

GitLab Self-Managed는 SAML 페이지에 "티어: Free, Premium, Ultimate"를 명시하고 있으므로, 자체 GitLab에 대한 SAML 연동은 비용이 들지 않습니다.
Paperless-ngx는 PAPERLESS_SOCIALACCOUNT_PROVIDERS을 통해 OIDC를 구성하고, PAPERLESS_DISABLE_REGULAR_LOGIN로 로컬 로그인 폼을 숨기며, PAPERLESS_SOCIAL_ACCOUNT_SYNC_GROUPS을 사용하여 클레임을 그룹에 매핑합니다.
Planka는 OIDC_ISSUER, OIDC_CLIENT_ID, OIDC_CLIENT_SECRET을 사용하며, 기본 스코프는 openid profile email로 설정하고, OIDC_ADMIN_ROLES를 통해 역할 클레임에서 관리자를 승격합니다.
BookStack은 AUTH_METHOD=oidc으로 전환한 뒤, OIDC_USER_TO_GROUPS=true 및 OIDC_GROUPS_CLAIM을 사용하여 공급자 그룹을 자체 역할에 매핑합니다.
Vaultwarden은 기여자가 포크 버전에서 구현했던 기능을 풀 리퀘스트로 제출함에 따라, 2025년 12월 27일 1.35.0 버전에서 "OpenID Connect를 통한 SSO 지원"을 출시했습니다.
listmonk는 v4.0.0부터 사용자 역할과 함께 OIDC 로그인을 지원해 왔습니다.

이 내용을 도입을 결정하기 전에 고려하십시오. Planka 칸반 보드와 다른 자체 호스팅 Trello 대안들은 모두 동일한 방식으로 ID를 처리하지 않으며, BookStack, Wiki.js 및 Outline도 마찬가지입니다. 무료 OIDC는 스토리지 제한이나 모바일 클라이언트처럼 비교할 수 있는 하나의 기능입니다. 아직 목록을 작성 중이라면 2026년에 자체 호스팅할 것들이 합리적인 시작점이 될 것이며, Paperless-ngx 문서 관리자와 Vaultwarden 모두 현재 무료 OIDC를 제공합니다.

리버스 프록시를 애플리케이션 앞에 두는 것이 왜 싱글 사인온(SSO)이 아닌가

일반적인 우회 방법은 포워드 인증(forward auth)입니다. 리버스 프록시는 각 요청을 대기시킨 뒤, 인증 서비스에 해당 브라우저가 로그인 상태인지 확인하고, 그제야 요청을 애플리케이션으로 전달합니다. authentik은 이를 프록시 공급자(proxy provider)라고 부르며, 단일 애플리케이션을 위한 포워드 인증 모드와 도메인 전체를 위한 모드를 각각 제공합니다. Authelia와 oauth2-proxy도 동일한 역할을 수행합니다.

Caddy 사이트 블록은 authentik의 예시를 따라 다음과 같이 작성합니다.

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에서는 헤더 이름의 대소문자가 중요합니다. 이름이 일치하지 않으면 값이 비어 있는 상태로 전달되기 때문입니다. 아웃포스트(outpost)는 승인된 모든 요청에 대해 X-authentik-username, X-authentik-email, X-authentik-groups 및 몇 가지 헤더를 추가로 설정합니다.

이 방식이 제공하는 이점은 다음과 같습니다. 사용자가 먼저 아이덴티티 공급자(IdP)를 통과하지 않으면 애플리케이션에 도달할 수 없으므로, 보안 패치가 되지 않은 로그인 폼이 인터넷에 직접 노출되지 않으며 프록시 뒤의 모든 서비스에 MFA가 즉시 적용됩니다.

이 방식이 제공하지 못하는 것은 애플리케이션 내부의 아이덴티티입니다. 애플리케이션은 여전히 자체 계정 체계를 가지며 누가 로그인했는지 독자적으로 판단합니다. 모든 사용자가 프록시를 통과하여 하나의 공유 관리자 계정으로 접속한다면, 튼튼한 현관문을 가졌더라도 그 뒤에는 익명의 세션 하나만 존재하는 셈입니다. 감사 로그에는 여전히 단일 사용자 이름만 남습니다. 사용자별로 권한을 다르게 부여할 수도 없습니다. 이러한 구성을 SSO라고 부르는 것은 보안상 오류입니다. 오프보딩(offboarding) 과정이 절반만 유효하기 때문입니다. IdP에서 사용자를 삭제하면 현관문은 닫히지만, 해당 사용자가 애플리케이션 내부에서 생성한 API 토큰은 애플리케이션에 직접 접근할 수 있는 누구에게나 계속 유효하게 작동합니다.

헤더 인증을 안전하게 구성하기

일부 애플리케이션은 프록시로부터 사용자 이름을 전달받아 유료 SSO 없이도 사용자별 식별 기능을 제공합니다. 이 설정의 명칭은 프로젝트마다 다릅니다.

Grafana는 이를 auth proxy라고 부르며 기본적으로 비활성화된 상태로 제공합니다. 헤더 이름은 기본적으로 X-WEBAUTH-USER이며, 프록시가 설정하는 헤더에 맞춰 변경할 수 있습니다.

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

whitelist은 사용자가 흔히 간과하는 설정입니다. Grafana 문서에 따르면 이 설정은 사용자가 헤더를 위조하는 것을 방지하기 위해 존재하므로, 반드시 프록시의 주소만 포함해야 합니다. Gitea도 다른 명칭으로 동일한 기능을 제공하며, 더 안전한 기본값을 사용합니다.

[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의 기본값은 127.0.0.0/8,::1/128이며, REVERSE_PROXY_LIMIT은 Gitea가 신뢰할 프록시 체인의 개수를 의미합니다. 이 제한을 0으로 설정하면 헤더 처리가 완전히 비활성화됩니다.

Paperless-ngx는 PAPERLESS_HTTP_REMOTE_USER_HEADER_NAME과 함께 PAPERLESS_ENABLE_HTTP_REMOTE_USER을 제공하며, 모든 관련 설정에 적용되는 다음과 같은 경고를 문서에 명시하고 있습니다.

이 설정은 요청에 Remote-User: <username> 헤더를 추가하는 것만으로 인증을 허용합니다. 주의해서 사용하십시오!

헤더 인증을 안전하게 유지하는 두 가지 규칙은 모두 접근성과 관련이 있습니다. 첫째, 애플리케이션은 반드시 프록시를 통해서만 접근할 수 있어야 합니다. 소켓을 열 수 있는 누구나 헤더를 보내 임의의 사용자로 가장할 수 있기 때문입니다. Docker에서 ports: ["8000:8000"]은 모든 인터페이스에 포트를 노출하므로, ports: ["127.0.0.1:8000:8000"]을 사용하여 루프백 주소에 바인딩하거나, 포트 노출을 제거하고 프록시와 동일한 Docker 네트워크에 배치해야 합니다. 둘째, 프록시는 클라이언트로부터 전달된 헤더를 삭제해야 합니다. 그래야만 애플리케이션이 인증 후 프록시가 설정한 값만 수신하게 됩니다.

두 가지 사항을 모두 확인하십시오. 첫 번째 명령은 VPS 외부의 기기에서 실행하고, 두 번째 명령은 서버 자체에서 실행합니다.

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

curl 명령은 연결에 실패해야 하며, ss는 0.0.0.0:8000가 아닌 127.0.0.1:8000을 출력해야 합니다. 첫 번째 줄에 HTTP/1.1 302 Found가 출력된다면 애플리케이션이 공용 인터넷에 직접 응답하고 있다는 의미이므로, 누구나 헤더에 이름을 지정하여 임의의 사용자로 로그인할 수 있는 상태입니다.

무료 SSO가 없을 때 불평 대신 결정하기

제가 시도할 순서대로 네 가지 선택지를 제시합니다.

OIDC를 포함한 애플리케이션을 선택하십시오. 두 프로젝트가 같은 기능을 수행하는데 하나가 무료로 ID 공급자(Identity Provider)와 연동된다면, 이는 운영 비용 측면에서 실질적인 차이를 만듭니다.
정직하게 포워드 인증(forward auth)을 사용하십시오. 계정 하나와 운영자 한 명이 사용하는 관리 도구라면 앞단에 프록시를 두는 것만으로 충분하며, 애플리케이션 내부의 사용자별 ID는 아무런 이득을 주지 않습니다.
비용을 지불하십시오. 해당 애플리케이션이 업무의 핵심이고 사용자당 가격이 팀 규모에 적합하다면, 지불하는 비용은 프로젝트 유지보수에 기여하며, 그렇지 않을 경우 귀하의 저녁 시간을 대가로 치르게 됩니다.
이슈 트래커를 검색한 후 업스트림에 요청하십시오. Vaultwarden의 OIDC 지원은 기여자의 포크와 오랜 기간 이어진 풀 리퀘스트를 통해 이루어졌으므로, 작동하는 구현체가 포함된 기능 요청은 때때로 무료 에디션에 반영되기도 합니다.

이 모든 것은 자체 ID 공급자가 없으면 작동하지 않으며, 이것이 가장 먼저 구축해야 할 요소입니다. VPS에서 authentik 실행하기는 OIDC 및 SAML 공급자와 위에서 언급한 포워드 인증 아웃포스트를 제공하며, Keycloak, authentik, Zitadel 비교는 아직 결정을 내리기 어려울 때 고려해야 할 장단점을 다룹니다.

라이선스 이력과 체크리스트에 포함된 이유

마지막 체크리스트 항목은 미래에 관한 것입니다. 현재의 계층 구조는 단지 특정 시점의 스냅샷일 뿐이기 때문입니다. 잘 기록된 두 가지 사례는 상황이 양방향으로 얼마나 빠르게 변할 수 있는지 보여줍니다. HashiCorp는 2023년 8월 10일 이후의 모든 릴리스에 대해 Business Source License 1.1을 채택했으며, 이전 릴리스는 MPL 2.0(Mozilla Public License)을 유지했습니다. Redis는 2024년 3월 SSPL(Server Side Public License)로 전환했고, 2025년 5월 1일에는 Redis 8이 AGPLv3(GNU Affero General Public License)로 배포된다고 발표했습니다.

프로젝트를 기반으로 시스템을 구축하기 전에 직접 프로젝트의 이력을 확인하십시오.

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

주로 초기 임포트 시점의 커밋으로 구성된 짧은 목록은 좋은 신호입니다. 라이선스 파일이 여러 번 다시 작성되었다면, 현재 약관을 기준으로 계획을 세우기 전에 각 커밋 메시지를 반드시 읽어봐야 합니다.

FAQ

SSO 세금이란 무엇입니까?

SSO 세금이란 제품의 나머지 기능은 무료이거나 저렴하게 제공하면서, 싱글 사인온(SSO) 기능을 프리미엄 기능으로 분류하여 추가 비용을 청구하는 관행을 의미합니다. 자체 호스팅 소프트웨어의 경우, 라이선스 키 없이 실행할 수 있는 오픈 소스 애플리케이션임에도 OIDC나 SAML 로그인은 유료 티어에 포함되어 있는 형태가 이에 해당합니다. 이 명칭은 sso.tax의 'SSO 수치스러운 벽(SSO Wall of Shame)'에서 유래했으며, 해당 사이트는 SSO 기능에 과도한 프리미엄을 부과하는 공급업체들을 추적합니다. 자체 호스팅 사용자가 겪는 결과는 모든 앱이 각자의 사용자 데이터베이스를 유지하게 되어, 계정을 수동으로 생성하고 삭제해야 한다는 점입니다.

포워드 인증(forward auth)을 사용하는 리버스 프록시는 SSO와 동일합니까?

아닙니다. 포워드 인증은 정문(front door)을 보호합니다. 즉, 요청이 애플리케이션에 도달하기 전에 프록시가 ID 공급자(identity provider)를 통해 확인을 거칩니다. 하지만 그 뒤에 있는 앱은 여전히 자체 계정 시스템을 사용하므로, 모든 사용자가 하나의 공유 로그인 페이지에 도달하게 되면 단일 익명 세션이 생성되고 감사 로그에는 한 명의 이름만 남게 됩니다. Grafana의 auth proxy, Gitea의 reverse proxy authentication, Paperless-ngx의 PAPERLESS_ENABLE_HTTP_REMOTE_USER 설정처럼 앱이 헤더에서 사용자 이름을 읽어올 때만 진정한 사용자별 ID 식별이 가능해집니다. 이러한 설정은 프록시를 통하지 않고는 앱에 접근할 수 없을 때만 안전합니다. 헤더는 어떤 클라이언트든 보낼 수 있는 일반 문자열이기 때문입니다.

어떤 자체 호스팅 앱이 무료 버전에서 OIDC를 지원합니까?

2026년 8월 기준 프로젝트 문서를 확인한 결과는 다음과 같습니다. Paperless-ngx, Planka, BookStack, Gitea, listmonk, Vaultwarden은 모두 무료 빌드에서 OIDC를 지원하며, GitLab Self-Managed는 SAML을 Free 티어에 포함하고 있습니다. Grafana의 오픈 소스 빌드는 자체 발급자를 대상으로 하는 일반 OAuth를 처리하지만, SAML은 Enterprise 기능입니다. 이러한 목록은 소프트웨어 릴리스에 따라 변경될 수 있으므로, 설치하기 전에 반드시 해당 프로젝트의 인증 관련 페이지를 확인하십시오.

싱글 사인온을 잠금 해제하는 티어에 비용을 지불해야 합니까?

두 가지 수치를 기준으로 결정하십시오. 계정이 필요한 사람이 몇 명인지, 그리고 수동으로 관리해야 할 앱이 몇 개인지가 기준입니다. 관리자가 한두 명뿐이라면 로컬 계정 앞단에 포워드 인증을 두는 것만으로 충분하며 유료 티어의 이점은 거의 없습니다. 팀원들의 입퇴사가 잦은 환경이라면, 퇴사 처리 과정에서 누락된 계정 하나가 라이선스 비용보다 더 큰 비용을 초래할 수 있으며, 지불하는 비용은 사용 중인 소프트웨어의 유지보수를 지원하는 역할을 합니다. 만약 가격이 적절하지 않다면, OIDC를 지원하지 않는 앱을 우회해서 사용하기보다 OIDC를 기본으로 포함하는 앱을 선택하는 것이 실용적인 해결책입니다.

#sso#oidc#saml#licensing #self-hosting #authentik