Jellyfin OIDC PR 보류 — 구현보다 인증 기반 정비가 먼저

AI 요약

Jellyfin에 OIDC 로그인을 추가하는 대규모 PR이 보류된 상황을 두고 r/selfhosted에서 논의가 이어졌습니다. 논점은 OIDC 기능 자체의 필요성보다 인증 코드를 어디에 두고, 서버와 클라이언트가 외부 인증을 어떤 방식으로 지원할지에 있습니다.

PR의 기술적 변경

PR 대화에는 마이그레이션 순서와 OIDC 클레임 처리에 관한 수정이 기록돼 있습니다. 브랜치 생성 뒤 master에 마이그레이션 세 개가 추가되면서 OIDC 마이그레이션 날짜가 앞서 정렬됐고, 모델 스냅샷에 OIDC 엔터티가 빠졌습니다. 문서화된 명령으로 마이그레이션을 다시 생성해 날짜를 마지막 순서로 옮겼습니다. 생성된 스키마는 네임스페이스를 제외하면 이전 마이그레이션과 같았고, 스냅샷의 ProductVersion은 고정된 Entity Framework Core 버전인 10.0.11로 바뀌었습니다.

또 다른 문제는 iss 클레임 처리였습니다. OpenIdConnectOptions는 기본 설정에서 iss를 삭제했고, 사용자 정보 엔드포인트 사용 여부와 관계없이 핸들러가 클레임 작업을 실행했습니다. 외부 ID는 provider, issuer, subject를 기준으로 묶이므로, iss가 빠지면 ValidateExternalIdentity가 로그인을 거부했습니다. 기존 단위 테스트는 설정된 인증 파이프라인 대신 ClaimsPrincipal을 직접 만들어 이 오류를 잡지 못했습니다. PR 대화에서는 이미 authority metadata로 검증한 iss 삭제 작업을 제거하고, 사용자 정보 엔드포인트 설정 두 경우를 모두 실제 provider 옵션으로 테스트하자는 수정이 제안됐습니다.

병합을 미루는 이유

유지보수팀 쪽 의견은 OIDC를 단독 기능으로 서버 코어에 바로 넣기보다 인증 기반부터 정리하자는 것입니다. PR은 46개 파일에 6,000줄이 넘는 변경을 담았고, OIDC 전용 컨트롤러와 관리자, DTO, ID 테이블까지 추가합니다. 팀은 이런 구현을 코어에 넣으면 유지보수 부담이 커지고, SAML 같은 다른 인증 방식을 지원할 때 별도 시스템을 다시 만들어야 한다고 우려합니다.

전직 프로젝트 리더라고 밝힌 참여자는 팀의 기존 논의를 설명했습니다. Jellyfin의 사용자 인증은 기본 기능에 머물러 있어 SSO를 제대로 지원하려면 사용자 관리와 인증 기반, 플러그인이 쓸 API와 ABI, 모든 앱에서 재사용할 프런트엔드 체계부터 마련해야 한다는 입장입니다. 따라서 기능 제안과 작은 PR을 단계별로 제출하고, 사용자 관리·인증 기반부터 쌓아야 한다고 설명했습니다. 한 번에 전체 OIDC 스택을 추가하는 단일 PR은 적절한 진행 방식이 아니라고 덧붙였습니다.

플러그인과 클라이언트의 과제

토론 참여자들은 플러그인 방식 자체보다 플러그인과 클라이언트 사이의 표준 계약이 없다는 점을 문제로 꼽았습니다. 인증 플러그인은 이미 OIDC를 구현할 수 있지만, 네이티브 클라이언트가 외부 인증 제공자를 발견하고 로그인 절차를 시작할 공통 방식은 부족합니다. 그 결과 웹 UI에서는 동작해도 TV 앱에서는 QuickConnect 같은 우회 방식이나 플러그인별 예외 처리가 필요하다는 지적이 나왔습니다.

한 참여자는 코어에 범용 외부 인증 API를 두고, 플러그인은 OIDC나 SAML 같은 프로토콜을 맡기는 방안을 제안했습니다. 인증 제공자가 사용자 신원과 그룹·권한 정보를 반환하고, 코어가 이를 Jellyfin 권한과 라이브러리 접근 권한에 연결하는 계약도 필요하다고 했습니다. TV 등 네이티브 클라이언트에는 RFC 8628의 Device Authorization Grant나 QuickConnect 기반 흐름이 필요하지만, 현재 PR 범위에는 들어 있지 않다는 의견도 있었습니다. 다른 참여자는 클라이언트가 로그인 링크나 QR 코드를 요청하는 코어 API만 있어도 Apple TV 사용자가 휴대전화로 로그인하는 흐름을 만들 수 있다고 제안했습니다.

Reddit 반응

• @u/Shane75776 — PR이 준비됐다는 이유만으로 유지보수하기 어려운 시스템을 병합할 수는 없습니다. 팀은 왜 병합하지 않는지, 받아들일 수 있는 형태로 만들려면 무엇을 해야 하는지 합리적으로 설명했습니다. 지금 병합하면 OIDC가 아닌 각 인증 제공자마다 큰 시스템을 만들어야 합니다. 그래서 코어에 제대로 된 인증 API를 넣어 제공자마다 별도 시스템을 만들지 않으려는 것입니다.
  • @u/clintkev251 — 이 기능을 정말 원하지만 제대로 만드는 편이 낫습니다. 인증 기반 정비가 실제로 우선순위에 오르길 바랍니다.
  • @u/destruction90 — 제목은 더 나은 걸 골랐어야 했습니다. 죄송합니다. 개발자들이 왜 그렇게 판단했는지 충분히 이해하고, 이 프로젝트를 유지보수하는 사람들이 결정권을 가져야 합니다. 다만 당분간 기능을 기대하기 어렵다는 점이 아쉽고, 많은 사용자가 바라던 진행 상황도 아닙니다.
• @u/Aussie6869 — Jellyfin 12.0용 OIDC 플러그인 가운데 하나를 유지보수하는 입장에서, OIDC를 구현하기 전에 서버 인증 백엔드를 정리하고 클라이언트 동작도 추가해야 한다는 유지보수팀 의견에 동의합니다. Jellyfin 쪽에 엔드포인트와 데이터 저장소가 없어 특정 동작과 연동에 제약을 겪고 있습니다.
• @u/angellus — 플러그인 방식이 프로젝트를 건강하게 유지하는 데 더 낫다는 점에는 동의합니다. 다만 실제 문제는 외부 인증 체계가 아직 없다는 것입니다. 외부 인증, forward auth, OIDC, LDAP 가운데 하나를 먼저 구현한 뒤 플러그인 시스템을 만들고 그 구현을 플러그인으로 분리해야 한다고 봅니다. 집에서는 Authentik으로 인증을 통합하고, 외부 사용자가 접속하는 서비스에는 OIDC나 OAuth 로그인을 쓰기 때문에, 자체 계정만 추가하는 방식은 제 환경에서 받아들이기 어렵습니다.
  • @u/Unhappy_Purpose_7655 — 플러그인 방식에는 강하게 반대합니다. 인증은 기반 기능이어야지, 지원이 계속될지 알 수 없는 플러그인으로 붙이면 안 됩니다.
  • @u/coderstephen — 외부 플러그인으로 만들지는 않더라도, 코드 구조를 정리하려고 내부 인증 플러그인 형태로 두는 건 좋겠습니다.
• @u/Crib0802 — mTLS 지원은 어떻게 되나요? 공식 클라이언트에 추가하면 좋겠습니다.

원문: Reddit / 번역·요약: Trawling