소셜 로그인 후 access token을 발급받는 주체를 백엔드가 아닌 프론트엔드에서 수행하는 것으로 바뀌었다.
상세
기존 소셜 로그인 과정은 다음과 같다.
(카카오 로그인 예시)
카카오 API에 애플리케이션 등록 및 Redirect URI 지정 (Redirect URI는 백엔드의 엔드포인트로 지정)
(클라이언트) 회원이 카카오 로그인 버튼을 누름으로써 카카오 로그인 시도
(카카오 인가 서버) 회원이 카카오 로그인 페이지에서 카카오 로그인
(백엔드) 카카오 로그인 후 회원은 지정된 Redirect URI로 리다이렉트된다. 즉, 브라우저에서 백엔드 서버로 GET 요청을 보내게 된다.
(백엔드) 인가코드를 Request Body에 담아 카카오에 토큰을 받는 요청을 보낸다.
(백엔드) 카카오로부터 access token, refresh token, email을 받으면 이 정보를 프론트로 보낸다. 이 과정은 클라이언트에서 온 요청을 처리하는 과정이므로 Response를 통해 토큰 정보를 보낸다.
이후 변경하고자 하는 과정은 2번까지는 위와 동일하고 3번 이후의 과정을 프론트에서 처리하는 것이다. Redirect URI는 프론트의 엔드포인트로 리다이렉트된다.
(클라이언트) 카카오 로그인 후 프론트 서버로 리다이렉트된다.
(클라이언트) 프론트에서 인가코드를 가지고 카카오 인가 서버로 토큰을 요청한다.
(클라이언트) Access 토큰은 JS 변수나 로컬 스토리지에 저장한다. 이후 백엔드 서버로 API 요청을 보낼 때 Access 토큰을 Authorization 헤더에 담아서 인증/인가에 활용한다.
이 경우 Refresh 토큰을 HTTP-only 쿠키에 담는 처리에 논의해야 한다. 한 가지 대안은 Refresh Token을 백엔드 서버로 보내고 백엔드 서버에서 Refresh 토큰을 HTTP-only, Secure, Samesite 옵션을 걸어서 클라이언트로 응답을 보내는 것이다.
TODO
소셜 로그인 과정이 위와 같이 변경될 경우 백엔드 서버에서 처리해야 할 것은 다음과 같다.
[x] 소셜 로그인 후 받은 인가 코드를 통해 서드 파티 인가 서버로 토큰을 요청하는 로직 제거
[x] Access 토큰을 통해 회원 정보를 가져오는 로직 구현
[x] Access 토큰을 통해 받아올 수 있는 email 정보에 해당하는 회원이 데이터베이스에 없을 경우 회원을 생성하는 엔드포인트 정의
개요
소셜 로그인 후 access token을 발급받는 주체를 백엔드가 아닌 프론트엔드에서 수행하는 것으로 바뀌었다.
상세
기존 소셜 로그인 과정은 다음과 같다.
(카카오 로그인 예시)
이후 변경하고자 하는 과정은 2번까지는 위와 동일하고 3번 이후의 과정을 프론트에서 처리하는 것이다. Redirect URI는 프론트의 엔드포인트로 리다이렉트된다.
이 경우 Refresh 토큰을 HTTP-only 쿠키에 담는 처리에 논의해야 한다. 한 가지 대안은 Refresh Token을 백엔드 서버로 보내고 백엔드 서버에서 Refresh 토큰을 HTTP-only, Secure, Samesite 옵션을 걸어서 클라이언트로 응답을 보내는 것이다.
TODO
소셜 로그인 과정이 위와 같이 변경될 경우 백엔드 서버에서 처리해야 할 것은 다음과 같다.
참고자료