Access Token 만료시 클라이언트가 요청 vs 자동 재발급에 대한 고찰.. 도와주세요!

Question

이전에 Refresh Token 만료 시에 대한 고찰에 대해 여러 선생님들께서 좋은 답변을 주셔서 도움이 많이 됐습니다.그래서 refresh Token 만료 시에 재인증을 하도록 예외처리를 다 해서 응답 받을 수 있도록 구현해놨는데이번에는 Access Token 만료 시에 대한 의견이 분분해서 다시 한 번 여러 선생님의 의견을 듣고 싶어 올리게 되었습니다.현재 동작방식은 다음과 같습니다.로그인 시 access token과 refresh token을 생성(발급)하여 로그인 성공 응답으로 응답해줍니다.사용자는 access token을 통해 인증을 수행하다가, access token이 만료되면 유효한 refresh token을 이용하여 access token을 재발급 받습니다.이때 Access Token 만료에 대한 핸들링을 아직 정의하지 못 했습니다.다음 방법 중에 어떤 방법이 괜찮을지 모르겠습니다.[A방법]ExpiredJwtException를 catch하여 Access Token 만료 시 Client에게 Access Token 만료 되었다는 응답만 전송Client는 Access Token 만료 응답을 받게 되면, 수동으로 Refresh Token을 통한 Access Token 재발급(/refresh)을 요청서버로부터 Access Token 및 Refresh Token을 재발급 받으면, 해당 Access Token으로 원래 요청하려고 했던 서비스 요청을 다시 시도[B방법]ExpiredJwtException를 catch하여 Access Token 만료 시 Client에게 Access Token이 만료되었으니 새롭게 Access Token과 Refresh Token을 발급하여 응답해줌Client는 만료되어 재발급받은 Access Token으로 기존 요청을 다시 재요청함[C방법]ExpiredJwtException를 catch하여 Access Token 만료 시 서버는 우선 해당 요청에 대한 로직을 수행한다.별도로 만료된 Access Token을 통한 요청에 대한 응답코드를 정의한다.3-A. 예를 들어 2005번은 요청에 대한 정상적인 응답을 주지만, Access token이 만료되었으니 Refresh Token을 통한 Access Token 재발급(/refresh)을 하라는 의미를 갖게 하여 Client가 Access token을 재발급 받게 한다.3-B. [3-A]안과 마찬가지로 요청에 대한 정상적인 응답을 주지만, 별도로 정의한 응답코드를 통해 요청에 대한 응답과 Access Token을 재발급해서 응답해준다.일단 제가 생각한 것은 보안 관점에서 봤을 때, A방법이 Client쪽에서 별도의 로직을 구현해야 하는 번거로움이 있지만, 이게 안전할 거라 생각이 들어요.왜냐하면, Access Token이 탈취되면 서버는 요청한 사람이 공격자인지 정상적인 클라이언트인지 구분할 수가 없게 되는데이것을 방지하기 위해 상대적으로 Access Token의 만료시간을 짧게 두고 Refresh Token을 두는 거로 알고 있기 때문에Access Token이 만료되었는데 B나 C방법처럼 재발급을 해준다..?이러면 만료시키는 의미가 없다고 생각이 들어서요.그래서 제가 생각한 결론은 Client에서 Access Token 만료 시 별도로 Refresh Token을 통해 /refresh로 요청하여 재발급 받는 게 맞다! 라고 생각은 들지만다른 분은 서비스API 요청마다 Access Token &#43; Refresh Token을 항상 같이 보내고, Access token이 만료될 경우 Refresh Token을 검증한 후에 자동으로 재발급 해주는 방식으로 구현하셨다고 해서요개발에 정답이 없다고 생각하지만, 보편적으로 사용되는 방법과 더 효율적인 방법에 대한 구분은 분명히 있다 보니여러 다양한 선생님들의 의견을 듣고 싶어 질문드리게 되었습니다. 도와주시면 감사하겠습니다 &#x1f44d;[&#43;] 만약 A방법이 맞을 경우 React나 Flutter 등 프론트 기술에서 구현하는 게 맞겠지요?

캐티 · Answer

