[Infra] SSO 로그인 장애 발생 시 디버깅 체크리스트와 해결 전략

운영 중인 서비스에서 갑자기 로그인이 안 되기 시작하면, 특히 SSO 로그인 장애 해결 이슈는 생각보다 훨씬 까다롭게 번진다. 사용자 입장에서는 그냥 “로그인이 안 된다”로 끝나지만, 운영자 입장에서는 IdP(Identity Provider, 인증 제공자), SP(Service Provider, 서비스 제공자), 브라우저 쿠키, 리버스 프록시(reverse proxy, 역방향 프록시), 시간 동기화까지 전부 의심해야 하거든요. 저도 처음엔 이게 뭔가 싶었는데, 실제로 장애 대응을 몇 번 해보니까 결국 핵심은 감으로 때려 맞추는 게 아니라 체크리스트 기반으로 좁혀가는 것이더라고요. 이번 글에서는 제가 현장에서 자주 쓰는 SSO 디버깅 순서와 IDP 문제 해결 전략을 정리해보겠다.

사용자, 브라우저, 서비스 제공자, 인증 제공자 사이에서 어디서 실패하는지 한눈에 파악하는 구조도입니다.

1. 왜 SSO 로그인 장애는 빨리 커질까요?

SSO(Single Sign-On, 통합 로그인)는 쉽게 말해 한 번 인증하면 여러 서비스에 연동되는 구조입니다. 평소에는 정말 편합니다. 그런데 장애가 나면 영향 범위도 같이 커집니다. 한 서비스만 막히는 게 아니라, 회사 포털, 내부 위키, VPN, 협업 도구까지 줄줄이 막힐 수 있거든요.

실제로 써보니까 SSO 장애는 보통 아래 네 가지 패턴으로 나뉘더라고요.

• 리다이렉트(redirect, 재전송) 루프: 로그인 페이지로 계속 돌아감
• 인증 오류: 잘못된 Assertion, invalid token, audience mismatch 같은 오류
• 세션 문제: 로그인 직후 다시 로그아웃되거나 세션이 안 붙음
• 환경 문제: DNS, TLS 인증서, 프록시 헤더, 서버 시간 차이

여기서 중요한 포인트! SSO는 애플리케이션만 봐서는 잘 안 풀립니다. 브라우저 – 네트워크 – 애플리케이션 – IdP를 한 묶음으로 봐야 합니다.

2. SSO 로그인 흐름 이해하기: 구조를 먼저 머릿속에 그려보세요

저도 처음엔 로그만 뒤졌었는데, 사실 그 전에 흐름부터 정리해야 하더라고요. 쉽게 말해 사용자가 보호된 페이지에 접근하면 SP가 “너 인증 필요해”라고 판단하고 IdP로 보냅니다. 사용자가 IdP에서 로그인하면, IdP는 SAML Assertion(사설명서 같은 인증 응답)이나 OIDC Token(JSON 기반 토큰)을 SP로 돌려보냅니다. 그다음 SP가 검증하고 세션을 발급하면 끝입니다.

이 흐름을 기준으로 보면 SSO 로그인 장애 지점이 꽤 명확해집니다. 브라우저가 못 가는지, IdP가 거절하는지, SP가 응답을 못 읽는지 구분이 되거든요.

3. SSO 로그인 장애 해결 체크리스트: 제가 가장 먼저 보는 순서

이 부분은 진짜 실전입니다. 삽질 좀 했습니다 ㅎㅎ 그래서 지금은 무조건 아래 순서로 봅니다.

1. 사용자 증상 수집: 전원 장애인지, 특정 사용자만 그런지, 특정 브라우저만 그런지 확인합니다.
2. 최근 변경사항 확인: 인증서 교체, 프록시 설정 변경, 도메인 변경, 쿠키 정책 수정이 있었는지 봅니다.
3. 브라우저 개발자 도구 확인: Network 탭에서 302, 400, 401, 403 흐름을 추적합니다.
4. 애플리케이션 로그 확인: assertion invalid, token verification failed, audience mismatch 같은 문자열을 찾습니다.
5. IdP 로그 확인: 정책 차단인지, 앱 설정 mismatch인지 확인합니다.
6. 시간 동기화 점검: NTP(Network Time Protocol, 시간 동기화) 오차가 몇 분만 나도 실패합니다.
7. 프록시/로드밸런서 헤더 확인: X-Forwarded-Proto, Host 헤더가 꼬이면 redirect_uri가 달라집니다.

