[TIL] Refresh Token, MSA 20221130

---

로그인의 역사 복습

1. 로그인 요청시, 브라우저 -> 백앤드 -> DB 순으로 요청

2. 검증을 위해 브라우저에서 입력한 데이터가 DB랑 비교

3. 로그인이 완료되면, 백앤드 컴퓨터에 session을 만들어서 저장

4. session ID를 브라우저에 넘겨주고, 브라우저 저장소에 저장함
   *** 브라우저 저장소 : 로컬 스토리지, 세션스토리지, 쿠키, 변수

5. 컴퓨터 메모리를 높혀도 (scale up) 다운되는 현상이 잦아서
   컴퓨터를 늘려서 (scale out)을 통해 다양한 컴퓨터에 저장함

6. DB는 살 수 없으니, 테이블을 나눠서 연결해.

7. I/O 발생, 이를 해결하고자 Redis 사용~

8. Redis도 쓰지말고 JWT 쓰자~
   *** JWT : 객체를 변수로 저장시켜서 암호화 해버림

=> 로그인이 만료되면 어떻게 다시 요청할까?

---

Refresh Token

1. 로그인 요청받고 JWT 토큰 생성 할 때, 똑같은 토큰을 하나 더 만든다.
   ex) JWT access 토큰(1시간 만료) && JWT refresh 토큰 (2주 만료)

2. Access 토큰은 브라우저에서 변수로 받음
   Refresh 토큰은 브라우저에서 쿠키로 받음

3. fetch 요청받으면 Bearer로 Access 토큰을 전송
   fetch API에서 복호화 실시

4. 토큰이 시간이 지나서 만료될 경우!

-> API 사용을 위해 Access 토큰을 보냈는데 토큰 만료!!
-> 토큰만료 에러를 브라우저로 보냄
-> 브라우저에서 에러 캐치!
-> 토큰만료 에러인 지 확인!
-> 토큰만료 에러일 경우, 재발급 API 요청!
-> 재발급을 위해 Refresh Token을 보냄
-> access token을 다시 받아서 새로운 access token을 덮어 씌움
-> 신규 access token을 다시 API로 보냄 -> 인가 성공!!

---

AuthSevice

• 로그인
• 로그아웃
• AccessToken 재발급

구글이나 네이버 등에서 AuthService 제공해줌
=> Open Authentication (OAuth : 소셜로그인)
ex) 브라우저 로그인 요청! - 우리 백앤드 - 구글 백앤드 - 구글 DB

ResourceService

• Fetch User Board Payments 등등
• Create User Board Payments 등등

==> 컴퓨터 다운등의 문제로 전부 마비되는 것을 피하기 위해
Service를 다양하게 나눔 ex) 보드 서비스, 결제 서비스, 회원가입 서비스...
= MSA (Micro service architecture)

---