Keycloak 토큰 설계 실수 7가지와 실무 보안 아키텍처 정리 (JWT, Scope, Audience, RBAC)

Keycloak은 설치만으로 인증 서버가 동작하지만,
그 상태는 단순히 **“로그인 가능한 시스템”**일 뿐이다.

실무에서 중요한 것은
👉 “어떤 토큰을, 누구에게, 어떤 범위로 발급할 것인가”

이 설계가 잘못되면 다음 문제가 발생한다.

• 토큰 탈취 시 장시간 악용
• 권한 과다 노출
• 서비스 간 인증 오남용
• 관리자 권한 유출

즉, Keycloak의 핵심은 설정이 아니라
👉 토큰 설계 + 권한 모델링 + 검증 전략이다.

---

📌 Keycloak에서 흔히 하는 설계 실수 7가지

---

1. Access Token 만료 시간을 길게 설정

가장 흔한 실수다.

Access Token: 8시간 / 24시간

 

이렇게 설정하면 토큰 탈취 시 피해가 그대로 유지된다.

👉 해결

• Access Token: 5~15분
• Refresh Token: 별도 관리
• 관리자 계정: 더 짧게

👉 핵심
“토큰 만료 시간 = 공격자가 쓸 수 있는 시간”

---

2. Refresh Token을 사실상 영구 세션처럼 사용

많은 시스템이 refresh token을 무제한처럼 사용한다.

문제:

• 탈취 시 재발급 계속 가능
• 세션 강제 종료 어려움

👉 해결

• Refresh Token 재사용 제한
• Logout 시 refresh token 폐기
• 비밀번호 변경 시 세션 전체 무효화

---

3. JWT에 너무 많은 정보 넣기

나쁜 설계:

 

{
"name": "홍길동",
"department": "개발팀",
"menu": ["A", "B", "C"],
"roles": ["ADMIN"],
"permissions": [...]
}

 

문제:

• 토큰 크기 증가
• 내부 정보 노출
• 권한 변경 반영 지연

👉 해결

• JWT는 최소 정보만
  • userId
  • role
  • scope

👉 핵심
JWT는 “프로필 저장소”가 아니라 “인가 판단용 증표”

---

4. Audience(aud) 검증을 안 함

이거 실무에서 진짜 많이 터집니다.

상황:

• A 서비스용 토큰
• B 서비스에서도 통과됨

👉 문제
토큰 오남용 (서비스 간 침범)

👉 해결

• 서비스별 audience 설정
• API에서 aud 검증 필수

issuer + signature + exp + aud

 

👉 핵심
“이 토큰이 나를 위한 것인가?”를 반드시 확인

---

5. Full Scope Allowed 켜둠

Keycloak 기본 설정 중 하나인데,
이걸 그대로 두면 거의 “권한 무제한” 상태입니다.

문제:

• 필요 없는 role까지 토큰에 포함
• 권한 과다 노출

👉 해결

• Full Scope Allowed OFF
• Client별 Scope 명확히 정의

예:

order.read
order.write
admin.user.manage

 

---

6. Redirect URI / Web Origins 느슨하게 설정

개발할 때 이렇게 많이 합니다.

*
https://*.domain.com/*

 

👉 문제

• 토큰 탈취 가능
• 인증 리디렉션 공격

👉 해결

https://app.company.com/*
https://admin.company.com/callback

 

👉 핵심
화이트리스트는 최대한 좁게

---

7. Public / Confidential Client 구분 안 함

잘못된 설계:

• SPA인데 secret 사용
• 서버인데 public client 사용

👉 올바른 기준

유형                                                                                  방식

SPA / 모바일	Public + PKCE
백엔드	Confidential
서비스 간	Client Credentials

👉 핵심
클라이언트 유형 = 인증 방식

---

📌 실무 Keycloak 아키텍처 설계

---

구조

[ Client (Web / App) ]
↓
[ Keycloak ]
↓
[ API Gateway ]
↓
┌───────────────┬───────────────┐
│ Order Service │ Payment │
└───────────────┴───────────────┘

 

---

인증 흐름

1. Client → Keycloak 로그인
2. Access Token 발급
3. API 호출 시 Bearer Token 전달
4. Gateway / Service에서 검증

---

📌 권장 설계 (실무 기준)

---

1. Client 구성

frontend-client (public)
admin-client (public)
api-client (confidential)

 

---

2. 토큰 정책

Access Token: 10분
Refresh Token: 회전 방식
SSO Session: 제한

 

---

3. 권한 모델

Realm Role → 최소 (ADMIN)
Client Role → 서비스별 권한
Scope → API 접근 단위
Group → 조직

 

---

4. Token 최소화

 

{
"sub": "userId",
"roles": ["USER"],
"scope": "order.read"
}

 

---

5. API 검증 정책

모든 서비스에서:

• 서명 검증
• issuer 검증
• 만료 시간
• audience
• scope/role

👉 여기서 aud 빠지면 설계 실패

---

📌 실무 적용 체크리스트

---

필수

• Access Token 짧게 설정
• Refresh Token 회전/회수
• Full Scope Allowed OFF
• Redirect URI 제한
• Audience 설정
• Role 최소화

---

권장

• API Gateway에서 1차 검증
• 서비스별 scope 분리
• 관리자 MFA 적용
• 세션 정책 정의

---

📌 결론

Keycloak은 “인증 서버”가 아니라
👉 보안 아키텍처의 중심 컴포넌트다

 

설치만으로 끝내면:

👉 로그인 시스템

설계를 제대로 하면:

👉 엔터프라이즈 IAM 플랫폼

---

📌 한 줄 정리

👉 “토큰을 어떻게 발급하고 검증하느냐가 시스템 보안을 결정한다”