[Jinyong] Week9 미션 #110
Conversation
kjhh2605
left a comment
kjhh2605
left a comment
There was a problem hiding this comment.
[키워드 조사]
세션/토큰, Access Token/Refresh Token, OAuth 1.0/2.0 차이를 표로 정리한 점이 좋습니다. 다만 OAuth2를 소셜 로그인 기능 자체로만 이해하기보다 Authorization Code Grant의 참여자(Resource Owner, Client, Authorization Server, Resource Server)와 redirect URI, scope, consent가 어떤 역할을 하는지 함께 정리하는 것을 권장합니다. Refresh Token은 저장 위치, 재발급 API, 탈취 시 폐기 전략까지 연결하면 학습 완성도가 높아집니다.
[코드 리뷰]
일반 로그인, JWT 필터, OAuth2 성공 핸들러를 한 흐름으로 연결하며 Spring Security 학습 범위를 넓힌 점이 좋습니다. Controller-Service-Repository 계층도 대체로 유지되어 있습니다. 다만 stateless API를 의도한 설정과 세션 정책이 어긋나는 부분, OAuth 인증 객체의 권한 모델, 인증 API DTO 입력 검증이 아직 불명확합니다. 일반 회원과 소셜 회원의 식별 기준(email, socialUid, socialType), JWT subject/claim 설계, SecurityContext에 저장되는 principal 타입을 표로 정리한 뒤 코드와 맞추는 것을 권장합니다.
|
|
||
| OAuth는 사용자의 비밀번호를 직접 공유하지 않고, 제3자 애플리케이션이 사용자의 리소스에 제한적으로 접근할 수 있게 해주는 권한 위임 프로토콜이다. | ||
|
|
||
| 쉽게 말하면, “카카오로 로그인”, “구글로 로그인” 같은 기능이 OAuth 기반으로 동작하는 것이다. |
There was a problem hiding this comment.
OAuth2를 현재 표준이라고 정리한 점은 좋습니다. 추가로 Authorization Code Grant에서 Client, Authorization Server, Resource Server가 각각 어떤 책임을 가지는지 함께 정리하는 것을 권장합니다. 그러면 OAuth2가 단순한 소셜 로그인 구현이 아니라 권한 위임 프로토콜이라는 점이 더 명확해집니다.
| String password | ||
| ){} | ||
|
|
||
| // 로그인 |
There was a problem hiding this comment.
로그인과 회원가입 요청 DTO가 분리된 점은 적절합니다. 다음 단계에서는 @Email, @NotBlank, 비밀번호 길이 조건처럼 입력 계약을 DTO에 명시하고 Controller에서 @Valid로 검증하는 것을 권장합니다. 인증 API는 잘못된 입력이 Service까지 내려가지 않도록 경계를 세우는 연습이 중요합니다.
| .permitAll() | ||
| // 1. 기존 폼 로그인 기능을 끈다 | ||
| .formLogin(AbstractHttpConfigurer::disable) | ||
|
|
There was a problem hiding this comment.
주석에서는 세션을 사용하지 않는 구조로 설명하지만 실제 설정은 IF_REQUIRED라서 Spring Security가 필요 시 세션을 만들 수 있습니다. JWT 기반 REST API 학습 목적이라면 SessionCreationPolicy.STATELESS로 맞추고, OAuth2 로그인 과정에서 세션이 필요한 구간과 JWT 발급 이후 무상태 API 구간을 분리해 이해하는 것을 권장합니다.
| @Override | ||
| public Collection<? extends GrantedAuthority> getAuthorities() { | ||
| return List.of(); | ||
| } |
There was a problem hiding this comment.
OAuth 인증 객체가 빈 권한 목록을 반환하면 성공 핸들러에서 만든 JWT의 role claim도 비어 있게 됩니다. 현재는 authenticated() 중심이라 바로 드러나지 않을 수 있지만, 이후 hasRole/hasAuthority를 사용하면 권한 판단이 어려워집니다. 일반 로그인용 AuthMember와 OAuth 로그인용 OAuthMember가 동일한 권한 모델을 갖도록 맞추는 것을 권장합니다.
2 participants
🔗 연관 이슈
closes #109
🛠 작업 내용
🖼 스크린샷 (선택)
👀 리뷰 요구사항 (선택)
🤖 AI 활용
💬 나의 프롬프트
JWT 토큰 기반 회원가입, 로그인, 마이페이지 인증 흐름을 어떻게 구현해야 하는지 질문했습니다.
특히 기존 회원가입 API에서 비밀번호를 BCrypt로 암호화하고, 로그인 성공 시 JWT accessToken을 발급한 뒤 Swagger Authorize에 토큰을 넣어 마이페이지 API를 호출하는 흐름을 어떻게 검증해야 하는지 물어봤습니다.
추가로 선택 미션인 카카오 OAuth 구현 과정에서 카카오 Developers 설정, Redirect URI, application.yml 설정, OAuthSuccessHandler, CustomOAuthService, JWT 발급 흐름에서 발생한 에러를 어떻게 해결해야 하는지도 질문했습니다.
🧠 AI 응답
AI는 JWT 인증 흐름을 회원가입 → 로그인 → 토큰 발급 → Swagger Authorize → 마이페이지 조회 순서로 정리해주었습니다.
또한 카카오 OAuth에서는
/oauth/authorize/kakao로 요청을 시작하고, 카카오 동의 후/oauth/callback/kakao로 돌아와 JWT를 발급하는 구조를 설명해주었습니다.디버깅 과정에서는
authorization_request_not_found,invalid_client,Not exist client_id같은 에러 원인을 분석해주었고, 세션 설정, Redirect URI 불일치,client-authentication-method: client_secret_post설정 필요성을 알려주었습니다.✅ 내가 최종 선택한 방법 (이유)
필수 미션은 이메일/비밀번호 기반 회원가입과 로그인을 구현하고, 로그인 성공 시 JWT accessToken을 발급하는 방식으로 진행했습니다.
이 방식을 선택한 이유는 과제에서 요구한 “JWT 토큰 방식의 회원가입, 로그인 구현”을 가장 직접적으로 확인할 수 있었기 때문입니다.
또한 Swagger에서 로그인 API로 발급받은 JWT를 Authorize에 넣고
/api/v1/users/meAPI를 호출하면, 토큰 인증이 정상적으로 동작하는지 명확하게 검증할 수 있다고 판단했습니다.선택 미션은 Spring OAuth Client를 활용해 카카오 OAuth 로그인을 구현했습니다.
직접 카카오 서버와 통신하는 방식도 가능하지만, Spring OAuth Client를 사용하면 인증 요청, 콜백 처리, 사용자 정보 조회 흐름을 Spring Security 구조 안에서 처리할 수 있기 때문에 이 방식을 선택했습니다.
카카오 로그인 성공 후 사용자 정보를 DB에 저장하고, OAuthSuccessHandler에서 JWT accessToken을 발급하도록 구성했습니다.
이후 발급된 토큰으로 마이페이지 API를 호출하여 200 OK 응답과 사용자 정보 조회가 되는 것을 확인했습니다.
💡 나만의 Tip (선택)