[refactor] access token 전달 방식 변경 #83
Conversation
dyk-im
left a comment
dyk-im
left a comment
There was a problem hiding this comment.
고생 많으셨습니다! 헤더방식에서 쿠키 방식으로 변경하신 부분을 확인했습니다. 쿠키의 경우 탈취의 위험이나 여타 이유로 일부 브라우저에서 제한이 되는 경우도 있는 것으로 알고있습니다! Https 설정이나 이런 부분들 모두 잘 확인해서 진행해주시면 좋겠습니다!
| public ResponseEntity<GlobalResponseDto<Map<String, String>>> getUserInfo(HttpServletRequest request) { | ||
| // 1. 쿠키에서 Access Token 추출 | ||
| String accessToken = jwtProvider.extractAccessCookie(request) | ||
| .orElseThrow(() -> new CommonException(ErrorCode.INVALID_TOKEN)); |
There was a problem hiding this comment.
쿠키와 api를 함께 사용하는 것인지 궁금합니다! 이런 경우라면 쿠키를 쓰지 않는 케이스도 가능한지 궁금합니다!
There was a problem hiding this comment.
현재 프런트 측에서 "카카오 로그인" 버튼을 누르면 저희 백엔드 측으로 넘어와서 카카오 인가 코드 요청부터 승인, 카카오 액세스 토큰, JWT 인증까지 모두 끝낸 후 "http://wedit/site/"로 이동하게 됩니다.
이때 저희 백엔드 측에서는 인증 절차를 거치면서 사용자 정보와 로그인 상태 등은 이미 DB에 저장되어 있어 저희는 구별이 가능합니다. 그러나 프런트엔드 측에서는 현재 그냥 Cookie안에 해당 사용자 고유의 Access Token과 Refresh Token만 가지고 있는 상태라서 프런트 측에서는 누구를 로그인 상태로 갱신시켜줘야 할지 모릅니다. 그래서 그때 해당 API로 프런트 측의 쿠키에서 Access Token을 추출해서 해당 토큰을 통해 이메일 클레임이 된 이메일을 DB에 저장된 이메일과 비교 및 검사하여 일치하면 프런트에 다시 해당 사용자의 정보를 넘겨줍니다. 그럼 프런트 측에서는 해당 사용자가 로그인한 것을 알게 되고 해당 사용자를 로그인 상태로 변경시켜줍니다.
There was a problem hiding this comment.
사용자 정보 반환을 위해 활용하는 것으로 이해했습니다. 자세한 답변 감사합니다!!
개요
CORS 설정 자체는 “Cross-Origin AJAX 통신에서 응답 헤더를 노출할 수 있느냐”를 결정할 뿐이며,
브라우저가 302 Redirect를 자동 처리해버리는 리다이렉트 응답에 대해서는 프론트엔드 코드가 응답 헤더를 직접 읽을 방법이 없다고 결론남
=> Access Token도 Header가 아닌 Cookie의 형태로 전달할 계획
프런트 측에서 로그인 상태변경을 감지하기 위한 사용자 정보 조회 API 구현
로그아웃 API 구현
PR 유형
어떤 변경 사항이 있나요?
PR Checklist
PR이 다음 요구 사항을 충족하는지 확인하세요.
<성공적으로 Cookie에 담긴 Access Token과 Refresh Token>
<쿠키에 담긴 Access Token으로 백엔드 측 DB에 있는 사용자와 일치하는지 검사 후 정보 전달>
<작동 시, 해당 사용자의 Access Token과 Refresh Token을 즉시 만료시켜 로그아웃 시킴>
📣 To Reviewers