[Dev_Log] 8/25 (수) 김재우

### 오늘은 어떻게 프로젝트에 기여했나요?
* 토큰 화이트리스트 생성

기존에 Redis에 저장한 블랙리스트에는 아직 만료되지 않았지만 사용하지 않을(로그아웃) 토큰들이 저장된다. 이번에는 좀 더 보안을 강화하기 위해 리프레시 토큰을 이용해서 재발급받을 수 있는 토큰들이 저장된 화이트리스트를 만들었다. 사용자가 로그인을 하면 해당 토큰이 화이트리스트에 저장된다. 이후 토큰이 만료되었을 때 그 토큰이 화이트리스트에 존재한다면 리프레시 토큰을 이용해서 다시 액세스 토큰을 재발급한다. 재발급에 이용된 토큰은 화이트리스트에서 제거한다. 이 로직을 이용해서 만료된 액세스 토큰으로 재발급을 시도 할 때 단 1회만 교환이 가능하도록 구현했다. 만료된 토큰을 검증했을 때만 조회하도록 하여 서버의 부담을 최소화시켰다.

```js
// 이전 Redis 구조
userId: [블랙리스트에 등록된 토큰들]

// 변경한 Redis 구조
userId: {
white: [화이트리스트에 등록된 토큰들],
black: [블랙리스트에 등록된 토큰들]
}
```

* 액세스 토큰 위치 쿠키로 변경

지금까지는 토큰을 리덕스를 사용해 상태로 관리했다. 웹페이지를 새로고침해도 상태가 유지되기 위해 클라이언트에서 리덕스 persist를 적용하였는데, 리덕스 persist는 상태를 로컬 스토리지에 저장한다. 결국 토큰을 웹 스토리지에 저장하는 것으로, 웹 스토리지는 자바스크립트 코드로 접근할 수 있기 때문에 XSS 공격에 취약해진다. 이를 보완하기 위해 토큰 저장 위치를 쿠키로 변경하였다.

쿠키도 물론 안전한 것은 아니다. 하지만 다양한 쿠키 옵션으로 웹 스토리지 보다 좀 더 안전하게 토큰을 관리할 수 있다고 생각했다. HttpOnly 옵션으로 자바스크립트에서 쿠키에 접근하지 못하도록 설정하고, Secure와 SameSite 옵션의 조합으로 HTTPS 프로토콜에서만 쿠키가 전송되도록 설정했다. 또한 CSRF 공격을 대응하기 위해 개발이 완료되면 서버 CORS 옵션의 origin에 Soundbubble 클라이언트 주소만 등록하여 인증된 클라이언트에서만 교차 출처 요청이 가능하도록 변경할 예정이다.

### 오늘의 프로젝트에서 힘든 점은 무엇인가요?
* 개발 환경에서의 쿠키 전송

토큰 전송을 쿠키로 변경하였을 때, Postman으로 로컬에서 실행한 서버에 요청을 보내도 쿠키 전송이 되지 않았다. mkcert로 발급 받아둔 사설 인증서를 이용해서 HTTPS 프로토콜로 로컬 서버를 구축하여 해결했다.

### 내일은 프로젝트에 기여하기 위해 무엇을 해야 하나요?
* [ ] Portal을 이용한 모달 알림창 학습 및 구현