🔑 SSO 구축, 오픈소스 Keycloak으로 정말 10분 만에 가능할까?

   +-------+
   |       |
   |  Key  |🔑-----> [🔑] App 1
   | (SSO) |
   |       |-----> [🔑] App 2
   +-------+
             -----> [🔑] App 3

 

매일 아침 출근해서 수십 개의 업무 시스템에 로그인하느라 소중한 시간을 낭비한 경험, 다들 한 번쯤 있으시죠? 저 역시 회사에서 신규 플랫폼을 론칭하며 통합 인증 시스템을 리딩했던 경험이 있는데요, 흩어져 있는 계정을 하나로 묶어 사용자 경험을 높이는 것이 얼마나 중요한지 절실히 깨달았습니다[1].

 

이때 필요한 기술이 바로 SSO(Single Sign-On) 입니다. 과연 복잡해 보이는 SSO 환경을 어떻게 효율적으로 구축할 수 있을까요? 이 글을 다 읽고 나면 오픈소스를 활용한 SSO 구축의 A to Z를 이해하게 될 겁니다.

 

⚡ TL;DR

• SSO(Single Sign-On)는 한 번의 인증으로 여러 서비스에 연동하여 로그인할 수 있게 해주는 기술입니다
• 오픈소스 솔루션인 Keycloak을 활용하면 복잡한 인증 서버를 아주 빠르게 구축하고 운영할 수 있습니다

목차

1. 배경: 우리는 왜 SSO를 도입해야 할까?
2. 핵심 개념: SSO는 어떻게 동작할까?
3. 실습: Keycloak으로 10분 만에 SSO 서버 띄우기
4. 모범 사례: 실패하지 않는 SSO 구축 전략
5. 마치며 & 참고자료

---

1. 배경: 우리는 왜 SSO를 도입해야 할까?

기업이 성장하고 서비스가 다양해지면서 사용자는 여러 개의 아이디와 비밀번호를 관리해야 하는 불편함을 겪습니다. 이는 사용자 경험을 저해할 뿐만 아니라, IT 관리자에게는 보안 및 계정 관리의 부담을 가중시킵니다[2].

SSO는 이러한 문제를 해결하기 위해 등장했습니다. 하나의 계정으로 모든 서비스에 접근할 수 있게 함으로써 사용자의 편의성을 극대화하고, 인증 포인트를 일원화하여 강력한 보안 정책을 적용할 수 있게 됩니다[2][3].

 

SSO를 이해하기 위해 알아야 할 몇 가지 기본 용어입니다.

• ✅ SSO (Single Sign-On): 단일 계정 로그인으로 여러 시스템에 접근할 수 있게 하는 통합 인증 체계[3][6].
• ✅ IdP (Identity Provider): 'ID 공급자'로, 사용자의 신원을 저장하고 인증을 직접 수행하는 중앙 서버. 예: Keycloak, Okta, Google 계정 [5].
• ✅ SP (Service Provider): '서비스 제공자'로, 사용자가 최종적으로 이용하려는 애플리케이션이나 웹사이트[5].
• ✅ OAuth 2.0 & OpenID Connect (OIDC): SSO를 구현할 때 가장 널리 쓰이는 표준 프로토콜. OAuth 2.0은 '권한 부여'를, OIDC는 그 위에 '인증' 기능을 추가한 스펙입니다[1][4].

2. 핵심 개념: SSO는 어떻게 동작할까?

SSO는 인증을 전담하는 서버(IdP)와 개별 서비스(SP) 간의 신뢰 관계를 기반으로, 인증 토큰을 통해 사용자의 로그인 상태를 안전하게 공유하는 메커니즘입니다[5][8].

 

동작 흐름은 생각보다 간단합니다. 사용자가 처음 로그인할 때만 인증을 거치고, 그 뒤로는 보이지 않는 곳에서 IdP와 SP가 통신하며 사용자를 대신해 인증을 처리해줍니다.

