[개념] 토큰과 세션

개요

• HTTP의 비상태성
• 세션
• 토큰

HTTP의 비상태성(Stateless)

HTTP는 요청-응답 쌍으로 이루어진 통신 규약이라고 알고 있습니다.

그렇다면, 요청-응답이 올바르게 진행된 후 응답은 어떻게 흘러갈까요?

클라이언트는 응답받은 데이터를 갖고 있지만, 서버에선 응답한 내용을 일절 저장하지 않습니다.

 

클라이언트는 인증(Authentication)을 거쳐야 하는 경우처럼, 서버에서 제공하는 모든 api에 접근할 권한이 없습니다.

클라이언트가 서버에 인증 요청을 보냈고, 적절한 응답("인증되었습니다"와 같은 문구)를 받았다고 해봅시다.

후에 인증이 필요한 api에 접근할 때, 서버에선 응답을 했었는지 모르기 때문에 인증이 되지 않은 클라이언트라고 판단합니다.

참... 곤란한 상황이네요

그렇다고 인증이 필요한 api를 사용할 때 마다 매번 인증할 수는 없는 노릇이지요.

세션(session)

그렇다면 서버에서 사용자의 정보를 저장하면 어떨까요?

이를 위해 등장한 개념이 세션입니다.

 

클라이언트가 인증 요청을 보내면, 서버에선 적절한 응답과 함께 특정한 키를 보냅니다.

동시에 서버에선 해당 키와 로그인 정보를 서버 내부에 저장합니다.

{
	"session_id": "vnuaerv-23fvdo923",
    	"session_body": "여기에는 인증 정보, 로그인한 유저, 유효기간등이 포함됩니다."
}

클라이언트에선 이 키를 받아두었다, 서버에 요청을 보낼때 쿠키에 담아서 같이 보내면 됩니다.

그렇게 되면 서버에서 키를 읽어와 인증 정보를 검사할 수 있게 됩니다.

 

세션 정보를 저장하는 공간은 DB를 사용할 수 있지만, 보통 크기가 그렇게 크지 않고 빠른 쓰기/읽기 속도를 요구하기 때문에 캐시가 적합합니다.

토큰(token)

그런데 그 많은 사용자의 인증 정보를 전부 저장하려니 너무 힘이 듭니다.

인증 정보를 클라이언트가 갖고 있도록 하면 어떨까요?

 

클라이언트가 인증 요청을 보내면, 서버에선 토큰을 발급합니다.

토큰의 형식중 하나인 JWT(Json Web Token)는 세 부분으로 나눠지는데, 헤더(Header), 페이로드(Payload), 서명(Signature)입니다.

간단히 말해 Header에는 토큰을 암호화 한 알고리즘에 대한 정보,

Payload에는 인증에 대한 정보,

Signature에는 인코딩된 Header와 Payload를 암호화 한 정보, 즉 무결성이 담기게 됩니다.

 

클라이언트에서는 이 발급받은 토큰을 쿠키에 담아, 서버에 요청을 보낼때 같이 보내면 됩니다.

서버에서는 토큰을 다시 해석해서 로그인이 제대로 되었는지, 변조되진 않았는지 검사할 수 있게 됩니다.