Quiz: Token Lifetime and Refresh

토큰을 한 번 받아 두고 401 이 오면 그때 새로 받는 구조의 근본 문제는?

• 만료 순간마다 반드시 한 건은 실패하고, 그 한 건이 사용자 요청이면 사용자가 본다
• 갱신 요청이 너무 드물어져 인증 서버가 우리 클라이언트를 비활성으로 판단한다
• 401 응답에는 새 토큰이 들어 있지 않아 갱신 자체가 불가능하다
• 토큰이 만료되면 서버가 연결을 끊으므로 재시도 자체가 닿지 않는다

JWT 의 페이로드를 클라이언트가 직접 디코드해 exp 를 읽었다. 이 값을 어디까지 써도 되는가?

• 서명이 붙어 있으므로 권한 판단까지 그대로 써도 된다
• 언제 갱신할지 정하는 데는 써도 되지만, 그 값을 근거로 권한을 판단하면 안 된다
• 아무 데도 쓰면 안 된다. 클라이언트는 토큰 내부를 열어 보아서는 안 된다
• 서명을 함께 검증했다면 자원 서버 대신 클라이언트가 권한을 판단해도 된다

exp 와 nbf 를 다룰 때 시계 오차 여유(leeway)를 두는 이유는?

• 토큰의 실제 수명을 늘려 갱신 횟수를 줄이기 위해서다
• 여유를 두면 만료된 토큰도 계속 쓸 수 있어 장애 중에 도움이 되기 때문이다
• 서버와 클라이언트의 시계가 몇 초 어긋나는 것은 흔해서, 여유가 없으면 방금 받은 토큰이 거절될 수 있기 때문이다
• RFC 7519 가 여유를 두지 않은 구현을 금지하기 때문이다

401 을 받으면 갱신하고 다시 거는 로직에 재시도 횟수 상한을 두지 않았다. 어떤 서버에서 문제가 되는가?

• 응답이 느린 서버. 재시도가 겹쳐 타임아웃이 길어진다
• 토큰 수명이 아주 긴 서버. 갱신이 거의 일어나지 않아 캐시가 낡는다
• 발급 횟수에 제한이 없는 서버. 우리가 토큰을 너무 많이 받아 간다
• 권한이 모자란 상황에 403 대신 401 을 주는 서버. 갱신해도 계속 401 이라 고리가 생긴다

워커 20개가 토큰 캐시를 공유한다. 갱신할 때 잠금은 걸었는데 잠금을 잡은 뒤 캐시를 다시 읽지는 않았다. 결과는?

• 갱신이 줄을 서서 20번 일어난다. 잠금은 순서만 줄 세웠을 뿐이다
• 갱신이 한 번만 일어난다. 잠금이 나머지 19개를 막아 주기 때문이다
• 첫 워커가 잠금을 잡는 순간 나머지는 예외로 끝나 요청이 19건 실패한다
• 잠금 경합 때문에 교착이 생겨 모든 워커가 멈춘다

401 이 특정 노드에서만 계속 난다. 가장 먼저 확인할 것은?

• 그 노드의 시계. 몇십 초 어긋나 있으면 여유를 잘 잡아도 어긋난 쪽으로 밀린다
• 그 노드의 디스크 여유. 토큰 캐시 파일을 못 써서 매번 발급이 실패한다
• 그 노드의 메모리. 토큰이 메모리에서 밀려나 사라졌을 수 있다
• 인증 서버의 발급 한도. 그 노드의 몫만 먼저 소진됐을 수 있다