로그인과 인증 사이

관리 화면의 인증을 개편하는 계획을 검토하는데 계획서에 고정 토큰으로 사용자 로그인을 한다고 적혀 있었다. 문장이 이상해서 코드를 직접 읽었다.

Open Table of contents

로그인과 호출이 쓰는 토큰

로그인 요청을 보낼 때 이미 빌드 시점에 박힌 고정 토큰을 헤더에 싣고 있었다. 응답으로 받은 사용자 토큰은 저장소에 넣고 있었다.

다른 화면의 호출을 보니 거기서도 같은 고정 토큰을 쓰고 있었다. 사용자 토큰이 요청 헤더에 실리는 자리가 없었다.

저장한 사용자 토큰이 어디서 쓰이는지 찾아보니 사이드바 표시와 메뉴 권한 필터링뿐이었다. 즉 로그인의 결과는 화면 상태를 정하는 데만 쓰였다.

서버 입장에서는 모든 요청이 같은 클라이언트에서 온다. 로그인은 정상적으로 사용자 자격으로 수행되지만 그 결과가 인증에는 도달하지 않는 구조였다.

토큰이 빌드에 박혀 있으므로 값을 바꾸려면 다시 빌드해야 하고 유출돼도 즉시 못 바꾼다. 번들 파일 안에 문자열로 들어 있어서 브라우저에서 추출된다.

서버가 사용자를 모르므로 누가 무엇을 했는지 감사 기록이 남지 않는다. 메뉴가 안 보여도 주소를 직접 치면 들어가지는데 서버는 막을 근거 자체가 없다.

원래 문장대로면 로그인 방식만 고치면 되는 문제로 읽힌다. 실제로는 인증 주체를 옮기는 작업이라 서버 쪽 검증과 권한 체계와 경로 보호까지 전부 손대야 한다.

작업량이 몇 배로 갈리는 차이였다. 그래서 로그인은 사용자 자격으로 수행되나 호출 인증은 고정 토큰을 쓰고 사용자 토큰은 화면 상태에만 쓰인다는 문장으로 고쳐 어디까지가 되고 어디부터가 안 되는지를 드러냈다.

처음에는 계획서를 그대로 받아들일 뻔했다. 고정 토큰으로 로그인한다는 것이 무슨 뜻이고 그러면 아무나 로그인되냐는 되물음이 들어와서 코드를 열었다.

그 질문에 답하려니 읽어야 했고 읽으니 표현이 부정확한 것이 드러났다. 말이 안 되는 것 같으면 되묻는 것이 맞고 그 질문 하나가 견적을 바꿨다.