세션(Session) vs JWT

세션(Session)이란?

• 서버에서 클라이언트측의 인증 정보를 저장하고 클라이언트에서 서버로 요청시 해당 인증 정보를 식별하여 인증방식입니다.

세션(Session) 동작 원리

1. 클라이언트에서 서버로 로그인 요청 시도합니다.
2. 서버에서 클라이언트의 로그인 인증완료시 해당 정보를 세션에 저장 후 클라이언트측에 해당 세션의 식별자인 JSESSION ID를 반환해줍니다.
3. 클라이언트는 서버로 부터 전달받은 JSESSION ID를 Cookie에 저장합니다.
4. 클라이언트가 서버에 요청을 보낼 시 쿠키에 저장된 JSESSION ID를 함께 전송합니다.
5. 서버에서는 클라리언트에서 전달한 JSESSION ID와 서버에서 저장된 SESSION 정보를 확인 후 인가 실패 / 성공 여부를 전달합니다.

SESSION 특성

• 쿠키를 포함한 요청이 외부에 노출되어도 SESSION ID 자체는 유의미한 개인정보를 담고 있지 않습니다. 단, 해커가 중간에서 탈취할 경우 클라이언트인척 위장 할 수 있습니다.
• 각 사용자마다 고유한 SESSION ID가 발급되기 때문에 요청이 들어올 때마다 회원정보를 확인할 필요가 없습니다.
• 서버에서 세션 저장소를 사용하므로 요청이 많아지면 서버에 부하가 심해집니다.
• 시스템이 확장될 때 SESSION의 인가를 위해 클러스터링 등의 추가 작업들이 필요합니다.

JWT Token이란?

• JSON Web Token의 약자로 header, payload, signature로 구성되며 base64인코딩을 한 문자열입니다.

header

• typ(타입), alg(알고리즘) 정보가 저장됩니다.

ex)

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

payload

• Token에 담을 정보를 저장하고 있습니다. 주로 클라이언트의 고유 ID값 및 유효기간 등을 포함합니다.
• Key, Value로 이루어져 있으며 이를 클레임(Claim)이라고 합니다.

ex)

{
	"sub": "jwtTest", // 제목
    "name": "shbae", // 이름
    "iat": 1516239981 // 발급 시간
}

signature

• Token을 인코딩하거나 유효성 검사를 할 때 필요한 암호화 코드입니다.
• 인코딩된 header와 payload를 더한 뒤 비밀키로 해싱하여 생성합니다.
• signature는 서버 측에서 관리하는 비밀키가 유출되지 않는 이상 복호화 할 수 없으며 Token의 위변조 여부를 확인하는데 사용됩니다.

JWT Token 동작방식

1. 클라이언트에서 서버로 로그인 시도를 합니다.
2. 서버에서 클라이언트 측에서 전달한 값을 비교하여 인증 성공시 JWT Token 생성을 한 후 클라이언트 측에 전달합니다.
3. 클라이언트는 서버로부터 전달받은 JWT Token을 쿠키에 저장합니다.
4. 클라이언트에서 요청시 마다 서버에서 내려준 JWT Token을 전달합니다.
5. 서버는 클라이언트에서 전달한 JWT Token을 가지고 해당 정보를 확인 후 인가 성공 / 실패 여부를 전달합니다.

JWT Token 특성

• 인증 정보에 대한 별도의 저장소가 필요없습니다.
• 클라이언트 인증 정보를 저장하는 세션과 다르게 서버는 무상태입니다.
• Token 기반으로 다른 시스템에 접근 및 권한 공유가 가능하여 확장성이 우수합니다.
• JWT Token의 길이가 길어 인증 요청이 많아 질수록 네트워크 부하가 심해질 수 있습니다.
• Token은 한 번 생성되면 유효기간이 만료될 때 까지 계속 사용 가능하기 때문에 탈취당하면 대처하기 어렵습니다.

Session과 JWT Token의 차이점

1. 크기 및 부하 위치

• Session의 경우 Session ID가 매우 작지만 JWT Token의 경우 정보를 모두 담고 있기 때문에 크기가 비교적 큽니다.
• Session은 서버에 해당 정보가 저장되어 있어 사용자가 많아질 경우 서버의 부하가 생길 수 있지만 JWT Token은 Session ID보다 크기가 크기 때문에 네트워크의 부하가 생길 수 있습니다.

2. 안전성

• 세션은 서버측에서 저장/관리하지만 JWT Token은 클라이언트측에 저장되기 때문에 공격에 노출될 가능성이 더 큽니다. 따라서 JWT Token에는 민감한 정보는 담지 않습니다. 또한 한번 탈취 당할 경우 JWT Token은 유효기간이 끝날 때까지 대응 할 수 없습니다.

3. 확장성

• JWT Token을 사용하는 이유가 확장성입니다.

• 서버가 여러대인 경우 Session은 각 서버에 지속적인 로그인, sticky session, session clustering 등의 작업이 필요합니다.
  - sticky session은 클라이언트가 처음 지정받은 서버로만 통신을 하는 방식으로 해당 서버가 문제가 생길시 사용할 수가 없습니다.
  - session clustering은 모든 서버마다 세션을 복사해줘야 하기 때문에 상당한 메모리를 요구할 뿐 아니라 매 로그인마다 오버헤드가 크게 발생합니다.

• JWT Token은 서버가 여러대이더라도 별도의 기능 추가 없이 그대로 사용할 수 있습니다.