[TIL] JWT TOKEN, Cookie & Session

현대 웹서비스에서는 토큰을 사용하여 사용자들의 인증 작업을 처리하는 것이 가장 좋은 방법이다.

JWT(Json Web Token)란 Json 포맷을 이용하여 사용자에 대한 속성을 저장하는 웹 토큰이다.

주로 로그인과 같은 처리는 밑사진 같은 로직을 따라 처리 된다고 보면된다.

 

- JWT의 구조

JWT는 Header , Payload, Signature의 3부분으로 이루어지면 각 부분은 Json 형태이다.

 

1.Header 

typ 속성과 alg 속성으로 이루어져있다.

alg는 Signature를 해싱하기 위한 알고리즘을 지정하는 속성

typ는 토큰의 타입을 지정하는 속성이다.

{ 
"alg": "HS256",
"typ": JWT 
}

 

2. Payload 
토큰에서 사용할 정보의 조각들(Claim, key-value로 이루어진 한쌍의정보)이 담겨있다. (=토큰에 담을 정보가 담긴다)

토큰발급자, 토근 제목, 토큰 만료시간, 발급시간, 식별자 등

 

3. Signature(서명)

토큰을 인코딩하거나 유효성 검증을 할떄 사용하는 고유한 암호화 코드이다.

Header와 Payload의 데이터 무결성과 변조 방지를 위한 서명 Header + Payload 를 합친 후, Secret 키와 함Header의 해싱 알고리즘으로 인코딩
Signature는 서버 측에서 관리하는 비밀키가 유출되지 않는 이상 복호화할 수 없습니다.

 

아래그림은 JWT토큰의 예시이다. 결국 JWT는 .을 구분자로 나누어지는 세 가지 문자열의 조합

 

 

- JWT의 장점 

사용자 인증에 필요한 모든 정보를 토큰 자체에 포함하기 떄문에 별도의 인증저장소가 필요 없어진다.

데이터 위변조 막을 수 있음( secret 키에 의해 해싱알고리즘으로 인코딩 되기 떄문에 )

 

- JWT의 단점 

Self-contained : 토큰 자체에 정보를 담고 있으므로 양날의 검이 될 수 있음. ( payload자체는 암호화되지 않기 떄문에 중요한 정보를 담을 수 없음..)

토큰 자체 payload에 정보를 저장하므로 토큰의 길이가 늘어나 네트워크에 부하를 줄 수 있음.

특정 토큰을 강제로 만료시키기 어렵다. ( 메모리상에서 미리 정의 된 비밀키를 이용해 비교하는 것 만으로 인증을 처리하기 때문에)

 

---

Cookie& Session  VS JWT

 

Cookie란  클라이언트가 어떠한 웹사이트를 방문할 경우, 그 사이트가 사용하고 있는 서버를 통해 클라이언트의 브라우저에 설치되는 작은 기록 정보 파일을 말한다. ( Key-Value 형식의 문자열 )

서버는 클라이언트의 요청에 대한 응답을 작성할 때, 클라이언트 측에 저장하고 싶은 정보를 응답 헤더의 Set-Cookie에 담는다. 이후 해당 클라이언트는 요청을 보낼 때마다, 매번 저장된 쿠키를 요청 헤더의 Cookie에 담아 보낸다. 서버는 쿠키에 담긴 정보를 바탕으로 해당 요청의 클라이언트를 식별할 수 있다.

 

-Cookie 단점

보안에 취약함(요청시 쿠키의 값을 그대로 보내기 떄문) 

용량제한이 있어 많은 데이터를 담을 수 없다.

 

쿠키처럼 HTTP를 통해 개인정보를 주고 받는 것은 위험하기 때문에 기존 웹사이트들은 Cookie와 Session을 같이 활용한 인증을 사용했다. 세션은 클라이언트의 인증정보를(비밀번호 등,,,) 서버측에 저장하고 관리한다.

서버는 클라이언트의 로그인 요청에 대한 응답을 작성할 떄, 인증정보는 서버에 저장하고 클라이언트 식별자를 쿠키에 담는다. 이후 클라이언트는 요청을 보낼따마다 이 식별자(JSESSIONID) 쿠키를 함께 보내 서버가 유효성을 판단해 식별할 수 있게 한다.

 

- Cookie & Session 기반 인증 장점 

SessionID 자체에는 개인정보를 담고 있지 않기 때문에 비교적 안전( 물론 해커가 탈취해서 위장할 수 있는 한계존재)

서버쪽에서 Session 통제가 가능 

 

- Cookie & Session 기반 인증 단점

서버에서 세션 저장소를 사용하므로 요청이 많아지면 서버에 부하가 심해진다.. 

 

JWT 기반인증

JWT는 인증에 필요한 정보들을 암호화 시킨 토큰이다. 쿠키/세션 방식과 유사하게 JWT 토큰을 HTTP헤더에 실어 서버가 클라이언트를 식별한다. 

 

-JWT 인증 과정

1. 클라이언트 로그인 요청이 들어오면, 서버는 검증 후 클라이언트 고유 ID 등의 정보를 Payload에 담습니다.
2. 암호화할 비밀키를 사용해 Access Token(JWT)을 발급합니다.
3. 클라이언트는 전달받은 토큰을 저장해두고, 서버에 요청할 때 마다 토큰을 요청 헤더 Authorization에 포함시켜 함께 전달합니다.
4. 서버는 토큰의 Signature를 비밀키로 복호화한 다음, 위변조 여부 및 유효 기간 등을 확인합니다.
5. 유효한 토큰이라면 요청에 응답합니다.

 

-이러한 인증기법들의 대표적 보안전략

1. 토큰의 만료기한을 짧게 설정   

--> 이렇게하면 사용자가 자주 로그인해야되고, 글 작성도중 토큰이 만료되면 submit 요청을 보낼떄 작업이 처리안되고 날라가버림,,,

2. Sliding Session 

위 문제를 해결하도록 서비스를 지속적이용(글작성 시작, 장바구니 담기)하는 클라이언트에게는 자동으로 토큰 만료기한을 늘려주는 보안전략이다.  ---> 접속이 단발성으로 이루어지면 효과가 크지않음

3. Refresh Token 

클라이언트가 로그인 요청을 보내면 서버는 Access Token 및 그보다 긴 만료 기간을 가진 Refresh Token을 발급하는 전략이다. 클라이언트는 Access Token이 만료되었을 때 Refresh Token을 사용하여 Access Token의 재발급을 요청하고 서버는 DB에 저장된 Refresh Token과 비교하여 유효한 경우 새로운 Access Token을 발급하고, 만료된 경우 사용자에게 로그인을 요구합니다    --> 검증을 위해 Refresh Token을 별도의 Strorage에 저장해야하기 떄문에 JWT의 장점인 I/O작업이 없는 빠른인증처리에 반하는 전략이긴 하다.