SEBA's 로그인 관련 정리 - YAPP13-4/semi-basement GitHub Wiki

웹 서비스에서, 회원가입은 User에게 허들로 작용한다.
이런 허들을 낮추고자 Social Login 방식을 채택하였고, 사용자가 많고 예제가 많은 Google Login 방식을 채택하였다.

로그인 매커니즘에서 OAuth, redirection, token 관리 등에 대한 issue가 많았다.
Front와 Back 을 나눠서 각각 Login Flow에 대해 정리한다.

jwt 인가, session인가.. 아니면 그 무엇인가... (스터디 필요)

google oauth 2.0 을 이용한 방식, 구글 로그인 기능을 연동해서 사용함

api : GET / something....

기태님 말씀으로는 프론트에서 백으로 email, name, googleId를 데이터를 넘기면 된다고 한다.

과연 그게 끝일까...? 토큰 이런거 뭐 넘겨야 하지 않나...? (스터디 필요)

백엔드 기능은 디비에 저장된 데이터를 위주로 동작함, 즉 토큰은 사용자가 DB에 저장되어 있는지를 판별하는 용도로만 사용하므로 현재로선 큰 영향을 주지 않음

추 후 리팩토링을 하면서 보안적으로 더 안전한 방식을 채택해 진행하는 것이 필요해 보임

1. client id를 가지고 google에 로그인 요청을 보낸다.

2. response로 무언가를 받는다.(TODO: '무언가'가 무엇인지 정확이 정리하기)

   1. response로 access token, googleId, profileObj,tokenId등을 받고 있다.
   2. refresh token도 받아야 하는데 response에는 없다.

3. back-end에서 필요로 하는 데이터를 post로 넘긴다.

   1. react-google-login 라이브러리 우리가 클라이언트에서 쓰는 라이브러리에 의하면, Authorization header에 tokenId를 넣어 서버로 넘기라고 한다. (jwt기반인듯)
   2. email, name, googleId: 기태님이 요청하신 정보들도 넘겨주기 (회원가입시에만?)

4. back-end는 받은 데이터를 4-1. DB에 인서트하거나(sign up) 4-2. 이미 있는 유저 (sign in)

5. 로그인이 확인이 되었다면 무언가를 해준다. ('무언가'가 무엇일까... 아마 로그인 되었다는 2xx응답과, 클라이언트에게 access권한을 주는 '무엇'이겠지...?)

3-2. 회원가입 시에 해당하는 데이터들을 user 테이블에 insert 함,
이 후 프론트가 token 값을 담아서 request 할 시에 백은 디비에서 해당 토큰 값을 찾아 일치하는 유저가 있으면 기능을 수행하는 방식임

5. 현재로선 로그인이 확인되었다는 응답만 줌, 현재 권한 또는 인증 기능은 디비에 저장된 token에 의존해서 실행중임.

나중에 생각하자...

백에서 진행한 방식은 logout api가 실행되면 유저 컬럼내 access_Token 값을 null 로 바꾸어 줌.
로그아웃한 유저는 token 값이 없기 때문에 다른 기능에 접근하지 못함

https://github.com/livelikeabel/make-note-with-markdown/blob/master/utils/login-study.md