개발을 어렵게 하면 안되며 이 문제는 복합적인 이유가 있겠어요.토큰만료가 30분이면 10~20분 사이에 타이머를 반복하고 새로 토큰을 받아온다.사용자가 마지막 요천을 보낸 30분이 지난경우 새로 토큰을 받아온다.두가지 방법 모두 코드 몇줄 이내로 구현 가능해요.

집킨 · Answer

글쓴님과 같은 이유로 전 보통 A를 선호합니다구글OTP도 만료되면 리프레시 하거든요

장독깨기 · Answer

A 로 하셔야죠. 자동 재발급 해줄거면 만료기간도 리프레시 토큰도 둘 필요가 없죠.그냥 액세스토큰 발급하고 계속 사용하면 되잖아요. ㅎOAuth2 한 번 자세히 읽어 보는 것도 도움이 될 거 같습니다. :)

북극곰은콜라 · Answer

A만 채용 가능하다고 봅니다.토큰은 기본적으로 보안성이 높지 않기 때문에 유효기간 개념이 도입되었습니다.이는 탈취되거나 노출되는 이슈 발생 시 피해를 최소화하기 위한 보안적 요구사항입니다.B,C의 경우 위 목적을 수행할 수 없으며, 이는 토큰을 사용하는 근본적인 이유가 희석됩니다.

르매 · Answer

저희 팀에는 A 방법으로 가이드 하고 있습니다.B도 고려해 본 적은 있는데 이 방법은..매번 리프레시 토큰을 전송해야 하는 점토큰 갱신 로직을 모든 API 서버에서 공통으로 구현해야 하는 점때문에 채택하지 않았습니다.보안적으로 보면 C는 채택할 수 없을 것 같고, B는 위의 두 가지가 서버 구현 측에 부담을 주는 문제가 있을 뿐 보안적으로는 문제가 없습니다.아마 B나 C를 고려하셨던 것은.. 프론트엔드의 부담을 덜어주고 싶기 때문이겠죠. ^^마지막 언급하신 것처럼 프론트엔드에서 구현해야하는 기능들이고, 주니어에게 맡겨 놓으면 막상 한 번에 잘 구현하지는 못해서.. 프로세스를 잘 설명해 줘야 했습니다.

르매 · Answer

보안을 위해 HTTP Only 쿠키를 사용하면 애초에 쿠키 설정을 프론트엔드가 아니라 백엔드가 하네요.프론트엔드는 토큰이 있는지 조차 알수 없기 때문에 액세스 토큰 갱신을 위해 리프레시 토큰을 백엔드에 보내는 것 자체가 불가능해 집니다.그 대신 백엔드에서 액세스 토큰 만료를 catch해서 리프레시 토큰을 사용해 (쿠키에 설정했기 때문에 API를 호출할 때마다 헤더에 액세스토큰과 리프레시 토큰이 자동으로 포함) 액세스 토큰을 갱신하고, 백엔드에서 갱신한 토큰을 쿠키에 http only로 설정해 주면 됩니다. (프론트엔드에게 토큰을 내려 주는게 아니라 백엔드가 직접 쿠키 설정)저도 그동안 토큰을 프론트엔드에 내려 주면 프론트엔드에서 알아서 저장하고 갱신하는 것으로 생각했는데, http only 쿠키를 사용하는 경우는 이 프로세스가 달라지네요.보안적으로도 더 낫고 백엔드에서 대부분을 컨트롤할 수 있어서 작업이 단순해 질 것 같아요. 이번 진행하는 프로젝트에서는 이런 방식으로 적용 시켜 보려 합니다.p.s 프론트엔드에서 로그인이 되어 있는지에 따라 화면 표시가 달라지는데, 이걸 위해 로그인 여부를 알려주는 API가 필요하고 (쿠키를 뒤져도 액세스 토큰이 있는지 없는지 모르기 때문) 로그인 여부를 로컬 스토리지 같은 곳에 따로 저장해서 이걸 읽는 방식으로 전환해야 합니다. 어차피 로컬 스토리지에 저장된 &#34;로그인 여부&#34;는 조작이 되더라도 상관이 없는 것이.. 로그인이 필요한 API는 백엔드에서 늘 토큰을 검사하기 때문에 큰 문제는 발생하지 않습니다.

Access Token 만료시 클라이언트가 요청 vs 자동 재발급에 대한 고찰.. 도와주세요!

6개의 답변

Q&A 목록