LocalStorage vs Cookie

• Access token : 짧은 수명 주기, 서버로부터 승인을 받아 인증이 필요한 모든 HTTP Request에 포함됌
• Refresh token : 긴 수명 수기, access token이 만료되었을 때 새로운 access token을 발급해주는 토큰

토큰을 어디에 저장해야하는가?

1. localStorage
2. cookies

LocalStorage의 장단점

장점: 편리함

javascript접근이 편리.
Authorization Bearer ${access token} 처럼 HTTP Header에 넣어서 사용.

단점: XSS 공격에 취약

XSS공격은 공격자가 javascript를 실행할 수 있을 때 발생. 이는 localstorage에 저장된 access token이 탈취 당할 수 있다는 얘기다. XSS공격은 프로젝트에 포함되는 third-party library코드에 의해서 발생할 수 있다. 그렇다고 third-party library를 포함하지 않는 것은 불가능 함.

Coockie의 장단점

장점: javascript접근불가, 따라서 localStorage만큼 XSS공격에 취약하지 않다.

XSS공격시 cookie의 httpOnly, secure옵션 사용시 안전
그리고 쿠키는 자동으로 모든 HTTP요청에 포함되어 보내진다.

단점: 일부 케이스에서 토큰을 쿠키에 저장하지 못할 수도 있다.

쿠키는 4kb의 size limit을 가지기때문에 4kb가 넘는 JWT토큰을 사용한다면 쿠키는 적절하지 않을 수 있다.

또한 API서버가 쿠키를 사용할 수 없거나 API의 요청에서 access token을 header에 넣어줘야 한다면 쿠키를 사용할 수 없을것이다.

XSS 공격에 대하여

httpOnly를 적용한 cookie는 javascript로 접근이 불가능하지만 이것이 XSS공격에 완전히 안전하다는 얘기는 아니다.

공격자가 당신의 애플리케이션에서 javascript를 실행할 수 있을 때, 자동적으로 당신의 쿠키가 포함되는 HTTP요청을 서버로 보낼 수 있다. 공격자를 쿠키에 있는 토큰을 읽을 수 없지만 읽지 않아도 공격하는데 크게 문제되는 부분은 없다.

Cookies > LocalStorage ?

cookies가 취약점이 여전히 존재하지만 localStorage보다 선호된다. why?

• localStorage와 cookies 둘 다 XSS공격에는 취약하다. 그러나 쿠키에서 httpOnly플래그를 사용한다면 쿠키가 조금 더 공격자가 접근하기 어렵다.
• 쿠키는 CSRF공겨에 취약하다. 그러나 sameSite플래그와 anti-CSRF tokens를 사용한다면 어느정도 예방가능.
• Authorization: Bearer header를 사용해야 하거나 JWT의 크기가 4kb보다 큰 경우에도 작동 가능하게 할 수 있다.

OAuth 2.0 토큰을 쿠키에 어떻게 적용해야 하는가?

refresh token을 httpOnly cookie에 저장: CSRF공격으로부터 안전하고 XSS노출에 대해 조금 더 낫다.
access token : memory save(변수에 저장, const accessToken = TOKEN_VALUE)
refresh token : cookie

• Step 1
  유저가 인증할 때 access token, refresh token 반환
  refresh token을 cookie에 셋업

  • httpOnly 플래그 사용해서 javascript가 쿠키를 읽는것을 방지
  • secure=true 플래그 사용하면 HTTPS에서만 요청을 보낼 수 있다.
  • 가능하면 sameSite=strict 플래그를 사용해서 CSRF를 방지할 것.
    이 플래그는 Authorization server가 프론트엔드와 같은 사이트일때만
    사용할 수 있다. 만약 이 경우가 아니라면 Authrization server는 CORS header를
    백엔드에서 설정하거나 refresh token요청을 인증된 웹사이트에서만 완료시킬 수 있도록
    어떠한 방법으로든지 세팅해주어야 한다.

• Step 2
  메모리에 access token을 저장. 즉 access token을 변수에 담는다는 것.
  유저가 탭전환, 페이지 새로고침을 하면 access token은 사라진다. 이때 refresh token이 필요하다.
  공격자가 javascript로 데이터를 탈취하기 쉽기 때문에 access token을 localStorage나 cookie에 넣어두지 않는 것이다.
  

• Step 3
  access token이 사라지거나 만료되었을 때, Step 1 에서 cookie에 저장한 refresh token을 /refresh-token endpoint로 보낸다. 그럼 새로운 access token을 받아서 새로운 api요청에 사용할 수 있다. 이는 JWT token은 4kb보다 더 클 수 있고 이것을 Authorization Header에 포함시킬수도 있다는 것을 의미한다.