소셜 로그인 접속 토큰 발급 500, 401, 400status 해결법: 카카오편?

DDD 프로젝트에 참여하며 로그인 api 구현 중, 

 

접속토큰 발급 로직에서 예외가 지속해서 발생했었습니다. 게시글에서는 그 문제를 어떻게 해결했는가를 설명합니다.

 

소셜로그인 흐름

프로젝트에서 소셜로그인 과정은 3가지로 이루어져 있습니다.

1. 소셜로그인 서버(카카오, 네이버, 구글 등)로 인가코드 요청을 보내어 인가코드를 받아오는 과정 -> 프론트엔드에서 수행
2. 받아온 인가코드를 백엔드와 협의한 api로 전달 ( ex) /login )
3. 백엔드 서버 내부에서 발급한 jwt 토큰 반환 ( 이때 회원가입이 되어있지 않은 요청일 경우, 회원가입 로직을 진행한 후에 로그인 시도, 아니라면 로그인 진행)

 

예외 발생 지점

외부에서는 500에러, 서버 내부에서는 400, 401 status는 상단의 과정 중에 3번에서 발생하게 됩니다.

3번에서도 토큰을 발급할때, 소셜로그인 서버에서 받아와야하는 응답이 2가지가 존재합니다.

1. 소셜로그인 서버에서 회원 상태를 변환하는 작업 ( ex) 탈퇴 ) 에 필요한 소셜로그인 용 accessToken값 요청
2. 소셜로그인 서버에서 얻어와야하는 email, nickName, 등 회원의 정보
   

이 2가지 과정중에서 

형식에 맞지 않은 요청을 소셜로그인 서버에 보낼경우, 400 에러
인가코드가 만료되었거나, 다른 회원의 인가코드로 인증을 시도할 경우, 401 에러
이렇게 발생한 에러를 헨들러로 관리하지 않으면 서버 외부에서는 500에러로 감지되게 됩니다.

따라서 소셜로그인 서버에서 응답이 제대로 받아와지지 않아 발생하는 오류가 500에러로 감지될 확률이 높습니다!

 

 

해결

처음에, 소셜 로그인 서비스로부터 인가 코드를 받기 위해 설정한 리다이렉트 URI는 프론트엔드 서버 주소(예: localhost:3000)로 지정되어 있었습니다. 이 설정은 사용자가 소셜 로그인을 시도할 때 인가 코드를 프론트엔드 서버로 정상적으로 전달받기 위한 것이었습니다.

그러나, 인가 코드를 받은 후 접속 토큰을 요청하는 과정에서 백엔드 서버 주소(예: localhost:8080)를 리다이렉트 URI로 설정하는 과정에 예외가 발생했습니다. 이는 소셜 로그인 서버가 두 요청 사이의 리다이렉트 URI가 일치하지 않음을 감지하고, 보안상의 이유로 요청을 다른 것으로 간주하여 접근 토큰 발급을 거부하는 원인이 되었습니다.

이 문제를 해결하기 위해서는 백엔드에서 접속 토큰을 요청할 때도 프론트엔드에서 인가 코드를 받을 때 사용했던 동일한 리다이렉트 URI를 사용해야 합니다. 즉, 백엔드 서버가 소셜 로그인 서버에 접속 토큰을 요청할 때는 프론트엔드 서버의 주소(예: localhost:3000/login/process)를 리다이렉트 URI로 명시해야 합니다. 이렇게 하면 리다이렉트 URI가 일치하게 되어, 소셜 로그인 서버는 요청을 받아 접근 토큰을 발급할 수 있습니다.