방송자는 웹에서 이미 로그인했는데 OBS에서 다시 로그인해야 할까요. C++ 플러그인에 OAuth를 넣으면 브라우저 열기, 콜백 처리, 토큰 갱신을 추가해야 합니다. 반대로 SRT URL과 비밀을 통째로 복사하게 하면 화면 공유나 로그에 비밀이 남을 수 있습니다.
저는 웹의 로그인 상태를 활용해 8자·10분·일회용 코드로 OBS를 연결하는 방식을 선택했습니다. 매 방송마다 설정을 반복하지 않는 것이 목표였으므로, 온보딩 때 코드 한 번을 입력하는 방식은 허용할 수 있었습니다. 최초 연결 1회와 매 방송 반복 설정 0회를 구분한 뒤 연결 절차를 좁혔습니다.
짧은 코드는 장기 자격증명을 전달하는 한 번의 창구였습니다
로그인한 방송자가 웹에서 코드를 발급받아 OBS에 입력하면, 플러그인은 Auth에서 이를 계정의 송출 설정으로 교환합니다. 코드는 짧은 시간 뒤 만료되거나 사용 처리되고, 실제 방송에 쓰는 자격증명과는 다른 수명을 갖습니다.
| 대안 | 추가되는 책임 | 판단 |
|---|---|---|
| OBS에서 OAuth 전체 구현 | 브라우저·콜백·토큰 갱신 | 당시 구현 범위에 비해 큼 |
| SRT URL 한 줄 복사 | URL에 섞인 비밀의 노출 | 기각 |
| 웹 로그인 + 일회용 코드 | 발급·교환·만료·시도 제한 | 기존 인증을 활용하는 방식으로 채택 |
이것은 표준 OAuth Device Flow를 그대로 구현한 것이 아니라 기존 웹 계정과 플러그인을 연결하는 자체 페어링 계약입니다. 따라서 짧은 코드 형태만 가져오지 않고 발급·교환·폐기 조건도 직접 정해야 했습니다.
입력을 줄인 대신 서버의 제한 조건을 함께 정했습니다
코드는 Crockford Base32 8자를 XXXX-XXXX로 표시하고 10분 뒤 만료되도록 했습니다. 발급 계정에 묶이며, 성공한 코드는 다시 교환할 수 없습니다. 짧은 코드에 대한 추측 시도도 제한해야 합니다.
| 계약 | 정한 값 또는 동작 |
|---|---|
| 형식·수명 | 8자, 10분 |
| 재사용 | 한 번 교환한 코드 거부 |
| 발급 제한 | 계정당 분당 3회 |
| 교환 제한 | IP당 분당 5회 |
| 계정 바인딩 | 발급 계정의 자격증명만 반환 |
길이와 제한 횟수를 정하는 것만으로는 충분하지 않았습니다. 프록시 뒤에서 실제 요청자 IP를 구분하지 못하면 IP별 제한이 공용 제한처럼 동작할 수 있습니다. 시도 기록을 제한 창보다 빨리 정리하면 제한의 근거도 사라집니다. 그래서 최신 계약에는 신뢰할 프록시·전달 헤더 설정과 기록 보존 조건을 함께 다루도록 보강했습니다. 실패 누적에 따른 추가 차단은 아직 구현된 기능이 아닙니다.
일회용 코드를 사용 직후 삭제하지 않은 이유
사용한 코드를 거절하는 것과 DB 행을 즉시 지우는 것은 다른 결정입니다. 사용 기록이 남아 있어야 같은 코드를 다시 입력했을 때 “이미 사용했다”는 이유를 응답할 수 있습니다. 최신 계약은 만료 뒤 1시간 보존하고 10분 간격으로 정리하는 기준입니다.
정리 뒤에는 재사용 사유를 구분할 기록이 없어질 수 있지만, 코드가 다시 유효해지는 것은 아닙니다. 사용된 코드와 존재하지 않는 코드를 모두 거절하더라도 사용자에게 설명할 수 있는 이유는 달라집니다. 보존 기간은 어떤 실패를 얼마 동안 설명할 수 있는지까지 정하는 값이었습니다.
팀 연동에서 확인한 것은 교환·재사용 거부·파일 권한입니다
OBS 팀 PR #179에는 웹에서 발급한 코드의 교환 성공, 동일 코드 재사용 시 409, macOS 설정 파일의 0600 권한을 확인한 기록이 있습니다. 플러그인 구현과 실측은 팀원이 맡았고, 저는 연결 흐름과 서버의 입력·응답 계약을 조율했습니다. 위의 전체 계약과 실제 연동에서 확인한 항목을 구별해 보고 있습니다.
passphrase는 전체 SRT URL 대신 별도 연결 필드로 전달하도록 했고, streamid에는 사용자명·이메일을 넣지 않았습니다. 둘은 SRT에서도 다른 옵션이며 플러그인의 전달 방식은 PR에서 확인할 수 있습니다.
당시 개발 Auth 경로는 HTTP였고, 로컬 송출은 passphrase가 꺼진 조건이었습니다. 따라서 HTTPS와 계정별 암호가 연결된 전체 송출은 별도 구현·검증 과제로 남았습니다. 페어링이 성공했다고 그 뒤의 전송 보호까지 확인된 것은 아닙니다.
방송자의 반복 설정을 줄이는 대신 서버가 책임질 일은 더 구체적이 됐습니다. 코드의 만료와 재사용, 계정 귀속, 시도 제한과 기록 보존을 함께 정해야 한 번의 입력이 안전하게 송출 설정으로 이어질 수 있었습니다. 짧은 코드를 고른 이유와 그 대가를 같이 다뤄야 플러그인에 인증 절차를 더 넣지 않은 선택을 설명할 수 있습니다.