토큰이 만료되고 아무도 안 알려 준다

시스템을 다른 환경으로 옮기면서 인증 계층 전체를 다시 훑어봤다. 토큰을 발급받아 요청마다 헤더에 실어 보내는 구조였다.

Open Table of contents

만료가 두 종류였다

토큰 자체의 만료는 짧고 만료되면 재발급받으면 되므로 코드가 처리한다. 그런데 만료가 걸린 것이 그것만이 아니었다.

앱 등록에도 일정 주기마다 재인증해야 하는 조건이 붙어 있었다. 그 기간을 넘기면 등록이 휴면이 되고 토큰 발급 자체가 거부된다.

앞의 것은 권한 없음 응답을 받았을 때 재발급을 받는 것으로 끝난다. 뒤의 것은 몇 번을 재시도해도 계속 거부되므로 코드가 할 수 있는 것이 없다.

사람이 관리 화면에 들어가 재인증해야 하는데 아무도 미리 알려 주지 않는다. 어느 날 갑자기 연동이 멈추는데 그 원인은 코드 어디를 봐도 나오지 않는다.

문서를 더 읽어 보니 관리 계정을 바꾸면 기존 앱 등록이 무효화되는 조건도 있었다. 담당자가 바뀌어 계정을 이관하는 것만으로 연동이 죽는다는 뜻이다.

이것도 예고가 없는 데다 계정 이관은 개발과 무관한 일정으로 진행된다. 만료 주기와 무관하게 언제든 걸릴 수 있는 조건이었다.

코드로 못 막는 것은 사람이 도는 절차 쪽에서 다루기로 했다. 재인증 마감일을 주기에서 역산해 달력에 넣고 그 전에 알림이 오게 했으며 계정 변경 시 절차도 운영 문서에 붙였다.

감지도 함께 넣었는데 토큰 발급이 실패하면 알림이 나가게 했다. 다만 그것은 이미 멈춘 뒤이므로 사전 예방은 달력이고 사후 감지가 알림이며 둘이 서로를 대체하지 않는다.

이식하는 김에 만료가 걸린 것을 전부 찾아 하나의 표로 만들었다. 토큰과 앱 등록과 인증서와 계정 비밀번호가 각각 주기와 만료 시 증상이 달랐다.

표에서 가장 중요한 열이 대응 주체였고 사람이라고 적힌 줄이 전부 달력에 들어갈 것이었다. 원래 환경에서는 누군가 알고 관리했겠지만 문서에 없었고 옮기면 그 사람이 없으므로 이식이 그 암묵적 지식을 드러낸 셈이다.