JWT 인증에 대해서...

jwt를 활용하는 범위는 정하기 나름입니다만 제가 썼던 대로 간단히 써보겠습니다. 클라이언트단 = 프론트엔드 서버단 = 백엔드 1. access토큰의 만료여부 클라이언트단에서 체크 - 만료되지 않았다면 로그인 시킵니다. - 이때 서버에서 로그인을 체크하며 유저 정보를 catch해올 수 있습니다. 단 이 부분은 보안적 처리가 꼭 들어가야 합니다. 최소한의 정보만 가져오는 것이 좋습니다. - 유저 정보를 가져올시, spring security 등의 방식이 적용되면 효과적입니다. (인증, 인가 처리) - access토큰 자체내에도 어느정도 심을수는 있지만 보통 비추합니다. 정 필요할때만 활용하는 것이 좋습니다. (userNo 정도는 암호화해서 심었습니다.) - 만료되었다면 refresh 토큰으로 서버에 갱신요청을 보내는 일을 합니다. 2. access토큰 만료로 인한 refresh토큰 서버단에서 체크 - refresh토큰의 유효정보를 체크하고 갱신후 재발급해줍니다. - 재발급된 access토큰은 클라이언트단에 전송됩니다. - refresh토큰까지 만료되었다면 로그인할 수 없게 합니다. 3. 재발급된 access토큰을 클라이언트단에서 다시 체크 - 1의 단계를 반복합니다. 4. refresh토큰 만료 - 여기는 서비스단의 협의하에 정하기 나름입니다. - 우선 로그인 만료를 사용자에게 표기하고 사용자가 재시도시 refresh를 재발급해주고 또 로그인 할수 있게 해줄지, 아닐지 5. refresh토큰 자체를 안 사용하는 경우? - 일반적이지는 않은 것 같습니다. 왠만해선 refresh와 쌍으로 움직이는게 일반적입니다. 여기까지가 간단한 flow이고 실제 예외는 프론트엔드 <-> 백엔드단 통신시 400 (unauthorized) 코드를 통해 정의하고, 처리합니다. jwt는 기존의 세션 관리로 인한 잦은 서버호출을 방지하기 위해 사용하는 것이므로 클라이언트 단에서 토큰의 만료여부를 꼭 판단할수 있어야 합니다. 또한 access토큰과 refresh토큰을 사용함으로서 여러 다른 처리들이 들어갑니다. 보안적 측면에서는 access토큰이 탈취당하더라도 유효시간이 짧으므로 refresh토큰을 모르면 갱신할 수 없을테지만, 이 요청 자체도 서버에서 검증하고자 하면 jwt를 블랙리스트나 화이트리스트 방식 같은걸로도 관리할 수 있습니다. 이와 같이, jwt를 사용하는 배경 등을 인지하시고 사용하시면 좋을 것 같습니다.