OIDC 리다이렉트 URI, 로그인 편의 기능이 보안 경계가 되는 이유
B2B SaaS의 OIDC SSO에서 리다이렉트 URI를 안전하게 등록하고 검증하는 방법과 멀티 테넌트 환경에서 반드시 점검할 항목을 알아봅니다.
OIDC 로그인이 끝나면 IdP는 사용자를 SaaS의 리다이렉트 URI로 돌려보냅니다. 겉으로는 로그인 후 돌아갈 주소 하나처럼 보이지만, 실제로는 인증 코드가 전달되는 보안 경계입니다. 주소 검증이 느슨하면 공격자가 인증 응답을 자신이 통제하는 페이지로 유도하거나, 다른 고객 테넌트의 로그인 흐름과 섞이게 만들 수 있습니다.
최근 아이덴티티 보안에서는 피싱, 탈취된 자격증명, 공급망 공격뿐 아니라 설정 오류로 생기는 신뢰 경계의 틈도 중요하게 다룹니다. OIDC를 도입했다는 사실보다 “인증 결과가 정확히 어디로 돌아가는가”를 통제하는 운영이 필요한 이유입니다.
리다이렉트 URI는 택배 수령 주소와 같습니다
인증 코드를 중요한 서류가 든 등기우편이라고 생각해 보겠습니다. 수령 주소를 예시 도메인 정도로만 적거나 비슷한 주소를 모두 허용하면 엉뚱한 사람에게 전달될 수 있습니다. 리다이렉트 URI도 스킴, 호스트, 포트, 경로까지 사전에 등록한 값과 정확히 비교해야 합니다.
와일드카드와 임의 주소를 피하세요
운영 편의를 위해 넓은 와일드카드를 허용하거나 요청마다 돌아갈 주소를 자유롭게 받으면 공격 표면이 커집니다. 운영·스테이징·로컬 환경은 각각 별도 URI로 명시하고, 사용하지 않는 주소는 제거해야 합니다. 운영 환경에서는 HTTPS를 기본으로 하고, 개발용 주소가 운영 앱 설정에 남지 않았는지도 확인합니다.
멀티 테넌트 SaaS는 고객 경계까지 확인해야 합니다
B2B SaaS는 하나의 서비스가 여러 고객사의 로그인을 처리합니다. 이때 리다이렉트 URI만 맞아도 충분하다고 생각하기 쉽지만, 요청을 시작한 테넌트와 응답을 처리하는 테넌트가 같은지도 확인해야 합니다. state로 요청과 응답을 연결하고, nonce로 ID 토큰 재사용을 방지하며, 브라우저나 모바일 앱 같은 공개 클라이언트는 PKCE 적용을 검토해야 합니다.
OIDC와 SAML의 역할 차이는 OIDC와 SAML 비교, 실제 SP 연동 흐름은 SSO SP 연동 가이드에서 더 자세히 확인할 수 있습니다.
등록보다 변경 관리가 더 어렵습니다
처음 연동할 때 안전하게 설정해도 도메인 이전, 경로 개편, 고객별 커스텀 도메인 추가 과정에서 예외가 쌓일 수 있습니다. 변경 요청에는 소유자, 목적, 대상 환경, 만료 여부를 남기고 기존 URI를 언제 제거할지 함께 정해야 합니다. 실패 로그에는 테넌트와 앱, 검증 결과를 기록하되 인증 코드나 토큰 같은 비밀값은 남기지 않아야 합니다.
배포 전 체크리스트
• 등록 URI와 실제 콜백 주소를 완전 일치로 비교합니다.
• 운영, 스테이징, 로컬 앱 설정을 분리합니다.
• state, nonce, 필요 시 PKCE 검증 실패를 안전하게 거부합니다.
• 미사용 URI를 정기적으로 삭제하고 변경 이력을 보존합니다.
• 고객 도메인은 소유권 검증 후 신뢰합니다. 자세한 기준은 도메인 검증 가이드를 참고하세요.
AxiPass로 고객별 SSO 경계를 일관되게 운영하세요
AxiPass는 SaaS 기업이 멀티 테넌트 환경에서 OIDC와 SAML 앱 등록, SCIM 프로비저닝, MFA, SWA, 감사 로그를 한곳에서 운영하도록 돕습니다. 고객사별 설정과 변경 기록을 분리하면 SSO 확장 속도를 유지하면서도 인증 응답의 목적지를 더 명확하게 관리할 수 있습니다.
고객별 SSO 연동을 안전한 기본값에서 시작하고 싶다면 AxiPass를 무료로 시작해 보세요.