14. CIAM과 API 보안의 모든 것
로그인 화면은 견고하게 지켜도 API 엔드포인트는 허술한 경우가 많습니다. CIAM 환경에서 공격자는 이미 브라우저 인증 흐름보다 API를 직접 노리는 방향으로 이동했습니다. 모바일 앱·파트너 연동·서드파티 클라이언트까지 고려하면, CIAM의 API 보안은 고객 데이터를 지키는 최후의 방어선입니다.
이 글에서는 OAuth 2.0·OIDC 플로우 선택 기준, JWT vs Opaque Token 비교, PKCE 구현 원리, 토큰 관리 전략, Rate Limiting 설계, OWASP API Security Top 10과 CIAM의 연관성, Bot 탐지까지 실무 관점에서 완전히 정리합니다.
1. CIAM API 보안의 위협 지형
CIAM은 본질적으로 외부에 공개된 접점이 많은 시스템입니다. 인증 엔드포인트, 프로파일 API, 토큰 발급 서버—이 모두가 잠재적 공격 표면입니다.
| 위협 유형 | 공격 방식 | 주요 대응 |
|---|---|---|
| 크리덴셜 스터핑 | 유출된 계정 목록으로 로그인 API 자동 공격 | Rate Limiting, MFA, IP 차단 |
| 토큰 탈취 | 네트워크 가로채기, 로컬 스토리지 탈취 | HTTPS 강제, 짧은 토큰 유효기간, HttpOnly 쿠키 |
| CSRF | 인증된 사용자의 브라우저를 통한 위조 요청 | PKCE, SameSite 쿠키, CSRF 토큰 |
| 토큰 재사용 | 만료된 또는 폐기된 토큰으로 접근 시도 | 토큰 블랙리스트, 즉시 폐기 메커니즘 |
| Bot 자동 가입 | 가입 API를 자동화 툴로 대량 호출 | CAPTCHA, 행동 기반 Bot 탐지 |
| 과도한 데이터 노출 | API가 필요 이상의 사용자 정보를 반환 | 응답 필드 최소화, 필드 레벨 인가 |
2. OAuth 2.0 플로우 선택 기준
OAuth 2.0은 인가 위임 프레임워크이고, OIDC는 그 위에 인증을 추가한 표준입니다. 어떤 플로우를 선택하느냐가 API 보안의 출발점입니다.
| 플로우 | 사용 환경 | 현재 권장 여부 | 비고 |
|---|---|---|---|
| Authorization Code + PKCE | 웹 앱, 모바일 앱, SPA | ✅ 현재 표준 권장 | 모든 퍼블릭 클라이언트 필수 |
| Client Credentials | 서버 간 통신 (M2M) | ✅ 권장 | 사용자 없는 백엔드 서비스 간 인가 |
| Device Code | TV·IoT 등 입력 제한 기기 | ✅ 권장 (해당 환경만) | QR 코드 또는 단순 코드 입력 방식 |
| Implicit Flow | 구형 SPA (레거시) | ❌ 사용 금지 | 토큰이 URL에 노출. RFC 9700으로 폐기 |
| Resource Owner Password | 레거시 직접 로그인 | ❌ 사용 금지 | 비밀번호를 클라이언트에 직접 전달. 피싱 위험 |
React·Vue 같은 SPA(Single Page Application)와 모바일 앱은 클라이언트 시크릿을 안전하게 보관할 수 없는 퍼블릭 클라이언트입니다. 이 환경에서 PKCE 없이 Authorization Code Flow를 사용하거나, Implicit Flow를 사용하면 Authorization Code 탈취 공격에 취약합니다. 반드시 PKCE를 함께 적용해야 합니다.
3. PKCE — Authorization Code Flow 보안 강화
PKCE(Proof Key for Code Exchange, 픽시)는 Authorization Code를 탈취당해도 공격자가 Access Token으로 교환할 수 없도록 막는 보안 메커니즘입니다.
- 클라이언트가 무작위 문자열
code_verifier생성 (43~128자) code_verifier를 SHA-256 해싱하여code_challenge생성- 인가 요청 시
code_challenge와code_challenge_method=S256을 함께 전송 - 인가 서버가
code_challenge를 임시 저장 후 Authorization Code 발급 - 토큰 교환 시 클라이언트가 원본
code_verifier전송 - 인가 서버가
code_verifier를 해싱하여 저장된code_challenge와 비교 → 일치 시에만 토큰 발급
핵심 보안 효과: 공격자가 Authorization Code를 가로채더라도 원본 code_verifier를 알 수 없으므로, 탈취된 코드로 토큰 교환이 불가능합니다. 퍼블릭 클라이언트(모바일 앱·SPA)에서 PKCE는 선택이 아닌 필수입니다.
4. JWT vs Opaque Token 비교
토큰 형식 선택은 API 보안 설계의 핵심 의사결정입니다. 두 방식은 트레이드오프가 명확합니다.
| 구분 | JWT (JSON Web Token) | Opaque Token |
|---|---|---|
| 구조 | Header.Payload.Signature 구조. Base64 인코딩 | 무작위 문자열. 의미 없는 참조자(Reference) |
| 검증 방식 | 공개키로 서명 검증. 서버 조회 불필요 | 인가 서버에 매번 조회 필요 (Token Introspection) |
| 성능 | 로컬 검증으로 빠름 | 서버 조회로 인한 지연 발생 |
| 폐기 | 만료 전 즉시 폐기 어려움 (블랙리스트 필요) | 인가 서버에서 즉시 폐기 가능 |
| 정보 노출 | Payload가 Base64 디코딩 가능. 민감 정보 포함 금지 | 토큰 자체에 정보 없음. 안전 |
| 적합 환경 | 마이크로서비스 간 통신, 분산 환경 | 보안 민감 서비스, 즉시 폐기 필요 환경 |
Access Token은 JWT로 발급하여 마이크로서비스 간 빠른 검증에 활용하되, 유효기간을 15~30분으로 짧게 설정합니다. Refresh Token은 Opaque Token으로 발급하여 즉시 폐기가 가능하도록 합니다. 계정 탈취 발생 시 Refresh Token만 폐기하면 전체 세션이 즉시 만료됩니다.
5. 토큰 관리 전략 — 발급·갱신·폐기
토큰의 생애주기 전체를 안전하게 관리해야 합니다.
| 단계 | 권장 설정 | 설계 포인트 |
|---|---|---|
| 발급 | Access: 15~30분 Refresh: 7~30일 |
금융 서비스는 Access Token 5~15분. 발급 즉시 감사 로그 기록 |
| 저장 위치 | HttpOnly 쿠키 (웹) Secure Storage (모바일) |
JavaScript에서 접근 가능한 localStorage 사용 금지. XSS 공격으로 탈취 위험 |
| 갱신 | Refresh Token Rotation | Refresh Token 사용 시마다 새 Refresh Token 발급 + 구 토큰 즉시 폐기. 재사용 탐지 가능 |
| 폐기 트리거 | 로그아웃, 비밀번호 변경, 보안 사고 감지 | 즉시 폐기 필요 시 토큰 블랙리스트(Redis) 활용. JWT 서명 키 순환으로 일괄 만료 가능 |
| 키 관리 | JWT 서명 키 정기 순환 | 신·구 키 동시 유효 기간 설정으로 무중단 순환. 키는 HSM 또는 KMS 보관 |
6. 토큰 Claim 설계 원칙
JWT의 Payload(Claim)에 무엇을 담느냐는 보안과 성능 모두에 영향을 줍니다.
- 최소 포함 원칙: 서비스 인가에 꼭 필요한 정보만 포함.
sub(사용자 ID),iat(발급시각),exp(만료시각),scope(권한 범위) 기본 세트 - 민감 정보 절대 금지: 이메일·전화번호·주소·생년월일·결제 정보는 토큰에 포함 금지. 필요 시 서버에서 별도 조회
- 역할·권한 포함 판단: 역할(role)은 포함 가능하되, 세분화된 권한은 토큰 크기 증가와 무효화 문제로 서버 조회 권장
- 사용자 지정 Claim: OIDC 표준 Claim(
sub,email등) 외 커스텀 Claim은namespace/claim형식으로 충돌 방지
| Claim | 포함 여부 | 이유 |
|---|---|---|
sub (사용자 고유 ID) |
✅ 필수 | 모든 서비스에서 사용자 식별에 사용 |
exp, iat |
✅ 필수 | 토큰 유효성 검증 기본 요건 |
scope (권한 범위) |
✅ 필수 | 리소스 서버의 접근 제어 기준 |
email |
⚠️ 선택적 | ID Token에는 포함 가능. Access Token에는 최소화. 탈취 시 이메일 노출 위험 |
| 결제 정보, 주민번호, 생체정보 | ❌ 절대 금지 | 토큰 탈취 즉시 민감 정보 노출 |
7. Rate Limiting 설계
Rate Limiting은 자동화 공격을 차단하는 가장 기본적이고 효과적인 방어 수단입니다.
| 적용 대상 | 권장 제한 | 설계 포인트 |
|---|---|---|
| 로그인 API | IP당 분당 10회 | 초과 시 CAPTCHA 요구 → 재초과 시 15분 차단 → 반복 시 24시간 차단 |
| 비밀번호 재설정 API | 계정당 시간당 3회 | 동일 계정 이메일 폭격 방지. IP와 계정 두 축 모두 적용 |
| 토큰 갱신 API | 계정당 분당 5회 | Refresh Token 자동화 탈취 방지 |
| 가입 API | IP당 시간당 5회 | Bot 대량 가입 방지. CAPTCHA 연동 |
| 프로파일 조회 API | 계정당 분당 60회 | 계정 열거 공격 방지. 응답 지연 균일화(Timing Attack 방어) |
- 고정 윈도우(Fixed Window): 구현 단순. 윈도우 경계에서 2배 트래픽 허용되는 취약점 존재
- 슬라이딩 윈도우(Sliding Window): 더 정교한 제어. Redis Sorted Set으로 구현 가능. CIAM 인증 API에 권장
- 토큰 버킷(Token Bucket): 버스트 트래픽 허용하면서 평균 속도 제한. API 게이트웨이 수준에 적합
8. Bot 탐지와 CIAM 연동
CAPTCHA는 Bot 방어의 첫 번째 수단이지만 유일한 수단이 되어서는 안 됩니다. 정교한 Bot은 CAPTCHA를 우회합니다.
| 탐지 방식 | 탐지 신호 | CIAM 연동 |
|---|---|---|
| CAPTCHA (reCAPTCHA v3 등) |
이미지 선택, 텍스트 입력, 행동 분석 점수 | 로그인·가입 API에 점수 임계값 기반 챌린지 |
| 행동 분석 | 마우스 이동 패턴, 타이핑 속도, 폼 작성 시간 | 점수가 낮은 세션에 추가 인증 또는 차단 |
| 기기 핑거프린트 | 브라우저, OS, 해상도, 언어, 플러그인 조합 | 알려진 Bot 핑거프린트 패턴 차단 |
| IP 평판 | 데이터센터 IP, Tor 출구 노드, 알려진 공격 IP | 고위험 IP는 추가 인증 요구 또는 차단 |
| Honeypot 필드 | 숨겨진 폼 필드 입력 여부 | Honeypot 입력 감지 즉시 Bot으로 판정 |
9. OWASP API Security Top 10과 CIAM
OWASP(Open Web Application Security Project)의 API Security Top 10은 API 보안 취약점의 표준 분류입니다. CIAM과의 연관성이 높은 항목을 정리합니다.
| OWASP 취약점 | CIAM 연관 시나리오 | 대응 방법 |
|---|---|---|
| API1 — 객체 수준 인가 취약 | 다른 사용자의 프로파일 ID로 조회 가능한 경우 | 모든 API 요청에서 토큰의 sub와 요청 대상 ID 일치 검증 |
| API2 — 인증 취약 | 토큰 없이 인증 API 접근, 만료 토큰 수락 | 모든 엔드포인트 토큰 검증 강제, 만료 시각 엄격히 확인 |
| API3 — 과도한 데이터 노출 | 프로파일 API가 전체 필드 반환, 클라이언트에서 필터링 | 서버 측 응답 필드 최소화. 필요한 필드만 선택적 반환 |
| API4 — 리소스 부족·Rate Limiting 부재 | 로그인 API 무제한 호출 허용 | 엔드포인트별 Rate Limiting 적용 (섹션 7 참조) |
| API5 — 기능 수준 인가 취약 | 일반 사용자가 관리자 API 호출 가능 | 정책 엔진에서 역할별 엔드포인트 접근 통제 중앙화 |
| API8 — 보안 설정 오류 | CORS 모든 오리진 허용, HTTP 허용, 디버그 헤더 노출 | CORS 화이트리스트 관리, HTTPS 강제, 프로덕션 헤더 감사 |
10. API 보안 감사 체크리스트
- ☐ Implicit Flow 제거: 모든 클라이언트가 Authorization Code + PKCE 사용 확인
- ☐ Access Token 유효기간: 30분 이하 설정 여부
- ☐ Refresh Token Rotation: 사용 시마다 새 토큰 발급·구 토큰 폐기 동작 확인
- ☐ 토큰 저장 위치: localStorage 사용 금지, HttpOnly 쿠키 또는 메모리 저장 확인
- ☐ 민감 정보 Claim 없음: Access Token Payload에 이메일·전화번호 등 포함 여부
- ☐ Rate Limiting 적용: 로그인·재설정·가입·토큰갱신 API 모두 확인
- ☐ CORS 설정: 와일드카드(*) 오리진 허용 여부
- ☐ HTTPS 강제: HTTP 요청 자동 리다이렉트 또는 차단 여부
- ☐ 토큰 즉시 폐기: 로그아웃·비밀번호 변경 시 모든 토큰 무효화 동작 확인
- ☐ API 응답 최소화: 프로파일 API가 필요 필드만 반환하는지 확인
11. 정리
CIAM API 보안은 단일 기술이 아니라 플로우 선택 → 토큰 설계 → 저장 방식 → Rate Limiting → Bot 탐지 → 감사 로그로 이어지는 다층 방어 체계입니다.
공격자보다 한 발 앞서 가시성을 확보하는 것입니다.
누가, 언제, 어디서, 왜 접근하는지—
모든 것이 추적 가능해야 합니다."
오늘 당장 확인할 세 가지입니다. 첫째, 모든 퍼블릭 클라이언트에 PKCE가 적용되어 있는지 코드 레벨에서 확인하십시오. 둘째, Access Token의 Payload를 디코딩하여 민감 정보가 포함되어 있지 않은지 점검하십시오. 셋째, 로그인 API에 Rate Limiting이 설정되어 있는지, 초과 시 정상적으로 429 응답이 반환되는지 직접 테스트하십시오.
- OWASP. (2023). OWASP API Security Top 10 2023. OWASP Foundation. https://owasp.org/API-Security/
- IETF. (2015). JSON Web Token (JWT), RFC 7519. IETF.
- IETF. (2020). OAuth 2.0 Security Best Current Practice, draft-ietf-oauth-security-topics. IETF.
- NIST. (2021). SP 800-63C: Federation and Assertions. NIST.
- Gartner. (2024). API Security: Key Insights for Security Leaders. Gartner, Inc.
댓글
댓글 쓰기