jwt 서버 인증시 access token 만 보내는 경우

Question

jwt 로 인증/인가 구현시 궁금한 점이 있어서요!클라에서 access token만 서버로 전송하면 access token 만료시 서버에서 refresh token 으로 access token 을 재발급 하는 걸로 알고 있습니다. 그런데 만약 access token 이 탈취되면 access token이 만료 되더라도 서버에서 refresh token 으로 재발급 받을 수 있는거 아닌가 하는 생각이 들었습니다. 이런 경우에는 어떻게 방어로직이나 설계를 구축하는지 의견을 듣고싶습니다..! -------------------------------------------------------------------------------- 저는 access token 과 refresh token 을 모두 보내는 방식을 생각했지만, 다른 프론트 개발자 분 회사에서는 access token 만 클라에서 서버로 보낸다는 얘기를 들었습니다. 이럴 경우에는 어떻게 악의적 공격에 대응하는지 궁금해서 질문을 작성하게 됐습니다. 그 분은 프론트라 서버단에서 어떻게 처리하는진 잘 모른다고 하셔서요 ㅎ,,,

심심하다능! · Answer

Access토큰과 함께 refresh토큰을 보내는 것 아닌가요? access토큰만 보내는 경우는 refresh토큰을 구현하지 않는 경우죠. access토큰이 만료되었는데 서버에서 알아서 refresh토큰을 보내 버리면 안 되죠. 함께 넘어오는 refresh토큰을 함께 검증을 해서 access 토큰을 다시 보내주는 거죠.

boomdw · Answer

jwt를 직접 구현해본적은 없지만 구현하기 위해서 서칭 해보면서 이해했던걸 토대로 답변 드립니다.도움이 될지 모르겠습니다.우선 jwt 를 사용하는 방법에는 정답이 없음을 알려드립니다.jwt 를 사용하는 목적은 auth 과정에서 DB 서버를 사용하는 리소스를 줄이기 위한 목적으로 많이 사용하는데토큰이 탈취 당할수도 있다는 전제를 깔아놓고 생각 하면 사실 jwt는 사용할 수 없습니다.우리가 집문에 잠금 장치를 여러개를 달아놔도 뒷 창문을 통해서 침입하는 도둑을 어찌 할 수 없는 것 처럼 jwt 토큰도 마찬가지에요. 클라이언트 단에서 서버로 전달 해야 하는 토큰이기 때문에 어쩔 수 없이 클라이언트가 보관을 하고 있어야 하는데,그렇다 보니 당연히 어떤 방법으로든 탈취 가능성이 있고 그런 부분까지 전부 다 고려하면 사실 jwt 토큰을 사용하기보다는 뚫기 어려운 기존의 DB 사용 방식을 채택 해야겠죠?저는 개인적으로 jwt 관련 서칭을 하면서 탈취를 완벽하게 막을수는 없다 라는 전제를 깔고 사용해야 한다고 이해했어요프론트엔드 개발자가 아니라서 아래 말씀드릴 내용이 가능한지 정확히는 모르겠지만reflesh 토큰 자체는 클라이언트 스토리지에 보관하기 보다는 DB를 사용해서 서버에 저장하는게 좋다고 생각하고백엔드도, 프론트엔드도 DB를 이용해서 보관하고 필요시에만 꺼내쓰는 방식을 채택하는게 보안적으로는 좋겠죠예를 들면access 토큰 인증 요청 -> 만료 확인 (거부) -> reflesh 토큰 인증 요청 -> DB에서 조회한 reflesh 토큰 전달 -> 확인 후 access 토큰 재발급access 토큰의 유효기간을 최소화 하고 자주 재발급을 진행하는 방식을 채택 하는걸 추천드려요access 토큰을 DB에 저장하는건 애초에 jwt 구현 목적에 맞지 않을테니 당연히 그럴 필요가 없고요.reflesh 토큰의 경우에도 뚫기 어려운 DB 환경을 사용해서 보관하는게 아니라면1일~3일 정도의 짧은 재발급 주기를 사용하시는 걸 추천드립니다.구현 사례를 보면 DB를 사용하신 분들은 reflesh 토큰 재발급 주기를 30일 정도로 넉넉하게 잡고 사용하신 경우도 있더라고요여튼, 요점은 보안이 엄청나게 중요한 환경이라면 jwt 토큰을 사용하는것 자체가 좋은 방법이 아닐 수 있다 입니다.

테스트맨 · Answer

클라이언트단에서 access token과 refresh token을 함께 관리하고서버에서 인증실패가 에러가 떨어지면 access token과 refresh token을 함께 전송하는 겁니다.그럼 refresh token이 유효하면 access token을 재발급해주고 아니면 사용자의 로그인 액션을 다시 요청하겠죠그 다음이 이제 탈취되었을때 문제입니다.access token이 탈취당하면 일단 답이없습니다.그렇기 때문에 시간을 짧게 주는것이구요.그러면 이제 refresh token도 함께 탈취당한경우는 어떻게되냐보통은 토큰발행시스템에선 어떤값도 서버에서 관리하지 않지만 ( 모든정보는 토큰에 있음)만약 탈취가 우려된다면 refresh token 정도는 DB에 관리합니다.그리고 탈취가 되었을 때 DB에서 날려버리면 유효하지 않은 refresh 토큰이라고 나오겠죠 만료일이 남은 refresh 토큰이라도 말이죠

심심하다능! · Answer

refresh토큰없이 구현하는 곳도 있어요. 만료기간을 길게 하고요. 사실 별로 추천하는 방법은 아니지만 실제로 그렇게 하는 곳도 있답니다.

kiroki · Answer

RTR이라고 하는 방법이 있습니다. 사용자가 가진 RT가 탈취당하여 공격자가 이를이용해 액세스토큰을 재발급 받았고사용자도 액세스 토큰이 만료되어 리프레시 토큰으로 액세스토큰을 재발급한다고 하면요하나의 리프레시 토큰으로 액세스 토큰을 2번 발급받은 상황이 일어납니다.이때 서버는 이때 사용된 리프레시 토큰으로 발급한 모든 토큰을 취소하는 동작을 합니다이를 위해 리프레시 토큰 체인이라는 데이터를 관리할 필요가 있습니다&#61;> 어느 토큰에서 어떤 토큰이 발급되었고 몇번 사용되었는지에 대한 정보이 로직을 리프레시 토큰에서만 사용하는 이유는요액세스 토큰은 주기가 짧고 api 호출 등 사용이 잦기 때문에성능과 보안의 사이에서 타협했기 때문이라네요

jwt 서버 인증시 access token 만 보내는 경우

5개의 답변

#accesstoken 목록