OAuth 클라이언트 시크릿, 발급보다 회전이 중요한 이유

SSO를 연결할 때 발급받은 OAuth 클라이언트 시크릿을 몇 년 동안 그대로 사용하고 있지는 않나요? 최근 IAM 보안에서는 사용자 계정뿐 아니라 애플리케이션, API, 자동화 도구 같은 비인간 아이덴티티의 자격증명 관리가 중요한 과제로 떠오르고 있습니다. 클라이언트 시크릿도 애플리케이션이 IdP에 자신을 증명하는 자격증명이므로 발급, 보관, 교체, 폐기까지 수명주기로 관리해야 합니다.

클라이언트 시크릿은 앱의 비밀번호입니다

OIDC에서 기밀 클라이언트는 토큰 엔드포인트에 요청할 때 클라이언트 ID와 시크릿으로 자신을 인증합니다. 시크릿이 소스 코드, 협업 문서, CI 로그에 노출되면 공격자가 정상 앱처럼 토큰을 요청할 가능성이 생깁니다. 사용자 비밀번호와 달리 여러 서버와 배포 환경에 복제되기 쉬워 유출 지점을 찾기도 어렵습니다.

브라우저나 모바일 앱처럼 값을 숨길 수 없는 공개 클라이언트에는 시크릿을 넣어서는 안 됩니다. PKCE 등 클라이언트 유형에 맞는 방식을 선택하고, 서버가 안전하게 보관할 수 있는 기밀 클라이언트에만 시크릿을 사용하세요. OIDC의 역할과 SAML과의 차이는 OIDC와 SAML 비교에서 확인할 수 있습니다.

회전은 사고 후 조치가 아니라 정기 운영입니다

시크릿 회전은 기존 값을 새 값으로 바꾸고 이전 값을 폐기하는 과정입니다. 정기 회전은 유출 사실을 모르는 상황에서도 자격증명의 유효 기간을 제한합니다. 담당자 퇴사, 저장소 공개, 배포 로그 노출, 외주 계약 종료처럼 신뢰 경계가 바뀌었을 때는 예정일을 기다리지 말고 즉시 교체해야 합니다.

중단 없는 교체 절차

1. 앱 소유자와 사용 중인 운영·스테이징 환경을 확인합니다.
2. 새 시크릿을 발급하고 비밀 저장소에 등록합니다.
3. 애플리케이션을 새 값으로 배포한 뒤 토큰 발급과 로그인을 검증합니다.
4. 모든 인스턴스 전환을 확인한 후 이전 시크릿을 폐기합니다.
5. 발급자, 변경 시각, 대상 앱, 검증 결과를 감사 기록으로 남깁니다.

새 값 배포 전에 기존 값을 즉시 폐기하면 로그인 장애가 발생할 수 있습니다. 반대로 전환 기간을 무기한 열어 두면 공격 가능 시간도 늘어납니다. 짧고 명시적인 전환 창과 롤백 기준을 정하는 것이 핵심입니다.

멀티 테넌트에서는 고객사별 영향을 분리하세요

여러 고객사가 같은 시크릿을 공유하면 하나의 유출이 전체 테넌트로 번질 수 있습니다. 고객사와 앱별로 자격증명을 분리하고, 운영·스테이징도 별도로 관리하세요. 접근 가능한 담당자를 최소화하고 평문을 티켓, 메신저, 로그에 남기지 않아야 합니다. 고객사 경계를 설계하는 원칙은 멀티 테넌트 IdP 격리를 참고하세요.

AxiPass는 멀티 테넌트 환경에서 OIDC/OAuth2 애플리케이션 등록과 시크릿 회전, 그룹 기반 접근 정책, MFA, 감사 로그를 함께 관리하도록 돕습니다. SAML 앱과 SCIM 프로비저닝, SSO를 지원하지 않는 앱의 SWA까지 한곳에서 운영하면 사람과 애플리케이션 자격증명의 변경을 더 일관되게 추적할 수 있습니다. 감사 준비 방법은 SaaS 보안 감사와 IdP도 함께 살펴보세요.

무료로 시작