1. 사용자가 App 1 (SP)에 로그인을 시도합니다.
2. App 1은 사용자가 인증되지 않았음을 확인하고, 인증 서버(IdP)의 로그인 페이지로 사용자를 보냅니다.
3. 사용자는 인증 서버(IdP)에 아이디와 비밀번호를 입력하여 인증을 받습니다.
4. 인증에 성공하면, 인증 서버는 SSO 토큰(인증 증표)을 발급하여 사용자를 다시 원래의 App 1으로 보냅니다[5].
5. App 1은 전달받은 SSO 토큰을 검증하고, 사용자에게 로그인 권한을 부여합니다.
6. 이제 사용자가 App 2에 접근하면, App 2는 다시 인증 서버(IdP)에 확인을 요청합니다. 이때 사용자는 이미 인증 서버에 로그인된 상태이므로, 별도의 로그인 절차 없이 즉시 SSO 토큰이 발급되고 App 2에 로그인됩니다.

3. 실습: Keycloak으로 10분 만에 SSO 서버 띄우기

SSO를 직접 구축하려면 인증 서버부터 만들어야 합니다[4][8]. 상용 솔루션도 있지만, Red Hat이 후원하는 강력한 오픈소스 Keycloak을 사용하면 빠르고 유연하게 구축할 수 있습니다[4].

① 인증 서버 선택: 왜 Keycloak인가?

SSO 서버를 선택할 때 고려했던 기준은 다음과 같습니다[4].

• SSO, OAuth 2.0, OpenID Connect 표준 프로토콜 지원
• 빠른 구축 가능성 및 무료 라이선스
• 성숙도와 활발한 사용자 커뮤니티

Spring Authorization Server 등 다른 대안도 있었지만, Keycloak은 8년 이상의 역사를 통해 문서와 레퍼런스가 풍부하고, GUI 기반의 편리한 관리 콘솔, 2단계 인증(MFA) 등 강력한 부가 기능을 기본 제공하여 최종 선택하게 되었습니다[4].

② Keycloak 설치 및 기본 설정

Docker가 설치되어 있다면 단 한 줄의 명령어로 Keycloak 개발 서버를 실행할 수 있습니다.

# Docker를 사용해 개발 모드로 Keycloak 서버 실행
# 실행 후 http://localhost:8080 에서 관리자 콘솔에 접근 가능
docker run -p 8080:8080 -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak:latest start-dev

# 출력 결과:
# ... (서버 로그) ...
# Keycloak 2x.x.x on JVM (powered by Quarkus ...) started in X.XXXs.
# Listening on: http://0.0.0.0:8080

서버 실행 후 http://localhost:8080으로 접속하여 위에서 설정한 admin/admin 계정으로 로그인하면 관리자 콘솔을 만날 수 있습니다. 여기서 SSO와 관련된 모든 설정을 할 수 있습니다[4].

• Realm: Keycloak의 가장 큰 관리 단위. 서비스별로 Realm을 분리하여 사용자와 클라이언트를 독립적으로 관리할 수 있습니다. master Realm은 Keycloak 자체 관리를 위해 사용되므로, 새로운 Realm을 생성해야 합니다[4].
• Client: 우리의 애플리케이션(SP)을 의미합니다. SSO 연동을 원하는 서비스들을 클라이언트로 등록합니다[4].
• User: 로그인할 사용자 계정입니다[4].

③ 샘플 앱 연동 테스트

이제 실제 애플리케이션과 연동해볼 차례입니다. Keycloak 관리자 콘솔에서 다음 단계로 간단히 연동 설정을 할 수 있습니다.

