feat: 소셜 로그인 계정 복구 흐름 추가 - #299
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e73843d0d3
ℹ️ About Codex in GitHub
Your team has set up Codex to 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 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| }.getOrElse { throw OAuthUserInfoFailedException() } | ||
| ?: throw OAuthUserInfoFailedException() | ||
|
|
||
| if (tokenInfo.appId != expectedAppId) throw OAuthUserInfoFailedException() |
There was a problem hiding this comment.
Allow both Kakao app IDs during the cutover
During the documented backend-first rollout, the old frontend continues calling /api/v1/auth/login, whose access tokens now pass through this same exact app-ID check. Configuring the singular OAUTH_KAKAO_APP_ID for the new app therefore rejects every old-app token before the frontend is switched, while leaving it set to the old ID makes the new v2 smoke test fail. Accept both old and new Kakao app IDs during the migration window so existing users can continue logging in.
Useful? React with 👍 / 👎.
| return authenticated(user, session.provider, false) | ||
| } | ||
|
|
||
| val matchingUsers = userRepository.findAllActiveByNormalizedEmail(normalizedEmail) |
There was a problem hiding this comment.
Serialize account creation by normalized email
If two valid OTP sessions for the same previously unused email are verified concurrently, both transactions can observe an empty result here and then create separate active users, because they lock different session/challenge rows and neither the query nor the schema enforces uniqueness for normalized email. This leaves duplicate accounts that subsequently resolve to SUPPORT_REQUIRED; serialize this resolution by normalized email or add an equivalent database invariant before creating the user.
Useful? React with 👍 / 👎.
변경 사항
POST /api/v2/auth/social/loginPOST /api/v2/auth/social/email/startPOST /api/v2/auth/social/email/verifysocial_identitiessocial_login_sessionsemail_verification_challengessocial_identities로 이관하는 Flyway V47 마이그레이션을 추가했습니다.users.id에 새 식별자 연결SUPPORT_REQUIRED반환/api/v1/auth/login에서 알 수 없는 식별자의 신규 회원 자동 생성을 차단하고ACCOUNT_VERIFICATION_REQUIRED를 반환하도록 변경했습니다.iss,aud,exp를 검증하고 허용된 Client ID만 승인하도록 강화했습니다.app_id를 검증하도록 변경했습니다.OAUTH_APPLE_ENABLED=false로 비활성화할 수 있도록 했습니다..env에 전달하도록 수정했습니다.DEV_OAUTH_GOOGLE_ALLOWED_CLIENT_IDSDEV_OAUTH_KAKAO_APP_IDDEV_OAUTH_KAKAO_REST_API_KEYDEV_OAUTH_KAKAO_CLIENT_SECRETDEV_OAUTH_KAKAO_REDIRECT_URIfalse로 고정변경 이유
Google, Kakao, Apple 소셜 애플리케이션을 새로운 관리 계정으로 이전하면 제공자 식별자가 달라질 수 있습니다. 기존 구조는 알 수 없는 식별자를 즉시 신규 회원으로 생성하기 때문에 기존 회원의 회고·프로젝트 데이터와 분리된 중복 계정이 만들어질 위험이 있었습니다.
클라이언트가 기존 회원과 신규 회원을 선택하지 않고, 이메일 소유권 확인 후 서버가 기존 계정 연결 여부를 결정하도록 변경해 기존 데이터를 보호하기 위해 수정했습니다. 또한 Kakao Client Secret과 액세스 토큰 교환 과정을 브라우저에서 제거하고 제공자별 토큰 검증을 강화했습니다.
개발 배포 시 OAuth 설정이 서버에 전달되지 않으면 Google의 Client ID 검증과 Kakao의 인가코드 교환이 동작하지 않으므로, 기존 개발 배포 워크플로의
.env생성 단계에도 환경변수 전달을 추가했습니다.영향
users데이터가 생성되지 않습니다.users.id가 유지되어 기존 서비스 데이터를 그대로 사용합니다.DEV_OAUTH_*GitHub Secrets가 등록되어 있어야 합니다.(provider, provider_id)중복 여부를 반드시 점검해야 합니다.검증
--rerun-tasks통과spotlessCheck통과git diff --check통과build통과참고
https://dev-app.didit.io.kr, 개발 API는https://dev-api.didit.io.kr기준으로 설정해야 합니다.https://app.didit.io.kr, 운영 API는https://api.didit.io.kr입니다.PROD_OAUTH_*전달은 운영 Secret 등록과 Apple 설정 확정 후 별도로 반영해야 합니다.deploy/SOCIAL_LOGIN_RECOVERY.md의 사전 점검 SQL 실행이 필요합니다.