[Joonseok] Week9 미션#103
Conversation
…tomUserDetails를 등록, 등록 안 된 경우에는 다음 필터 체인으로, 등록 되어있지만 유효하지 않은 경우에는 필터 체인을 다음으로 넘기지 않고, 예외를 위로 전파
…nFilter가 작동하도록 설정
…외, 둘 다 통과했다면 JWT를 생성하여 반환하도록 명시
…lder에서 UserDetails의 구현체를 주입받게 수정
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 45ff0bcd20
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| jwtTokenProvider.isExpired(accessToken); | ||
|
|
||
| } catch(JwtException e) { | ||
| set401Response(response); | ||
| } |
There was a problem hiding this comment.
jwtTokenProvider.isExpired(accessToken)의 반환값을 사용하지 않고, JwtException을 잡은 뒤에도 getAuthentication과 다음 필터 체인을 계속 수행하고 있습니다. 이러면 만료 토큰이 그대로 인증 처리되거나(반환값 무시), 예외 토큰에서 401 응답을 쓴 뒤 다시 파싱하다가 필터 단계 예외로 흐름이 꼬일 수 있습니다. Spring Security 필터는 인증 실패 시 SecurityContext를 채우지 않고 즉시 return해야 인증 경계가 명확해집니다. 만료/파싱 실패 시 바로 종료하도록 분기하고, 정상 토큰에서만 Authentication을 생성하세요. 다음으로는 OncePerRequestFilter의 실패 처리 패턴(early return, context clear)을 함께 정리해보면 좋습니다.
Useful? React with 👍 / 👎.
kjhh2605
left a comment
kjhh2605
left a comment
There was a problem hiding this comment.
[키워드 조사]
이번 PR diff에는 Week9 keyword_summary 신규 파일이 확인되지 않았습니다. 기존 keyword_summary 원본은 위키 raw 경로에 보관했습니다. Week9 인증 주제와 직접 연결되는 JWT subject/claim 설계, Access Token과 Refresh Token의 역할, stateless 세션 정책, WebAuthn과 OAuth2의 차이를 별도 문서로 정리하는 것을 권장합니다.
[코드 리뷰]
로그인 API, JWT 발급, JWT 필터, 인증 사용자 기반 /home·/my 조회로 흐름을 전환한 점이 좋습니다. 특히 @AuthenticationPrincipal로 컨트롤러에서 사용자 식별자를 직접 받도록 바꾼 방향은 MVC 책임 분리에 적절합니다. 다만 필터에서 예외 응답을 작성한 뒤 체인을 계속 진행하는 흐름과 인증 기술(WebAuthn/JWT)의 설정 경계를 조금 더 명확히 해야 인증 실패 시 동작을 안정적으로 설명할 수 있습니다.
| jwtTokenProvider.isExpired(accessToken); | ||
|
|
||
| } catch(JwtException e) { | ||
| set401Response(response); |
There was a problem hiding this comment.
예외 응답을 작성한 뒤 return하지 않으면 아래의 getAuthentication()과 filterChain.doFilter()가 계속 실행될 수 있습니다. 인증 실패 응답을 보낸 시점에는 필터 흐름을 종료하도록 정리하는 것을 권장합니다.
| session.sessionCreationPolicy(SessionCreationPolicy.STATELESS) | ||
| ) | ||
|
|
||
| .webAuthn(webAuthn -> |
There was a problem hiding this comment.
JWT stateless 인증 흐름에 WebAuthn 설정이 함께 들어오면 이번 미션의 인증 전략이 어디까지인지 읽기 어려워질 수 있습니다. JWT 로그인, OAuth2 로그인, WebAuthn을 각각 어떤 엔드포인트와 필터 체인에서 다룰지 분리해서 정리하는 것을 권장합니다.
|
|
||
| - 클라이언트에서 자격 증명을 생성하여 인증 요청 | ||
| - 서버에서 자격 증명을 검증하고, `사용자의 정보가 포함된` JWT를 생성하고, 비밀 키(signature)로 해싱 | ||
| - 생성된 JWT를 클라이언트 측에 전송. RFC 6749 문서에 따르면, ResponseBody에 추가하는 것이 옳다고 서술되어 있다.(별다른 보안 문제가 없다면, 추후로도 응답 바디로 반환해줄 것 같다.) |
There was a problem hiding this comment.
RFC 6749는 OAuth2 토큰 응답의 예시로 JSON body를 정의하지만, 애플리케이션 로그인 API에서 Access Token을 반드시 ResponseBody로만 내려야 한다는 의미로 이해하면 범위가 넓어질 수 있습니다. Authorization Code 흐름의 토큰 엔드포인트 응답과, 우리 서비스가 클라이언트에 JWT를 전달하는 API 설계를 구분해서 정리하는 것을 권장합니다.
|
|
||
| ### AccessToken | ||
|
|
||
| 액세스 토큰은 보호된 리소스에 접근할 때 사용되는 자격 증명입니다. 액세스 토큰은 클라이언트 측에서 이해할 수 없게 암호화 처리해야 합니다. 토큰은 `접근 권한` , `유효한 기간` 등의 정보를 담습니다. |
There was a problem hiding this comment.
Access Token이 항상 암호화되어야 한다기보다는, JWT처럼 서명된 토큰은 위변조 검증을 제공하고 내용은 Base64URL 디코딩으로 읽을 수 있다는 점을 구분할 필요가 있습니다. 민감한 개인정보를 claim에 넣지 않는 이유와 JWS/JWE 차이를 함께 정리하면 토큰 보안 이해가 더 명확해집니다.
2 participants
🔗 연관 이슈
🛠 작업 내용
🖼 스크린샷 (선택)
👀 리뷰 요구사항 (선택)
🤖 AI 활용
💬 나의 프롬프트
Spring boot 3.x.x 에서는 ObjectMapper가 기본적으로 Bean 등록이 돼있었는데,
Spring boot 4.0.5 로 업그레이드하니까 ObjectMapper 빈 주입이 안 돼 왜 그런거야?
🧠 AI 응답
Spring boot가 업데이트 되면서
com.fasterxml.jackson.databind.ObjectMapper에서tools.jackson.databind.json.JsonMapper로 JSON 직렬화 라이브러리가 변경되었다고 알려주었다.✅ 내가 최종 선택한 방법 (이유)
ObjectMapper를 JsonMapper로 리팩토링
💡 나만의 Tip (선택)