💡 글의 핵심 3줄 요약

1. 홈서버에 서비스가 5개만 넘어가도 서비스마다 따로 만든 계정과 비밀번호가 관리 지옥을 만들고, 보안 수준도 제각각이 됩니다.
2. 오픈소스 IdP인 Authentik을 쓰면 한 번의 로그인으로 모든 셀프호스팅 서비스에 접근하는 SSO 환경을 만들 수 있고, MFA도 한 곳에서만 설정하면 됩니다.
3. OIDC를 지원하는 앱은 표준 연동으로, 자체 로그인이 없는 앱은 프록시 인증으로 감싸는 두 가지 패턴만 익히면 대부분의 서비스를 커버할 수 있습니다.

홈서버 SSO 구축기: Authentik으로 통합 로그인 만들기

홈서버를 운영하다 보면 서비스가 하나둘 늘어나는 재미가 쏠쏠합니다. 미디어 서버, 사진 백업, 문서 관리, 모니터링 대시보드까지 붙이다 보면 어느새 컨테이너가 열 개를 훌쩍 넘죠. 그런데 어느 날 문득 이런 생각이 듭니다. "잠깐, 나 지금 로그인 계정이 몇 개지?"

서비스마다 따로 만든 관리자 계정, 어떤 건 비밀번호를 재활용했고, 어떤 건 2단계 인증이 있고 어떤 건 없고, 가족에게 사진 서버를 공유해주려니 또 새 계정을 만들어야 하고... 편하자고 시작한 셀프호스팅이 계정 관리 지옥이 되는 순간입니다. 회사에서는 구글 워크스페이스나 Okta로 한 번 로그인하면 모든 사내 서비스에 들어가지는데, 내 홈서버라고 그렇게 못 할 이유가 있을까요? 오늘은 오픈소스 IdP(Identity Provider)인 Authentik으로 홈서버에 SSO(Single Sign-On)를 구축하는 이야기를 해보겠습니다.

홈서버에 SSO가 필요한 진짜 이유

"집에서 혼자 쓰는데 SSO까지 필요해?"라고 생각하실 수 있습니다. 저도 처음엔 그랬는데요, 계정이 흩어져 있을 때의 문제는 단순히 귀찮음에서 끝나지 않습니다.

첫째, 보안 수준이 가장 약한 서비스에 맞춰집니다. 외부에 노출된 서비스가 10개인데 그중 하나라도 약한 비밀번호에 2단계 인증이 없다면, 공격자에게는 그 하나가 곧 입구입니다. SSO를 도입하면 인증이라는 관문을 한 곳으로 모으고, 그 관문에만 MFA(다중 인증)와 강력한 정책을 집중할 수 있습니다.

둘째, 사용자 관리가 한 곳으로 모입니다. 가족이나 친구에게 서비스를 공유할 때 서비스마다 계정을 파주는 대신, IdP에 사용자 한 명을 추가하고 그룹으로 권한을 나눠주면 끝입니다. 반대로 접근을 끊을 때도 한 곳에서 계정만 비활성화하면 모든 서비스에서 즉시 차단됩니다.

셋째, 자체 로그인이 아예 없는 서비스도 보호할 수 있습니다. 모니터링 도구나 간단한 웹 UI 중에는 인증 기능이 없는 것들이 꽤 있는데, 뒤에서 설명할 프록시 인증을 쓰면 이런 앱 앞에도 로그인 화면을 세울 수 있습니다.

Authentik이란? 홈랩의 사실상 표준이 된 오픈소스 IdP

Authentik은 셀프호스팅할 수 있는 오픈소스 통합 인증 서버입니다. OIDC(OpenID Connect), OAuth2, SAML, LDAP 같은 표준 프로토콜을 폭넓게 지원해서, 기업용 IdP가 하는 일 대부분을 홈서버에서 재현할 수 있습니다. 비슷한 선택지로 Keycloak이나 Authelia도 있지만, Authentik은 웹 UI에서 거의 모든 설정이 가능하고 애플리케이션 연동 마법사가 잘 되어 있어서 홈랩 커뮤니티에서 사실상 표준처럼 자리 잡았습니다.

배포는 여느 셀프호스팅 서비스처럼 Docker Compose로 이루어집니다. 구성 요소는 크게 서버(웹 UI와 API), 워커(백그라운드 작업), 그리고 PostgreSQL과 Redis입니다. 컨테이너 네 개짜리 스택이라 무겁지 않을까 걱정할 수 있는데, 미니 PC급 홈서버라면 부담 없이 돌아가는 수준입니다.

Authentik의 개념 몇 가지만 미리 알아두면 설정이 훨씬 수월합니다. 사용자가 로그인할 때 거치는 단계들을 플로우(Flow)라고 부르고, 각 서비스와의 연결은 프로바이더(Provider)와 애플리케이션(Application)의 쌍으로 표현됩니다. 처음엔 용어가 낯설지만, "서비스 하나 = 애플리케이션 하나 + 프로바이더 하나"라는 공식만 기억하면 됩니다.