운영 서버에서 빠르게 볼 때는 이런 식으로 확인합니다.

# 애플리케이션 로그에서 인증 관련 에러만 추리기
journalctl -u myapp -n 300 | egrep -i "saml|oidc|oauth|token|assertion|redirect|issuer|audience|nonce|session"

# NTP 동기화 상태 확인
chronyc tracking
chronyc sources -v

# 리다이렉트와 응답 헤더 확인
curl -k -I https://service.example.com/login
curl -k -L -v https://service.example.com/login

# 인증서 만료일 확인
openssl s_client -connect service.example.com:443 -servername service.example.com </dev/null | openssl x509 -noout -dates -issuer -subject

직접 해보니 여기서 절반은 걸러집니다. 특히 최근 변경사항과 시간 동기화는 생각보다 자주 원인이 됩니다.

4. 실전 구현: 로그와 설정으로 원인 좁히기

4-1. OIDC 설정 점검 포인트

OIDC(OpenID Connect, OpenID 기반 인증 확장)를 쓰는 서비스라면 클라이언트 설정이 맞는지부터 보셔야 합니다. redirect_uri 하나만 달라도 바로 로그인 실패가 납니다.

auth:
  oidc:
    issuer: "https://idp.example.com/realms/main"
    client_id: "internal-portal"
    client_secret: "REDACTED"
    redirect_uri: "https://portal.example.com/oauth/callback"
    scopes:
      - openid
      - profile
      - email

여기서 제가 실제로 자주 본 문제는 세 가지였습니다.

• issuer 불일치: 트레일링 슬래시 하나 차이로 검증 실패
• redirect_uri 불일치: 프록시 뒤에 있어서 http로 인식됨
• scope 누락: email, profile이 없어 사용자 매핑 실패

4-2. SAML 설정 점검 포인트

SAML은 XML 기반이라 더 고전적인 대신, 장애가 나면 더 난감할 때가 있습니다. 처음엔 에러 메시지도 불친절해서 헷갈렸는데, 결국 볼 건 비슷합니다.

saml:
  entity_id: "https://service.example.com/saml/metadata"
  acs_url: "https://service.example.com/saml/acs"
  idp_metadata_url: "https://idp.example.com/metadata"
  want_assertions_signed: true
  want_response_signed: true

ACS URL(Assertion Consumer Service URL, 인증 응답 수신 주소), Entity ID, 서명용 인증서가 안 맞으면 거의 바로 터집니다.

실무에서 자주 확인하는 issuer, redirect URI, ACS URL, Entity ID 같은 핵심 항목을 비교해 보여주는 이미지입니다.

5. ⚠️ 자주 만나는 장애 패턴과 해결 전략

이제부터는 제가 장애 대응하면서 반복해서 본 케이스들입니다. 여기서 시간 많이 씁니다.

5-1. 무한 리다이렉트가 걸릴 때

브라우저에서 로그인 후 다시 로그인 페이지로 돌아오면 보통 세션이 저장되지 않았거나, 콜백 URL 계산이 틀린 경우가 많습니다.

• 쿠키의 SameSite 속성 확인
• Secure 쿠키인데 HTTPS 종료 지점이 꼬이지 않았는지 확인
• X-Forwarded-Proto, X-Forwarded-Host 헤더 전달 확인
• 애플리케이션의 external URL 설정 확인

저는 예전에 로드밸런서에서 HTTPS를 종료하고 백엔드로 HTTP를 넘기는 구조에서 이걸 크게 겪었습니다. 앱은 자꾸 자기 주소를 http로 계산하고, IdP에는 https로 등록되어 있으니 매번 검증이 틀어지더라고요.

5-2. token expired 또는 not yet valid

이건 거의 시간 문제입니다. 서버 두 대 중 한 대만 시간이 어긋나도 간헐 장애처럼 보입니다. 그래서 모든 인증 노드는 반드시 같은 시간 기준을 써야 합니다.

timedatectl status
chronyc tracking
# 컨테이너 환경이라면 호스트 시간도 같이 확인

5-3. 특정 사용자만 실패할 때

이 경우는 그룹 매핑(group mapping), 이메일 클레임(claim), NameID 형식, 역할(role) 동기화 문제일 때가 많습니다. 즉, 시스템 전체 장애가 아니라 속성(attribute) 매핑 문제일 수 있습니다.

5-4. 인증서는 멀쩡한데 서명 검증이 실패할 때

