Jitsi 채팅방 생성 권한을 특정 인증 사용자에게만 제한하는 방법

2026년 10월 6일 현재, Jitsi의 최신 자체 호스팅 안내서는 인증된 사용자만 회의실을 생성하고 게스트는 이후에 참여할 수 있도록 하는 목표를 여전히 지지합니다. 그러나 안내서에서는 기존의 "보안 도메인" 절차를 신규 설치 시 더 이상 사용하지 않도록 권장하고 토큰 기반 인증을 권장합니다. 올바른 설정 방법은 Jitsi 설치 방식에 따라 다릅니다. 이 가이드는 Docker 배포를 위한 직접적인 내부 인증 경로를 제공하고, 새로운 Debian 또는 Ubuntu 설치를 위한 최신 방향을 설명합니다.

이러한 설정은 누가 방을 시작할 수 있는지를 관리합니다. 모든 방을 자동으로 비공개로 만드는 것은 아닙니다. 방 비밀번호, 대기실, 초대 절차는 별도의 설정입니다.

인증 경로를 선택하세요

전개	실용적인 선택	그것이 제어하는 것
공식 Docker Compose 배포	Prosody에서 내부 인증을 활성화하고 계정을 프로비저닝하세요.	본인이 생성한 계정만 회의를 시작할 수 있으며, 게스트 참여는 설정 가능합니다.
새로운 Debian 또는 Ubuntu 배포	Jitsi의 최신 토큰 인증 가이드를 따르세요. 해당 가이드의 예제에서는 Keycloak을 사용합니다.	사용자 인증 절차에서 유효한 토큰을 받은 사용자만 회의를 시작할 수 있습니다.
기존 설치는 이전 보안 도메인 설정을 사용합니다.	업그레이드를 계획하는 동안에는 기존 구성으로만 유지하세요.	기존의 인증된 호스트와 익명 게스트 분리 방식

최신 Jitsi 인증 가이드에서는 익명 게스트를 사용한 인증된 회의실 생성 방법을 설명하고 있으며, 이전 보안 도메인 페이지 에서는 해당 방법이 새 설치에서는 더 이상 사용되지 않는다고 명시적으로 언급하고 있습니다. 설치 방법에 맞는 가이드를 확인하지 않고 이전 Prosody 또는 Jicofo 설정을 최신 환경에 복사하지 마십시오.

Docker: 프로비저닝된 사용자만 룸을 시작할 수 있도록 허용

이 절차는 Jitsi Meet이 공식 Docker Compose 프로젝트에서 이미 실행 중이고 해당 .env파일을 편집할 수 있다고 가정합니다. 아래 예제는 내장 internal인증 모드를 사용합니다. 공개 가입 페이지는 추가되지 않으며, 관리자가 허용된 계정을 생성하고 삭제합니다.

1. 환경 변수 파일에서 인증을 활성화합니다.

Jitsi Compose 배포에 사용되는 파일을 엽니다 .env. 다음과 같이 인증 변수를 설정하세요.

어두운 설정 편집기 화면에 Jitsi .env 파일에 ENABLE_AUTH=1, ENABLE_GUESTS=1, AUTH_TYPE=internal이 표시됩니다. — Docker 환경 설정에서 인증을 활성화하고, 게스트 액세스를 허용하며, 내부 계정을 선택하는 값입니다.

ENABLE_AUTH=1
ENABLE_GUESTS=1
AUTH_TYPE=internal

주석으로 시작하는 줄이 아니라 활성 설정인지 확인하세요 #. 를 사용하면 ENABLE_GUESTS=1인증된 사용자가 회의를 시작한 후 로그인하지 않은 사용자도 게스트로 참여할 수 있습니다. 모든 참가자가 인증을 거치도록 하려면 를 설정하세요. 이렇게 하면 ENABLE_GUESTS=0회의실 생성 권한이 아닌 회의 참여 권한도 변경됩니다.

Docker 가이드에는 이러한 변수와 내장 계정 워크플로에 대한 설명이 있습니다. 지원되는 인증 유형 및 옵션의 최신 목록은 Docker의 인증 섹션을 참조하십시오.

2. 설정을 적용합니다.

Compose 파일이 있는 디렉터리에서 업데이트된 환경을 적용하세요. Compose는 구성이 변경된 서비스를 다시 생성합니다.

docker compose up -d

