tecoble/post/2021-05-22-cookie-session-jwt/

[utterances-bot]

인증 방식 : Cookie & Session vs JWT

1. HTTP 특성 HTTP는 인터넷 상에서 데이터를 주고 받기 위한 서버/클라이언트 모델을 따르는 프로토콜입니다. 클라이언트가 서버에게 요청을 보내면 서버는 응답을 보냄으로써, 데이터를 교환합니다. HTTP…

https://woowacourse.github.io/tecoble/post/2021-05-22-cookie-session-jwt/?utterances=f2bc1a7e08d9fd3f995e92cbcfFew8T5KshBIkGMfp9nJdJWdoPED67yiiT6NHqjL%2BezQjtjs1Abfk20fuP5g06EsnO7wV68Px%2BLpndCDhzEUMikm%2By4iDMLFwIIYzzJQ8ogJLcyEc0AnYGwt3U%3D

[Ji-Ha]

안녕하세요! 포스트 잘 읽고 있습니다! 이번 포스트를 읽다가 궁금한 점이 있어서 질문 남깁니다. jwt의 단점에서 payload의 암호화가 되지 않는다고 되어 있는데, token에서 payload는 암호화를 하지 않는 것인가요? 아니면, 암호화는 되지만 뚫릴 위험이 크다는 것인가요? 공부를 하다가 궁금해서 질문남겨봅니다! 감사합니다.

[joniel]

고객이 자신의 액세스토큰이 탈취되었다 생각한다면, 리프레쉬 토큰을 삭제하면 되지 않을까요? 더이상의 액세스토큰 발급이 안될테니...

고객이 글쓰는 도중에 토큰이 만료가 되었을 때는 글쓰기를 눌렀을 때 서버에서 expired되었다고 sendStatus(403)을 날리기보다. 그 토큰에 담긴 아이디로 DB에서 RT를 검색해서 그 RT가 유효하다면 AT를 다시 발급해주고, 일단 그 요청은 통과시켜 글쓰기가 제대로 처리되도록은 안될까요?

아직 구현은 안해보았지만, 궁금해서 찾아보다가 남겨보았습니다. 귀한 글 감사드립니다. orz

[AnneMayor]

@joniel 말씀하신 방식대로 도중에 토큰이 만료되었을 때 바로 토큰에 담긴 아이디로 Refresh Token 유효기간 검증하여 새로 Access Token 발급하게 되면 해커가 그 만료된 Access Token으로 요청을 하게 되면 보안에 취약할 수 있다는 문제점이 생길 수 있을 것 같다는 생각이 드는데요 이거에 대해선 어떻게 생각하시는지 궁금합니다

[jaykiim]

@AnneMayor 클라이언트가 refresh token을 갖고있어야지만 access token을 재발급하게 해주면 어떨까요? 그러니까 만약 글쓰는 도중에 토큰이 만료됐으면 서버에서 바로 access token의 아이디로 refresh token 유효기간을 검증해서 access token을 재발급해주는게아니라 401을 보내긴하는데 대신에 클라이언트에서 axios 응답 인터셉터 같은걸 써서 401로 오는 응답에 대해서는 클라이언트에 도달하기 전에 토큰 재발급해주는 앤드포인트로 재요청을 보내게하고, 그 앤드포인트에서 쿠키헤더로 넘어오는 리프레시 토큰을 검사하게 하는건 어떨까 했는데 생각해보니까 이렇게할거면.. 리프레시 토큰을 DB에 저장해야하는데 그럼 그냥 세션방식을 쓰는거랑 굳이 다를것도 없지않나 싶어서 헷갈리네요 ㅜ

[AnneMayor]

@jaykiim 예 저도 해당 로직으로 구현해보려고 시도했는데 아무래도 그런 식으로 구현할거면 차라리 쿠키-세션 방식으로 구현하는게 물론 성능상으론 이슈가 있을 수 있겠지만 생각하시는 보안과 신뢰도 측면에선 JWT보다 더 나은 방식인 것인지라...ㅎㅎ제가 듣기론 말씀하신 부분은 Oauth 인증 방식과 유사한 것처럼 들리는데 이 부분에 대해서는 저도 좀 알아보고 관련 코멘트 남기도록 하겠습니다 😀

[Joong-Sunny]

장/단점이 궁금했었는데 이 부분 해소 잘되었습니다! 잘 읽고 갑니다!