사용이유를 알려면 먼저 HTTP 통신을 알아야 한다.
HTTP
서버와 클라이언트가 데이터를 주고 받는 통신방법
특징
-
연결을 유지하지 않는다
(한번 통신이 일어나면 바로 끊어짐) -
상태를 유지하지 않는다.
(이 전 통신에대한 정보를 갖고있지 않음)
이러한 특성들 때문에 매번 서버에 요청을 보낼 때 마다 인증을 해 주어야 한다.
위의 이유로 로그인을 유지시킬 방법이 필요하다.
1. DB에 직접 받기
ID/Password 를 받아와, DB와 비교하는 방법
문제점
- 로그인 유지가 안됨
- 페이지를 이동할 때마다 다시 로그인 해야함
- 보안적 문제 발생
2. 세션 방식
- 서버의 메모리, 데이터베이스같은 자원을 사용해 사용자의 로그인 정보를 유지하는 방식
문제점
- 서버의 확장성이 떨어짐
- 서버의 자원이 많이 필요
- 사용자가 로그인을 했을 때는 만들어진 세션을 참조해야 하기 때문에
처음 로그인한 그 서버에서만 요청을 보내야 함
3. 토큰 방식
-
사용자가 로그인을 하면 서버에서 발행해 주는 토큰을 가지고 브라우저의 저장소에 토큰을 유지시키는 방법(JWT)
-
서버에 저장하지 않아서 확장성이 있다.
-
요청이왔을때 해당 토큰이 유효한지만 체크하면 되기 때문에 어떤 서버로 요청을 보내도 상관없음
JWT
Json Web Token의 약자로 두 개체 사이에서 안정성 있게 교환하기 좋은 방법.
JWT는 .을 기준으로 세 파트로 나뉨.
Header
헤더에는 JWT를 어떻게 검증하는지에 대한 내용이 들어감.
토큰의 타입, 암호화 알고리즘이 어떤 알고리즘인지에 대한 정보가 들어있음.
Payload
담아서 보내고자하는 데이터가 담겨있는 곳.
이 정보 조각은 클레임(claim) 이라하고, key-value의 한 쌍으로 이루어짐.
payload에는 여러개의 클레임을 담을 수 있고, 공개 혹은 비공개 할 것인지 등록할 것인지 결정할 수 있다.
Signature
시그니처에는 헤더와 페이로드를 합친 문자열을 서명한 값이 있음.
서명은 헤더의 alg에 정의된 알고리즘과 secret key를 이용해 생성하고 Base64URL-Safe로 인코딩.
secret key를 포함해서 암호화 되어있음.
공개키와 비밀키
JWT는 기본적으로 공개키 암호화방식을 사용하는데, 비대칭 암호화 방식을 이용해 공개 키와 비밀키를 생성하고 이 키들을 상황에 따라 나누어 통신한다.
서명은 비밀 키가 있는 곳에서만 할 수 있고 공개키를 가진 어느곳에서나 이 데이터의 서명을 검증할수있음.
공개키를 가진 누구나 데이터를 암호화해서 보낼 수 있지만,
비밀키를 가진 곳에서만 데이터를 복호화해서 내용을 확인할 수 있다.
비대칭 암호방식이기 때문에
- 비밀키로 암호화한 데이터는 다시 비밀키로 풀 수 없고,
- 공개키로 암호화한 데이터는 공개키로 풀 수 없다.
서명: 비밀키를 가진 사람만 데이터에 서명할 수 있다. 공개 키를 가진 아무나 데이터의 서명을 검증할 수 있다.
암호화: 공개키를 가진 아무나 데이터를 암호화할 수 있다. 비밀키를 가진 사람만 데이터를 복호화해 확인할 수 있다.
JWT 프로세스
"Refresh Token"
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 개념
