관리자 OTP를 붙이며 인증 이후의 질문을 배웠다

잇다 SM 프로젝트에서 OTP 인증 기능을 구현한 경험이 있다. 화면에 코드를 입력하고 확인하는 흐름은 눈에 잘 보인다. 하지만 백엔드까지 맡으며 더 중요하게 보게 된 것은 인증이 끝난 뒤 어떤 요청을 허용하는지였다.

인증 성공 화면이 보호 범위를 설명하지는 않는다

로그인한 사람인지 확인하는 것과 그 사람이 특정 관리 작업을 해도 되는지 확인하는 것은 다르다. OTP를 통과했다는 상태가 있어도 다른 사용자의 데이터에 접근할 권한까지 생기는 것은 아니다. 화면에서 버튼을 숨기는 것 역시 서버의 권한 검사와 같은 역할이 아니다.

당시 업무를 통해 인증과 인가를 구분해서 보는 계기가 생겼다. 돌아보면 “OTP 기능 완료”라는 표현만으로는 무엇이 보호됐는지 충분히 설명할 수 없다. 어느 작업 전에 추가 확인이 필요한지, 확인된 상태를 어디에 연결하는지가 함께 있어야 한다.

지금 다시 검토할 경계

우선 로그인 세션과 추가 인증 상태의 관계를 확인하겠다. 로그아웃한 뒤 이전 인증 상태가 남지 않는지, 다른 계정으로 바뀌었는데 그대로 인정되지 않는지 살펴보겠다. 중요한 작업은 화면을 거치지 않고 요청해도 같은 조건을 적용받는지 확인할 필요가 있다.

실패 흐름도 별도 기능으로 보겠다. 코드가 맞지 않는 경우와 인증 수단을 사용할 수 없는 경우는 사용자의 다음 행동이 다르다. 무작정 다시 시도하라고만 하면 운영 문의가 늘어날 수 있고, 지나치게 느슨한 복구는 추가 인증의 목적을 무너뜨릴 수 있다. 이 균형을 일반적인 답 하나로 단정하지 않겠다.

기능의 완료 범위를 설명하기

OTP를 구현했다는 사실만으로 시스템 전체가 안전하다고 말할 수는 없다. 추가 인증이 적용되는 요청과 여전히 별도 검토가 필요한 요청을 구별해야 한다. 당시에는 입력과 검증의 연결에 집중했다면, 지금은 보호 범위가 서비스 전체에서 일관적인지까지 질문하게 된다.

내게 남은 기준은 간단하다. 인증 기능을 검토할 때는 성공 화면의 스크린샷보다 보호해야 할 요청 목록을 먼저 보겠다. 정상 사용자에게 편리한가와 우회 요청에도 같은 규칙이 적용되는가는 각각 확인해야 한다. 두 질문을 나눠야 기능의 완료 범위를 설명할 수 있다.

기술 참고: OWASP 인증 가이드