계정을 생성하기 전에 컨테이너가 실행 중인지 확인하십시오. 사용자 지정 Compose 프로젝트, 다른 프로젝트 이름 또는 오케스트레이션 레이어를 사용하는 경우 두 번째 Jitsi 스택을 시작하는 대신 해당 배포에 대한 업데이트를 실행하십시오.

3. 승인된 각 방 호스트별로 계정을 생성하세요.

Prosody 컨테이너에서 셸을 엽니다.

docker compose exec prosody /bin/bash

다음으로 기본 Docker XMPP 도메인에 Jitsi 사용자를 등록합니다.

터미널 창에 Docker 구성 경로와 meet.jitsi의 예시 계정 host1을 사용하는 Prosody 계정 등록 명령이 표시됩니다. — 계정 등록 명령은 내부 사용자를 생성합니다. 명령을 실행할 때 선택한 사용자 이름과 암호를 입력하십시오.

prosodyctl --config /run/prosody/config/prosody.cfg.lua register <username> meet.jitsi <strong-password>

두 자리 표시자를 해당 사용자의 사용자 이름과 고유한 비밀번호로 바꾸십시오. 꺾쇠괄호(<)는 포함하지 마십시오. 두 번째 인증된 호스트의 경우 다른 사용자 이름을 사용하여 명령을 다시 실행하십시오. 표시된 명령은 기본 Docker 도메인을 사용합니다 meet.jitsi. 도메인을 변경한 경우 XMPP_DOMAIN배포에 구성된 도메인을 따르십시오. 최신 Docker 가이드에는 Prosody 컨테이너 명령과 관련 제거 명령에 대한 설명이 있습니다.

사용자 권한을 취소하려면 Prosody 컨테이너에 접속하여 다음 명령을 실행하십시오.

prosodyctl --config /run/prosody/config/prosody.cfg.lua unregister <username> meet.jitsi

회의를 시작할 수 있는 권한이 있는 사람만 계정 목록에 추가하세요. 회의실 이름은 접근 제어 수단이 아니므로, 호스트가 더 이상 계정 접근 권한이 필요하지 않으면 해당 권한을 제거해야 합니다.

4. 호스트 경로와 게스트 경로를 각각 테스트합니다.

기존 Jitsi 로그인 세션으로 인해 결과가 가려지지 않도록 개인 정보 보호 모드 브라우저 창이나 별도의 브라우저 프로필을 사용하세요. 공개 Jitsi URL을 열고 인증 없이 새 회의실을 시작해 보세요. 새 회의를 할당하기 전에 인증이 필요할 것입니다. 생성한 계정 중 하나로 로그인하여 회의실을 시작한 다음 회의실이 열리는지 확인하세요.

간단한 회의 로그인 패널에는 사용자 이름과 비밀번호 입력란이 있으며, 호스트로서 회의를 생성하려면 로그인이 필요하다는 안내가 표시됩니다. — 일반적인 로그인 화면은 승인된 호스트가 회의실을 만들기 전에 나타나야 하는 인증 단계를 보여줍니다.

다음으로, 인증되지 않은 별도의 브라우저 세션에서 회의실 링크를 엽니다. 게스트 액세스가 활성화된 경우, 인증된 호스트가 회의를 시작하면 게스트도 회의에 참여할 수 있습니다. Jitsi의 Docker 가이드에 따르면 게스트 액세스가 활성화된 경우 인증되지 않은 사용자는 사용자가 인증할 때까지 기다려야 합니다.

회의 대기 화면에는 참가자가 호스트를 기다리고 있으며 회의가 아직 시작되지 않았다고 표시됩니다. — 인증된 호스트를 기다리는 게스트는 회의실 생성과 게스트 참여의 차이점을 보여줍니다.

새로운 Debian 또는 Ubuntu 설치의 경우, 최신 토큰 인증 가이드를 참조하십시오.

Jitsi의 최신 자체 호스팅 핸드북은 토큰 인증을 사용하는 새로운 인증 경로를 제공합니다. 문서화된 예제는 Jitsi를 Keycloak에 연결하고, Prosody 호스트에서 토큰을 요구하도록 구성하며, 게스트 접속을 허용해야 하는 경우 익명 게스트 도메인을 추가합니다. Jitsi 구성에서 문서화된 설정은 기본 호스트에 `/etc/jitsi.gov/main/user/name`을 사용 authentication = "token"하고 게스트 도메인을 `/etc/jitsi.gov/main/user/name`으로 매핑합니다 . Keycloak 영역, 클라이언트 리디렉션 URL, 역방향 프록시 라우팅, Prosody 및 Jitsi 웹 클라이언트 설정에 대한 전체 인증 가이드를 참조하십시오 . 모든 예제 호스트 이름을 사용자 환경에 맞게 변경하고 ID 공급자 엔드포인트는 HTTPS로 보호해야 합니다.allow_empty_token = falsejitsi-anonymous

