공유할 것

1. 액세스 토큰이 필요한 API 요청
   1. 액세스 토큰이 올바르지 않은 경우: unauthorized error, 2번으로
   2. 액세스 토큰이 올바른 경우: 200
2. 클라이언트는 unauthorized error를 받으면 /refresh 요청
   1. 리프레쉬 토큰이 올바르지 않은 경우: unauthorized error, 3번으로
   2. 리프레쉬 토큰이 올바른 경우: 200 (토큰 재발급)
3. 클라이언트는 unauthorized error를 받으면 로그인 페이지로 리다이렉트, /login요청
   1. 유효한 액세스, 리프레쉬 토큰 발급받게 됨
4. 액세스 토큰이 필요한 API 요청

⇒ 총 4번의 API 요청이 필요하게 됨. 따라서 액세스 토큰이 필요한 API 요청 앞에 토큰 재발급 로직을 미들웨어로 끼워넣는 건 어떨까? 최초의 API 요청에서 토큰 검사하고 setCookie까지 해주는 것으로?

⇒ 좋은데 나중에 생각해보자

• 클라이언트에서 로그인 상태로 볼 수 있는게 user 변수가 있는지 혹은 액세스 토큰이 있는지로 본다.
• 액세스 토큰이 유효하지 알기 위해서는 무조건 서버를 거쳐야한다.
• 우리 API는 user 정보랑 액세스 토큰을 같이 발급해주고 있고, 클라이언트는 액세스 토큰을 인메로리에 저장하기로 했으므로, 로그인 상태는 user 변수가 있는지로 판단할 수 있다.
• 액세스 토큰을 보내면 유저 정보를 보내주는 엔드포인트 뚫어주셈
  • api/user

MongoDB 대신 Redis 사용 어떤 지?

→ 좋은거 같다. (익명 사용자 정보 손실되도 문제 X)

이번 주 할 내용

수만