개발하기에 앞서 우리는 firebase로 유저 회원가입/로그인을 진행하기 때문에 관련내용을 알아야 될 것 같아서 미리 공부했다.
개인 프로젝트를 했을 땐 firebase auth와 store를 사용해서 토큰을 백엔드로 안넘겨도 됐었다. 그런데 팀플의 경우 백엔드가 따로 있어서 유저 인증을 위해 firebase에서 받은 토큰을 넘겨줘야한다.
보통 authentication의 과정은 다음과 같다.
유저의 아이디와 비밀번호를 서버에 보내면 서버가 이 데이터를 확인하고 유효하면 클라이언트에게 protected 리소스를 요청할 수 있는 endpoint로의 요청을 허용한다.
serer-side session
유저가 로그인을 하면 서버는 특정 인증키가 서버에 저장되고 클라이언트에게 로그인 성공했다는 응답에 인증키를 함께 보낸다. 서버와 클라이언트는 동시에 특정 유저에 대한 인증키를 공유하는 상태가 된다. 클라이언트에서 서버한테 요청을 보낼 때 이 인증키를 같이 보내면 서버는 누가 요청한 건지 구분할 수 있다.
그러나 이 메커니즘은 한가지 단점이 있는데 백엔드와 프론트엔드가 밀접하게 커플링 되어있어야 한다는 점이다. SPA로 웹을 만들면 이 커플링이 깨지게 된다. 프론트엔드와 백엔드가 분리되어 각자의 라이프 사이클을 가지게 된다.
그래서 SPA로 개발된 웹은 식별자를 서버에 저장하는 것은 필요 없게 되었다. 서버는 stateless되야 한다. 즉 서버는 클라이언트와 연결하기 위해 인증키와 같은 데이터를 저장하지 않아야 한다.
authentication token
stateless한 서버를 위해 인증 토큰을 사용한다. 아이디어는 똑같다. 유저가 아이디와 비밀번호로 로그인을 요청하면 서버가 데이터 베이스에 저장된 아이디와 비밀번호를 비교한다.
유효한 데이터면 서버는인증 토큰을 만든다. 이 인증 토큰은 해시 알고리즘을 사용해 어떤 데이터를 인코딩한 하나의 문자열인데 오직 백엔드에서만 디코딩 될 수 있다. 즉 백엔드에서만 구별할 수 있는 것이다.
서버는 이 토큰을 저장하지 않는다. 단지 로그인 되면 응답에 이 토큰을 보낸다. 클라이언트가 요청할 때 이 토큰을 보내면 백엔드는 자신이 만든 토큰인지 알 수 있으므로 유효한지 아닌지를 판단할 수 있다.