1. 새로 생성한 Realm에서 Clients 메뉴로 이동해 Create client 버튼을 클릭합니다.
2. Client ID에 서비스 명을 입력하고, Valid Redirect URIs에 로그인 성공 후 돌아올 애플리케이션 주소(예: http://localhost:3000/*)를 등록합니다.
3. Users 메뉴에서 테스트용 사용자를 생성합니다.
4. 이제 준비된 샘플 애플리케이션에서 Keycloak으로 로그인을 시도하면, 우리가 만든 Realm의 로그인 페이지로 이동했다가 인증 성공 후 다시 애플리케이션으로 돌아오는 SSO 흐름을 확인할 수 있습니다[7].

4. 모범 사례: 실패하지 않는 SSO 구축 전략

Keycloak은 강력하지만, 모든 상황에 맞는 만능 해결책은 아닙니다. 성공적인 SSO 도입을 위해 몇 가지 패턴과 장단점을 알아두면 좋습니다.

패턴	장점	주의점
오픈소스(Keycloak) 활용	빠른 구축, 비용 절감, 풍부한 기능(GUI, MFA 등), 커뮤니티를 통한 문제 해결 용이[4].	특정 비즈니스 로직(예: 복잡한 회원가입 절차) 구현이 까다롭고, 민감 데이터 암호화를 별도로 처리해야 할 수 있음[4].
프로필 서버 분리	Keycloak이 지원하지 않는 커스텀 로직이나 데이터 암호화를 별도 서버에서 처리하여 유연성을 확보할 수 있음[4].	전체 아키텍처의 복잡도가 증가하고 관리 포인트가 늘어남[4].
인증 위임 모델	대상 서비스의 인증 로직을 수정하기 어려울 때, 에이전트가 대신 로그인 정보를 전달하여 연동[6].	에이전트가 각 서비스의 계정 정보를 모두 알아야 하므로 관리 부담이 있음.
MFA 결합	SSO 로그인 시 OTP 등 2차 인증을 필수로 설정하여 보안 수준을 대폭 강화할 수 있음[5].	로그인 단계가 추가되어 사용자 편의성이 약간 저하될 수 있음.

5. 마치며

오늘 우리는 SSO의 개념부터 오픈소스 Keycloak을 활용한 실전 구축 방법까지 알아보았습니다.

• SSO는 단일 인증으로 여러 서비스에 접근하게 하여 사용자 경험과 관리 효율을 동시에 잡는 핵심 기술입니다.
• 오픈소스 Keycloak은 강력한 기능과 빠른 구축 속도를 제공하는 매우 훌륭한 SSO 솔루션입니다.
• 하지만 실제 프로젝트에서는 Keycloak의 한계를 이해하고, 프로필 서버 분리와 같은 유연한 아키텍처 설계를 함께 고민해야 합니다.

실제 프로젝트에 적용할 때는 Production 환경을 위한 외부 DB 연결, HTTPS 설정, 그리고 서비스 특성에 맞는 Realm/Client 분리 전략을 반드시 수립해야 합니다[4].

 

❤️ 글이 도움이 되셨다면 하트와 댓글로 응원해주세요! 궁금한 점은 언제든지 질문 남겨주시면 답변드리겠습니다.

---

참고자료

• Keycloak 공식 문서 (https://www.keycloak.org/guides)
• AWS의 SSO 소개 자료 (https://aws.amazon.com/ko/what-is/sso/) [5]
• Microsoft Entra의 SSO 배포 계획 가이드 (https://learn.microsoft.com/ko-kr/entra/identity/enterprise-apps/plan-sso-deployment) [9]

[1] https://velog.io/@ddkds66/SSO-%EA%B5%AC%EC%B6%95%EA%B8%B0-SSO-Model-%EC%84%A4%EA%B3%84%EC%99%80-SSO-OAuth-2.0-OpenID-Connect-Protocol%EC%9D%98-%EC%9D%B4%ED%95%B4
[2] https://play-with.tistory.com/362
[3] https://gsretail.tistory.com/13
[4] https://velog.io/@ddkds66/SSO-%EA%B5%AC%EC%B6%95%EA%B8%B0-Authorization-Server-%EC%84%A0%EC%A0%95%EA%B3%BC-%ED%94%84%EB%A1%9C%ED%95%84-%EC%84%9C%EB%B2%84-%EA%B5%AC%EC%B6%95
[5] https://aws.amazon.com/ko/what-is/sso/
[6] https://drg2524.tistory.com/192
[7] https://devocean.sk.com/blog/techBoardDetail.do?ID=167060&boardType=techBlog
[8] https://brunch.co.kr/@sangjinkang/36
[9] https://learn.microsoft.com/ko-kr/entra/identity/enterprise-apps/plan-sso-deployment
[10] https://www.cloudflare.com/ko-kr/learning/access-management/what-is-sso/