이건 IdP 메타데이터가 갱신됐는데 SP가 예전 인증서를 계속 들고 있을 때 자주 봅니다. 메타데이터 캐시를 갱신하거나, 인증서를 다시 가져오면 풀리는 경우가 많습니다.

6. 검증 절차: 수정 후에는 이렇게 확인합니다

SSO 로그인 장애 조치가 끝났다고 바로 종료하면 안 됩니다. 저도 예전에 한 사용자만 테스트하고 끝냈다가, 다른 브라우저에서 다시 터진 적이 있었습니다. 그래서 수정 후 검증은 아래처럼 분리해서 합니다.

1. 신규 세션 테스트: 시크릿 모드에서 처음부터 로그인
2. 기존 세션 테스트: 로그인 상태 유지, 로그아웃 후 재로그인
3. 권한별 테스트: 일반 사용자, 관리자, 외부 사용자 계정
4. 브라우저별 테스트: Chrome, Edge, Safari 등
5. 로그 검증: 에러가 사라졌는지, 경고만 남았는지 확인

# 최근 10분간 에러 로그 재확인
journalctl -u myapp --since "10 minutes ago" | egrep -i "error|warn|saml|oidc|oauth|token|assertion"

# 헬스체크 응답 확인
curl -k https://service.example.com/health

# 로그인 후 콜백 응답 코드 확인 예시
curl -k -I https://portal.example.com/oauth/callback

장애 조치 이후 정상 로그인과 에러 감소 추이를 함께 보여주는 검증 결과 이미지입니다.

이렇게 해두면 단순히 “된다”가 아니라, 왜 해결됐는지까지 남길 수 있습니다. 이게 다음 장애 때 큰 차이를 만듭니다. 드디어 됐다! 싶은 순간이 오더라고요.

7. 빠르게 보는 SSO 디버깅 체크리스트

운영 중 급할 때 바로 볼 수 있게 요약하면 이렇습니다.

SSO 로그인 장애 해결을 할 때 중요한 건 도구보다 순서입니다. 순서만 잡히면 장애 대응 시간이 확 줄어듭니다.

8. 정리와 다음 단계

오늘 정리한 내용은 결국 하나로 모입니다. SSO 디버깅은 인증 서버만 보지 말고, 사용자 요청이 지나가는 전 구간을 따라가야 한다는 점입니다. 저도 처음엔 앱 로그만 붙잡고 있었는데, 실제로는 프록시 헤더 하나 때문에 반나절을 날린 적도 있었거든요. 그런 삽질을 몇 번 하고 나니, 이제는 무조건 체크리스트로 갑니다.

혹시 지금 인증 오류나 로그인 실패 때문에 급하게 보고 계시다면, 먼저 최근 변경사항과 시간 동기화부터 보세요. 그다음 브라우저 리다이렉트 흐름, 애플리케이션 로그, IdP 로그 순으로 좁혀가면 됩니다. 이 흐름만 익숙해져도 IDP 문제 해결 속도가 꽤 빨라집니다.

다음 글에서는 Keycloak, Okta 같은 실존 IdP 제품에서 공통적으로 확인할 수 있는 로그 포인트와, Kubernetes(쿠버네티스) Ingress(인그레스, 외부 트래픽 진입점) 뒤에서 SSO가 꼬일 때의 대응법도 다뤄볼 예정입니다. 이전 글에서 다뤘던 리버스 프록시 헤더 정리 글도 함께 보시면 더 이해가 잘 되실 겁니다.

장애 대응 순서, 주요 원인, 확인 명령어를 한 장으로 요약한 인포그래픽 이미지입니다.

9. 자주 묻는 질문

Q1. 로그인 실패가 특정 브라우저에서만 발생하면 어디를 봐야 하나요?

쿠키 정책, 캐시, 확장 프로그램, 서드파티 쿠키 차단 설정부터 보시면 됩니다. 특히 SameSite 정책은 브라우저별 체감이 다를 수 있습니다.

Q2. IdP는 정상인데 서비스만 로그인 안 되면요?

SP 쪽 redirect_uri, ACS URL, issuer, audience 설정을 다시 보셔야 합니다. 대부분은 설정 불일치입니다.

Q3. 장애 재발 방지는 어떻게 하시나요?

설정 변경 전후 diff 관리, 메타데이터 만료 모니터링, NTP 상태 점검, synthetic login test(합성 로그인 테스트) 자동화를 추천드립니다. 이거 진짜 편하더라고요.