Keycloak — 인증 시스템의 허브
인증 생태계의 큰 그림에서 디렉터리·IdP·프로토콜을 구분했다면, 이제 그중 Keycloak이 놓이는 자리를 좁혀 본다. 앱마다 비밀번호를 직접 확인하게 두지 않고 로그인과 세션은 Keycloak에 모은다. 사용자는 어디에서 왔든 Keycloak realm의 사용자로 정리되고, 앱은 같은 방식으로 받은 토큰을 검증한다. 다만 토큰의 신원과 claim을 실제 권한으로 바꾸어 요청을 허용하는 마지막 판단은 앱이나 API가 맡는다.
이 장에서 처음 나오는 말5개
IdPIdentity Provider- 사용자를 인증하고 그 결과를 앱이 확인할 수 있게 전달하는 신원 제공자. 이 덱에서는 Keycloak이 이 역할을 맡는다.
SSOSingle Sign-On- 한 IdP의 로그인 세션을 이용해 여러 앱에 다시 자격 증명을 입력하지 않고 로그인하는 방식.
realm- 사용자·역할·앱·로그인 정책을 함께 묶어 다른 영역과 격리하는 Keycloak의 관리 단위.
User Federation- Keycloak이 LDAP 같은 외부 사용자 저장소에서 계정을 찾고 자격 증명 검증을 맡기는 연결 방식.
Identity Brokering- Keycloak이 다른 IdP로 사용자를 보내 인증받고, 돌아온 신원 정보를 자기 realm에 연결하는 방식.
이 장에서 답할 질문
섹션 제목: “이 장에서 답할 질문”- 앱이 디렉터리에 직접 붙는 대신 Keycloak을 두면 무엇이 달라지는가?
- 로컬 사용자·User Federation·Identity Brokering은 어디에서 신원을 가져오는가?
- Keycloak의 인증 결과는 어디까지이며, 최종 접근 허용은 누가 결정하는가?
앱에서 인증을 떼어낸다
섹션 제목: “앱에서 인증을 떼어낸다”앱마다 LDAP 연결과 로그인 화면을 만들 수도 있다. 하지만 앱 수만큼 비밀번호 처리 지점, 로그인 세션, MFA와 감사 정책이 생긴다. 새 앱을 붙일 때마다 같은 보안 문제를 다시 풀어야 하고, 한 앱의 구현 실수가 사내 자격 증명을 노출할 수도 있다.
Keycloak을 IdP로 두면 사용자는 Keycloak의 로그인 경로에만 자격 증명을 내고, 앱은 사용자를 Keycloak으로 보낸 뒤 인증 결과를 토큰으로 받는다. 같은 realm의 Keycloak 세션을 여러 앱이 사용하므로 한 번 인증한 사용자는 앱마다 비밀번호를 다시 입력하지 않아도 된다.
| 앱별 직접 인증 | Keycloak으로 중앙화 |
|---|---|
| 앱마다 디렉터리 연결과 비밀번호 처리를 구현 | 자격 증명 처리는 Keycloak의 인증 경로에 모음 |
| 앱마다 로그인·MFA 정책과 세션을 따로 관리 | 공통 로그인 정책과 SSO 세션을 realm에서 관리 |
| 앱이 외부 저장소의 속성과 구조를 알아야 함 | Keycloak 사용자 모델과 token claim만 알면 됨 |
| 로그인 기록과 실패 지점이 앱마다 흩어짐 | 인증 이벤트와 정책 적용 지점이 Keycloak에 모임 |
Keycloak이 맡는 일과 맡지 않는 일
섹션 제목: “Keycloak이 맡는 일과 맡지 않는 일”Keycloak은 로그인 요청을 받아 사용자의 신원을 확인하고, realm 안의 사용자·그룹·역할 모델로 정리한다. 인증에 성공하면 SSO 세션을 만들고, 연결된 앱인 client에 서명된 OIDC 토큰이나 SAML assertion을 발급한다. 앱은 Keycloak의 공개키와 token claim을 이용해 결과를 검증한다. realm·user·client의 관계는 Keycloak 26.7의 core concepts에서 공식 정의를 확인할 수 있다.
인증과 최종 인가는 같은 일이 아니다. Keycloak이 groups나 role 같은 claim을 발급해도,
“이 사용자가 이 API 작업을 해도 되는가”는 그 API나 앱의 권한 규칙이 결정한다. 따라서 사용자가
인증됐다는 사실만으로 모든 앱 접근이 허용되지는 않는다.
신원이 들어오는 세 경로
섹션 제목: “신원이 들어오는 세 경로”세 경로는 사용자의 원본과 자격 증명을 검증하는 위치가 다르지만, 인증 뒤에는 같은 realm의 사용자 모델과 token 발급 경로로 모인다.
| 경로 | 신원과 자격 증명의 원본 | 로그인 때 일어나는 일 | 이 덱에서의 위치 |
|---|---|---|---|
| 로컬 사용자 | Keycloak | Keycloak이 저장한 자격 증명을 직접 검증 | realm·client·OIDC·SSO를 먼저 익히는 출발점 |
| User Federation | LDAP/AD 같은 외부 사용자 저장소 | Keycloak이 외부 저장소에서 사용자를 찾고 자격 증명 검증을 맡김 | Samba AD 호환 디렉터리를 LDAPS로 붙이는 기본 실습 |
| Identity Brokering | OIDC·SAML을 말하는 외부 IdP | 브라우저를 외부 IdP로 보내 인증받고, 돌아온 신원을 realm 사용자에 연결 | 다른 IdP가 이미 있을 때 선택하는 심화 경로 |
Keycloak 26.7 Server Administration Guide는 외부 저장소의 데이터를 공통 사용자 모델로 매핑한 뒤 token claim으로 내보내는 User Federation 흐름을 설명한다. 반면 Identity Brokering은 외부 IdP가 인증하고 Keycloak이 그 결과를 내부 앱에 다시 전달하는 중계 관계다.
이 덱의 본선과 심화 범위
섹션 제목: “이 덱의 본선과 심화 범위”본선은 작은 흐름부터 확장한다. 먼저 Keycloak 로컬 사용자로 realm과 client, OIDC 로그인, 앱 두 개의 SSO, API 인가를 확인한다. 그다음 Samba AD 호환 디렉터리를 LDAPS User Federation으로 붙이고, 외부 그룹이 Keycloak 모델과 token claim을 거쳐 API 권한이 되는 두 매핑을 추적한다. Samba 실습 결과는 Microsoft AD DS나 Windows 도메인에서 검증한 결과로 일반화하지 않는다.
Identity Brokering·SAML·service account·oauth2-proxy·Kubernetes OIDC는 Keycloak 전체에서의 자리와 선택 기준을 배우는 심화 경로다. Kerberos/SPNEGO 데스크톱 SSO도 기본 LDAP/LDAPS 실습 뒤의 선택 주제다. 심화 항목은 별도 실습이 실제로 검증된 경우에만 재현 절차로 다룬다.
- Keycloak은 여러 신원 원본의 인증을 realm으로 모으고, 앱에는 검증 가능한 token을 발급한다.
- 로컬 사용자는 Keycloak이 직접 검증하고, User Federation은 외부 저장소에 검증을 맡기며, Identity Brokering은 외부 IdP의 인증 결과를 받아들인다.
- Keycloak은 신원과 claim을 제공하지만, 최종 요청 허용은 앱이나 API가 결정한다.
- 이 덱의 본선은 로컬 사용자에서 시작해 LDAP/LDAPS Federation과 그룹→claim→API 권한으로 이어진다.