RealtimeKit 참가 토큰 유효시간 지원: 갱신·회수와 재입장 차단 설계
11월 12일 공개된 RealtimeKit 참가 토큰의 시작·만료 시각과 개별 회수를 살펴본다. 갱신 후 기존 토큰 유지, 회수 전파 지연, 서버의 재발급 차단과 예약 변경 검증 항목을 정리한다.
회의 참가 권한과 유효시간을 표현한 생성형 개념 이미지다. 실제 RealtimeKit 화면은 아니다.
예약한 화상회의가 끝난 뒤에도 같은 참가 토큰을 계속 쓸 수 있다면, 회의 시간표만 바꾸는 것으로 접근을 막을 수 없다. 이제 Cloudflare RealtimeKit에서는 참가 토큰의 시작·만료 시각을 지정하고, 특정 토큰만 폐기할 수 있다. 다만 토큰 갱신이 기존 토큰을 무효화하지는 않는다.
Cloudflare는 November 12, 2026 이 변경을 발표했다. 예약 수업·면접·상담처럼 참가 가능한 시간이 정해진 서비스라면 적용 가치가 있다. 이 글은 공식 API와 문서를 바탕으로 발급·갱신·회수의 경계를 정리한다. 공식 변경 공지
1. 기본값이 자동으로 짧아진 것은 아니다
기존 연동에서 새 필드를 생략하면 발급 시점부터 100일 동안 유효한 토큰을 받는다. 업데이트됐다는 이유만으로 현재 서비스의 참가 가능 시간이 짧아졌다고 생각하면 안 된다.
백엔드가 참가자를 추가할 때 요청의 token 객체에 not_before와 expires_on을 넣는다. 값은 시간대가 있는 RFC 3339 문자열이다. 유효구간은 시작 포함·종료 제외이며, 최대 100일이다. 만료 시각은 미래여야 한다. 반환된 시각은 UTC로 확인한다. 참가자 추가 API
아래는 한국 시간 December 1, 2026 15:00부터 한 시간 동안 참가를 허용하려는 예제 요청 본문이다. 실제 서비스 호출 결과가 아니라 문서에 맞춘 예시다.
이 본문은 다음 엔드포인트로 보내는 참가자 추가 요청에 해당한다.
참가자 추가에는 공식 공지에 명시된 Realtime Admin 또는 Realtime 권한이 필요하다. 관리용 API 토큰은 서버에 두고, 프런트엔드에는 해당 사용자의 참가 토큰만 전달하는 구조로 설계한다. 발급 전에 애플리케이션 로그인과 해당 회의의 참가 자격을 확인해야 한다.
2. 갱신과 회수를 따로 설계한다
갱신 API는 같은 참가자에 새 토큰을 발급한다. 이때 기존 토큰은 자신의 만료 시각까지 유효하다. 새 토큰을 받았다는 사실만으로 유출된 이전 토큰을 차단했다고 판단하면 안 된다.
갱신 요청에서는 유효시각을 참가자 추가의 token 객체와 달리 요청 본문에 지정한다. 반환값의 새 토큰과 UTC 유효시각을 저장할 때도 기존 토큰을 폐기했는지는 별도로 관리한다. 갱신 API
토큰 하나를 폐기할 때는 다음 경로에 DELETE 요청을 보내고, 본문에 대상 참가 토큰을 전달한다.
다른 토큰은 유지된다. 폐기 반영은 모든 위치에서 최대 60초 걸릴 수 있으므로, 즉시 전체 참가 토큰을 차단해야 한다면 참가자 삭제가 공식 안내의 선택지다. 참가자 삭제는 현재 세션에서 제거하는 효과도 있으므로 운영 화면에서 단일 토큰 회수와 구분해야 한다. 참가 토큰 개념·회수 문서 · 참가자 삭제 API
3. 예약 취소와 연장은 서버 정책까지 연결한다
다음은 새 기능을 적용할 때의 설계 권고다. Cloudflare가 자동으로 처리해 주는 기능이라고 해석하지 않는다.
- 예약 취소: 서비스의 참가 자격을 먼저 취소하고, 그 뒤 공급자 측 토큰도 회수한다. 참가 자격을 남겨두면 사용자가 새 토큰을 발급받는 경로가 생길 수 있다.
- 회의 연장: 연장 승인 여부를 서버가 확인한 뒤 새 유효구간으로 발급한다. 브라우저가 임의로 보낸 종료 시각을 그대로 신뢰하지 않는다.
- 정기 회의: 회의 하나와 여러 회차를 구분한다. 다음 회차의 입장 권한을 언제 줄지 정하고, 넓은 유효기간을 무심코 재사용하지 않는다.
- 감사 기록: 토큰 원문 대신 내부 사용자 식별자, 회의·참가자 식별자, 발급/회수 시각과 결과를 남긴다. 일반 로그·분석 도구에 인증 토큰이 유출되지 않게 한다.
custom_participant_id는 앱의 사용자와 참가자를 연결하는 식별자다. 그 값 자체가 접근 제어를 수행하지 않는다. 이메일·전화번호 대신 내부 식별자를 쓰라는 공식 권고도 함께 적용한다. 참가자 식별자 안내
4. 배포 전에 확인할 경계
운영 데이터를 쓰지 않는 별도 테스트 회의에서 다음을 검증한다.
- 시작 직전에는 입장이 거부되고, 시작 이후 정상적으로 참가하는가.
- 종료 시각 이후의 새 입장·재접속이 차단되는가.
- 갱신 뒤 이전 토큰이 계속 유효한 조건을 테스트로 기록했는가.
- 토큰 하나를 폐기해도 다른 토큰은 유지되는지, 회수 전파 지연을 감안했는가.
- 참가자 삭제 후 모든 관련 토큰의 접근과 현재 연결 상태를 확인했는가.
- 취소된 사용자의 신규 발급·갱신 요청을 앱 서버도 거부하는가.
만료·시작 전·회수된 토큰은 입장 전에 거부되며, 공식 문서는 이 거부된 참가에 과금하지 않는다고 설명한다. 이것을 정상 참가나 다른 기능까지 무료라는 뜻으로 넓히면 안 된다. 공식 공지
특히 토큰 만료와 진행 중인 회의의 정확한 종료 동작을 같은 것으로 가정하지 않는다. 입장 제한, 재접속, 현재 연결 종료를 각각 검증해야 한다. 이 글에서는 실제 RealtimeKit API 호출, 토큰 발급·폐기, 회의 접속 테스트를 하지 않았다. 요청 예시와 서비스 동작은 공식 문서에 근거하며, 운영 검증 항목은 이를 바탕으로 한 권고다.
유효시간 지정은 필요한 기능이지만 완전한 참가 권한 모델을 대신하지 않는다. 발급 전 권한 확인과 회수 후 재발급 차단까지 연결해야, 회의 일정과 실제 접근 가능 시간을 일치시킬 수 있다.