Thread by @0xono_

#FE #BE #JWT

그래서 JWT는 어디에 보관하는게 좋을까

1.
JWT는 JSON Web Token으로 stateless한 웹 환경에서 유저를 인증하기 위한 토큰이다.

서버가 관리하던 세션과 달리, 토큰 자체에 권한 정보 등이 Self-contained된 형태로서 브라우저에서 관리하여 서버의 부담을 줄일 수 있다.

이에 따른 장단점이 존재하는데, 이건 다른 스레드에서 다루겠다.

2.
발급받은 JWT를 브라우저에서 관리할 때, 우리는 몇가지 관리포인트를 생각해볼 수 있다.

1) 휘발성
- JWT는 보통 인증(authentication)에서 발급받아, 인가(authorization)에서 사용한다. 따라서 persistent 하지 않은 곳에서 관리할 경우, 매번 발급해야하는 UX적 오류가 발생한다.

3.
2) 보안성
- JWT는 self-contained token이기때문에, 탈취 당한 JWT이더라도 서버에서 expired될 때까지 조치할 수 있는 방법이 없다. 따라서 보안적으로 우수한 곳에 보관해야하는 개인정보급(또는 그보다 우위의) 데이터이다.

4.
위의 포인트를 기준으로 브라우저에서 1)영속성을 보장할(또는 흉내낼) 수 있는 옵션은 cookie 그리고 localStorage가 있다.

이 둘을 원론적으로 정리하기에는 무리가 있어, jwt 보관 관점에서만 이야기해보자면,

5.
LocalStorage
- CSRF 안전✅
- XXS 취약⚠️

Cache
- CSRF 취약⚠️
- XXS 안전✅

의 성격을 띄고있다.

CSRF = 유저가 의도하지않지만, (피싱사이트 등을 통하여) 유저의 권한으로 서버에 reuqest를 보내는 공격형태

XXS = 브라우저에서 js 코드를 삽입하여 공격하는 형태

6.
Best UseCase
- cookie(http only) + jwt(refresh token)
- 서버에서 매번 access token을 발급받아서 app 내 변수로 관리

이는 서버의 부하는 늘어나지만, cookie를 통해 xxs를 방어하고, access token을 직접 노출시키지않아 CSRF를 방어하여 보다 안전하다고 판단된다.

7.
현재 작업 중인 프로젝트에서는 inbound 정책을 폐쇠적으로 가, CSRF를 해결했기때문에, cookie + access token의 방식을 사용하는 것으로 결정지었다.

8.
추가적으로 SSR의 환경에서는 localStorage(브라우저 종속)값을 알 방법이 없어서, cookie를 사용해야한다.