OAuth의 Redirect URL이 향하는 곳

댓글 달아줘요

---

1. Redirect URL이 백서버를 향하는 경우  

Redirect URL이 백서버를 향하는 순간, 프론트 => 구글 => 백으로 향했기 때문에, 구글에서 백으로 리다이렉트 되는 시점에 프론트와 연결이 끊어진 상태라고 볼 수 있다. 요청 주체가 구글이라서 응답에 토큰을 넣어준다고 해서 클라이언트가 받는게 아니다. 구글이 받고, 아무것도 안한다. 따라서 토큰을 발급한 후에 토큰을 담아 리다이렉트를 시켜주어야 한다. 유저가 없는 경우 디스코드 요청한 유저임을 확인하기 위한 토큰(로그인 토큰X)을 발급해서 클라이언트로 넘어가야 한다. 유저가 있는 경우 로그인 토큰을 가지고 메인 페이지로 이동해야한다. 

 

만약 추가정보를 입력하지 않고 구글의 code만으로 유저 생성이 가능하다면, 그대로 로그인 성공을 할 수 있다. 다만 그렇게 되면 로그인 요청을 하면 무조건 생성이 된다는 단점이 있다.

2. Redirect URL이 프론트를 향하는 경우

Redirect URL이 프론트로 리다이렉트되는 경우, 백서버와의 HTTP 통신으로 요청과 응답이 가능하다. 프론트가 구글에서 코드를 받아오고 해당 코드를 서버로 전달하면, 서버는 구글에 코드를 전달하여 진위를 파악하고 클라이언트에 성공 응답을 보내줄 수 있다. 존재하지 않아 실패 응답을 보낸다면, 프론트에서 실패일 경우 회원가입 페이지로 이동시키는 방식이다. 

---

처음에 잘 협의해야하는 이유

이게 생각보다 서로의 입장을 생각안하고 작성하는 경우가 많다. 따로 정하지 않았다가 리다이렉트를 자연스럽게 자신의 분야로 데려와 놓고, 서로 왜 code가 아니라 token을 주고 받지, token이 아니라 code를 주고 받자하는 경우도 많다. 어떻게 보면 백에서 받은 토큰을 어떻게 다시 프론트한테 줘야하는지에만 집중해서 고민하는 과정이 이어져서 1의 방법이 탄생한거같기도 하다.

 

나는 1의 방법에서 실제 토큰을 주든, 그냥 단순히 계정확인용 역할을 하는 토큰을 새로 만들어서 주든, 굳이 구글 로그인을 통한 code 주고 받기가 있는데 불필요한 작업이 추가되는 것이며, 리다이렉트를 백에서 하는건 부조리하다고 생각한다. 2의 경우에서도 로그인 페이지를 리다이렉트로 해줘야한다는 의견이 있는데, 좀 더 빠르긴 하지만 개발하는 입장에서 예외사항이 아닌가 싶다.

---