쿠키, 세션 그리고 JWT

쿠키와 세션이 생겨난 이유는 무엇일까?

우리는 HTTP프로토콜을 사용한다.

HTTP프로토콜의 특징으로는

Connectionless(비연결), Stateless(상태정보 유지X)를 갖고있다.

 

HTTP의 특징

1. Connectionless(비연결)

> 우리는 서버에 요청(Request)를 보내고 서버는 요청에 따른 응답(response)를 보내준다.

 이러한 연결이 지속적으로 연결되어있는게 아니라. 요청 그리고 응답을 하게되면 연결을 끊는 특징을 가지고있다.

 

2. Stateless(상태정보 유지X)

> 서버는 클라이언트의 상태를 저장하지 않는다. 그래서 여러번 요청을 보낸 클라이언트가 같은 클라이언트인지 인지하지 못한다.(서버 비용, 부담 증가)

 

이러한 두개의 특징으로 인해 우리는 특정 웹사이트에 접속할때 로그인을 하여도 상태가 연결되어있지 않기때문에

쿠키와 세션이 없었다면 한 서버에 끊임없이 로그인요청을 보내야 하는 경우가 생긴다.(인증상태를 유지할 수 없기때문)

 

쿠키(Cookie)

> 우리는 로그인을 할 때 id,pw를 입력하여 서버에 요청을 보내게 된다

> 서버는 데이터베이스의 사용자를 확인 후 Cookie를 담아 클라이언트에게 보내준다.

> 클라이언트는 받은 Cookie를 저장해 두었다가 같은 서버로 요청을 할때 Cookie를 같이 담아 요청(Request)를 보낸다.

> 서버는 로그인 정보가 담긴 쿠키를 확인하여 클라이언트에게 응답(Response)를 한다.

 

세션(Session)

> 세션은 쿠키와 다르게 클라이언트가 정보를 갖는것이 아닌 서버측에서 일정시간동안 해당클라이언트의 상태정보를 저장하고 관리하기위해 서버측에 저장이 된다.

> 클라이언트가 로그인시 헤더-쿠키에 세션ID가 담겨있는지 유무를 파악해 동작한다.(각 클라이언트에 고유 세션 ID를 부여)

> 쿠키와 다르게 쿠키는 실제 로컬에 사용자 정보가 저장되는 반면 세션은 서버에 저장되기 때문에 보안상 비교적 안전하다.

> 접속이 끊김과 동시에 세션ID 제거

출처:https://dongsik93.github.io/til/2020/01/08/til-authorization(1)/

 

하지만 세션의 경우도 단점은 존재한다.

> 세션 ID 자체를 탈취할 경우 클라이언트인척 위장이 가능.

> 서버 - 세션 저장소를 사용해 세션ID정보를 저장하므로 서버에 부담이됨.

 

Token 인증 방식

 

> 로그인 시에 서버가 클라이언트에게 인증되었다는 의미의 토큰을 부여하게된다.

> 클라이언트는 새로운 요청시 발급받은 토큰을 담아서 서버에 보내게 된다.

> 서버는 토큰의 위조여부를 파악해 인증 과정을 처리하게된다.

> 세션 저장소를 사용하지 않기때문에 서버자체의 부담을 덜어준다 (장점)

> 쿠키/세션과 다르게 데이터가 길어 네트워크 부하가 심해질수있다 (단점)

> 토큰에 중요한 정보를 담을 수는 없다.

> 토큰 탈취시 대처가 어렵다. (유효기간을 짧게, Refresh Token 등의 방식)

 

JWT (Json Web Token)

> 클라이언트와 서버 사이에서 통신할 때 권한을 위해 사용하는 토큰, 웹 상에서 정보를 JSON형태로 주고 받음.

> 헤더(Header), 페이로드(Payload), 서명(Signature) 세 파트로 나뉘어져 있으며 .으로 구분된다 (아래 그림 참고)

 (xxxxxx.yyyyyy.zzzzzz)

JWT

> 그림과 같이 헤더에는 토큰타입, 사용 알고리즘이 담겨있고, Payload에는 사용자의 속성 및 유효기간이 들어있다.

> 서명(Signature)에는 Header와 Payload를 더한 뒤, Secret key로 해싱해서 생성한다. 

 헤더, 페이로드와는 다르게 Signautre은 서버 측에서 관리하는 secret key가 있어야 복호화가 가능하므로 위변조 여부를 확인할수있다.