연동 패턴 두 가지: OIDC 표준 연동과 프록시 인증

홈서버 서비스를 Authentik에 붙이는 방법은 크게 두 갈래입니다. 어떤 앱이냐에 따라 골라 쓰면 됩니다.

패턴 1: OIDC를 지원하는 앱은 표준 연동으로

요즘 인기 있는 셀프호스팅 앱들은 대부분 OIDC 로그인을 지원합니다. 사진 백업 서버, 문서 관리 도구, Grafana 같은 대시보드가 대표적이죠. 이런 앱들은 Authentik에서 OAuth2/OIDC 프로바이더를 만들고, 발급된 클라이언트 ID와 시크릿을 앱 설정에 넣어주면 연동이 끝납니다. 이후 앱의 로그인 화면에 "Authentik으로 로그인" 버튼이 생기고, 이미 Authentik에 로그인된 상태라면 클릭 한 번에 들어가집니다.

표준 연동의 장점은 앱이 사용자 정보를 제대로 넘겨받는다는 점입니다. 사용자 이름, 이메일, 그룹 정보까지 전달되므로 앱 안에서의 권한 구분(관리자/일반 사용자)도 IdP 그룹으로 제어할 수 있습니다.

패턴 2: 인증이 없는 앱은 프록시 인증으로 감싸기

문제는 자체 로그인이 없거나 OIDC를 지원하지 않는 앱들입니다. 이럴 때 쓰는 것이 프록시 인증인데요, 리버스 프록시가 요청을 앱에 전달하기 전에 Authentik에게 "이 사람 로그인했어?"라고 먼저 물어보는 방식입니다. 로그인이 안 된 요청은 Authentik 로그인 화면으로 보내지고, 인증된 요청만 앱에 도달합니다. Traefik, Nginx, Caddy 같은 주요 리버스 프록시 모두 이 방식(포워드 인증)을 지원하고, Authentik 쪽에서는 프록시 프로바이더를 만들어주기만 하면 됩니다.

이미 리버스 프록시로 HTTPS를 구성해둔 분이라면, 기존 설정에 미들웨어 몇 줄을 추가하는 정도의 작업입니다. 인증 기능이 전혀 없던 앱 앞에 MFA까지 갖춘 로그인 관문이 생기는 셈이니, 투자 대비 효과가 가장 큰 패턴이라고 생각합니다.

도입할 때 주의할 점들

장밋빛 이야기만 할 수는 없겠죠? 실제로 구축하면서 부딪히기 쉬운 지점들도 짚어두겠습니다.

먼저 IdP는 단일 장애점(SPOF)이 됩니다. Authentik이 죽으면 모든 서비스에 로그인할 수 없게 되므로, 관리자 계정 하나 정도는 각 서비스의 로컬 계정으로 남겨두는 비상구 전략이 필요합니다. 데이터베이스 백업도 필수입니다. 사용자, 연동 설정이 전부 PostgreSQL에 들어 있으니, 기존에 운영하는 백업 체계에 반드시 포함시키세요.

또 하나, 한 번에 모든 서비스를 옮기려고 하지 마세요. 가장 자주 쓰는 서비스 한두 개로 시작해서 플로우와 프로바이더 개념에 익숙해진 뒤 점진적으로 확장하는 편이 정신 건강에 좋습니다. 특히 프록시 인증은 웹소켓이나 API 경로 예외 처리 같은 미세 조정이 필요한 경우가 있어서, 서비스별로 하나씩 검증하며 진행하는 것을 추천합니다.

마지막으로 MFA는 도입 첫날부터 켜는 것을 권합니다. 통합 로그인은 편리함과 동시에 "계정 하나가 뚫리면 전부 뚫린다"는 뜻이기도 하니까요. Authentik은 TOTP 앱은 물론 패스키(WebAuthn)도 지원하므로, 지문이나 보안 키로 로그인하는 쾌적한 환경을 만들 수 있습니다.

결론: 계정 지옥에서 벗어나는 가장 확실한 투자

홈서버 취미의 묘미는 회사 인프라에서나 보던 것들을 내 손으로 직접 굴려보는 데 있다고 생각합니다. SSO는 그중에서도 배우는 것과 실용성을 동시에 챙길 수 있는 주제입니다. OIDC와 포워드 인증이 어떻게 동작하는지 몸으로 익히게 되고, 그 결과물로는 매일 쓰는 통합 로그인이라는 편의가 남으니까요.

서비스가 늘어날수록 계정 관리의 고통은 커지기만 합니다. 주말 하루를 투자해서 Authentik을 세워보세요. 한 번의 로그인으로 모든 서비스의 문이 열리는 경험을 하고 나면, 예전으로 돌아가고 싶지 않아질 겁니다.