사용이유를 알려면 먼저 HTTP 통신을 알아야 한다.
서버와 클라이언트가 데이터를 주고 받는 통신방법
연결을 유지하지 않는다
(한번 통신이 일어나면 바로 끊어짐)
상태를 유지하지 않는다.
(이 전 통신에대한 정보를 갖고있지 않음)
이러한 특성들 때문에 매번 서버에 요청을 보낼 때 마다 인증을 해 주어야 한다.
ID/Password 를 받아와, DB와 비교하는 방법
사용자가 로그인을 하면 서버에서 발행해 주는 토큰을 가지고 브라우저의 저장소에 토큰을 유지시키는 방법(JWT)
서버에 저장하지 않아서 확장성이 있다.
요청이왔을때 해당 토큰이 유효한지만 체크하면 되기 때문에 어떤 서버로 요청을 보내도 상관없음
Json Web Token의 약자로 두 개체 사이에서 안정성 있게 교환하기 좋은 방법.
JWT는 .
을 기준으로 세 파트로 나뉨.
헤더에는 JWT를 어떻게 검증하는지에 대한 내용이 들어감.
토큰의 타입, 암호화 알고리즘이 어떤 알고리즘인지에 대한 정보가 들어있음.
담아서 보내고자하는 데이터가 담겨있는 곳.
이 정보 조각은 클레임(claim)
이라하고, key-value
의 한 쌍으로 이루어짐.
payload에는 여러개의 클레임을 담을 수 있고, 공개 혹은 비공개 할 것인지 등록할 것인지 결정할 수 있다.
시그니처에는 헤더와 페이로드를 합친 문자열을 서명한 값이 있음.
서명은 헤더의 alg
에 정의된 알고리즘과 secret key
를 이용해 생성하고 Base64URL-Safe
로 인코딩.
secret key
를 포함해서 암호화 되어있음.
JWT는 기본적으로 공개키 암호화방식을 사용하는데, 비대칭 암호화 방식을 이용해 공개 키와 비밀키를 생성하고 이 키들을 상황에 따라 나누어 통신한다.
서명은 비밀 키가 있는 곳에서만 할 수 있고 공개키를 가진 어느곳에서나 이 데이터의 서명을 검증할수있음.
공개키를 가진 누구나 데이터를 암호화해서 보낼 수 있지만,
비밀키를 가진 곳에서만 데이터를 복호화해서 내용을 확인할 수 있다.
비대칭 암호방식이기 때문에
서명: 비밀키를 가진 사람만 데이터에 서명할 수 있다. 공개 키를 가진 아무나 데이터의 서명을 검증할 수 있다.
암호화: 공개키를 가진 아무나 데이터를 암호화할 수 있다. 비밀키를 가진 사람만 데이터를 복호화해 확인할 수 있다.
Access Token 만을 사용했을 때 보안 문제를 해결하기 위해 나온 Refresh Token
위와 같은 방식으로 진행했을 때의 문제점은 Access Token을 탈취 당했을 때이다.
유효기간이 긴 토큰이라면, 그 시간동안 정보를 탈취당하게 되고
또 유효기간을 줄이자니 사용자가 로그인을 여러 번해야 하는 번거로움이 있다.
그래서 나온 것이 Refresh Token
Refresh Token 또한 Access Token과 같은 JWT이다.
로그인을 했을 때 서버에서 Access Token, Refresh Token을 동시에 보내준다
단, 둘의 유효기간을 다르게 해서 보낸다.
Refresh Token을 한 달, Access Token 을 하루로 잡았다면
Access Token의 기간이 다 되어도 Refresh Token의 기간이 남아있기 때문에
사용자는 로그인 없이 다시 Access Token을 발급 받을 수 있다. (로그인 유지)
Refresh Token는 Access Token를 다시 발급받기 위한 JWT.
localStorage 저장 방식
은 공격자가 클라이언트 브라우저에 스크립트를 삽입해 공격하는 XSS(Cross-site scripting)에 취약.
쿠키 저장 방식
은 XSS & 다른 도메인에서 우리 도메인으로 API Call을 날리는 공격하는 CSRF 둘 다에 취약해 질 수 있다.
secure httpOnly
역시 CSRF 공격에 취약.
참고 : JWT 개념