토큰 인증은 계정을 ID 공급자가 관리해야 하거나 애플리케이션에서 회의실별 액세스 토큰을 발급해야 할 때 유용합니다. 이를 위해서는 올바르게 구성된 발급자와 토큰 유효성 검사가 필요하며, 단순히 브라우저 설정에서 토큰 인증을 활성화하는 것만으로는 회의실 생성을 안전하게 제한할 수 없습니다. Docker에서 LDAP 기반 계정이 필요한 경우 Docker 가이드에 LDAP 모드에 대한 설명이 있지만, LDAP 연결, 인증서 및 필터 설정이 디렉터리와 일치해야 합니다.

방 생성은 방 개인 정보 보호와 별개입니다.

인증은 "누가 회의를 시작할 수 있습니까?"라는 질문에 대한 답을 제공합니다. 하지만 "누가 이 회의실에 입장할 수 있습니까?"라는 질문에는 답이 되지 않습니다. 게스트 입장이 허용된 경우, 회의실 URL을 얻은 사람은 누구나 회의에 참여를 시도할 수 있습니다. 초대된 참가자만 입장할 수 있도록 회의실 비밀번호를 설정하거나 대기실을 구성하는 것이 좋습니다. Jitsi의 자체 호스팅 가이드에서는 서버 수준에서 회의를 시작하는 기능과 개별 회의실에서 관리되는 접근 제어를 구분하여 설명합니다.

점검해야 할 일반적인 문제점

익명으로 룸을 생성하는 기능은 여전히 작동합니다.ENABLE_AUTH=1 실행 중인 Compose 프로젝트에서 사용하는 환경 파일에서 해당 기능이 활성화되어 있는지 확인한 후 구성을 다시 적용하세요.
모든 참가자에게 로그인 메시지가 표시됩니다. 이 설정이 비활성화되어 있는지 확인하세요 ENABLE_GUESTS. 해당 설정이 비활성화되어 있으면 참가자는 인증을 거쳐야 합니다. 하지만 인증된 호스트만 참여하고 게스트 참가자만 받는 구성이라면 이 설정은 필요하지 않습니다.
새 계정으로 로그인할 수 없습니다. 배포에 구성된 도메인에 계정을 등록했는지 확인하십시오. Docker의 기본 명령은 를 사용하며 meet.jitsi, 사용자 지정 XMPP 도메인에는 해당 값이 필요합니다.
게스트는 호스트보다 먼저 입장할 수 없습니다. 이는 게스트 액세스 동작과 일치합니다. 인증된 호스트가 먼저 회의실을 시작한 다음 게스트에게 회의실 링크를 사용하도록 요청하십시오.
다른 설치 유형의 튜토리얼을 따르는 경우: Debian 패키지 경로, Docker에서 생성된 구성, 그리고 이전의 보안 도메인 코드 조각을 혼합해서 사용하지 마십시오. 설치 설명서의 해당 섹션을 참조하고, 사용 중단 예정 사항을 확인하십시오.

검증 체크리스트

인증되지 않은 브라우저는 새 방을 만들 수 없습니다.
권한이 부여된 사용자는 로그인하여 채팅방을 시작할 수 있습니다.
삭제된 계정은 더 이상 인증할 수 없습니다.
게스트 참여는 ENABLE_GUESTS설정에 따라 의도된 대로 작동합니다.
개인 회의에도 필요한 경우 회의실 비밀번호 또는 로비 이용 정책이 적용됩니다.

핵심 결정 사항은 Jitsi 인스턴스에서 개별적으로 프로비저닝된 내부 계정을 사용할지, 아니면 ID 공급자를 통해 발급된 토큰을 사용할지 여부입니다. 기존 Docker Compose 배포의 경우, 내부 인증은 등록된 소수의 사용자만 회의실을 생성할 수 있도록 제한하는 직접적인 방법입니다. 새 설치의 경우, 최신 토큰 인증 가이드를 참조하여 회의실 수준의 접근 제어를 별도로 구성하십시오.