세션(Session)과 토큰(Token)의 차이를 알아보자

클라이언트와 서버와의 통신은 일반적으로

요청(Request)과 응답(Response)로 나뉘어진다.

 

클라이언트 측에서 서버에 신호를 보내 무언가를 요청할 때에는 요청,

요청을 받아 서버에서 클라이언트에게 자료를 주는 것은 응답.

 

예를 들어, 사용자가 메뉴판에서 한식 카테고리를 클릭하였을 경우,

클라이언트는 서버에게 한식 카테고리 속의 메뉴들을 보여달라고 요청을 할 것이다.

그러니까, 한식 카테고리 속 비빔밥, 된장찌게, 순두부찌게 등의 메뉴 말이다.

 

그럼 서버 측에서는 그러한 요청을 받고, 서버 DB내 한식 메뉴들을 찾아낸 다음,

이를 클라이언트에게 보내주는 방식으로 응답을 하게 된다.

 

 

 

그런데.. 만약,

만약, 서버 DB내 아무나 접근해서는 안되는 정보가 있다고 가정해보자.

예를 들어 회원 개인정보, 주소 등의 말이다.

 

이러한 중요한 정보들을 클라이언트가 접근할 권한이 있는 사용자인지 먼저 확인을 한 다음에,

권한이 있는 사용자일 경우, 서버에서 클라이언트에게 원하는 정보를 제공해주는 일종의 보안 장치가 필요하다.

여기서,

 

사용자가 어떠한 사람인지 확인하는 절차를 인증(Authentication)이라 하며,

인증된 사용자가 접근 가능한 정보에만 허가를 주는 것을 인가(Authorization)이라 한다.

 

그럼 이런 인증/인가 방식은 어떻게 이루어지는 걸까?

방식은 다양하지만, 가장 많이 사용하는 두 가지 방법, 세션(Session)과 토큰(Token)에 대해 알아보기로 하자.

 

 

 

 

세션(Session)을 통한 인증/인가 방법

 

아래 그림을 통해 이해를 해보자. 먼저,

 

1. 사용자가 로그인을 하기 위해 ID와 Password와 같은 정보를 서버에 보낸다.

2. 서버는 회원 DB내에서 동일한 ID와 Password가 있는 지 확인해본다.

3. 회원임을 확인된 경우, 서버 내 별도의 세션 저정소에 해당 회원 정보 세션을 생성한다.

4. 세션을 생성한 다음, 해당 회원 전용 Session ID를 발급하고,

5. 이를 "로그인 성공"이라는 응답과 함께, Session ID를 사용자에게 보내준다.

 

Session ID는 사용자의 컴퓨터에서 실행 중인 브라우저 내 쿠키라는 형식으로 저장이 된다.

 

로그인 성공한 사용자가 다시 특정 정보를 요청을 하게 될 경우,

6. 데이터를 요청을 함에 동시에 쿠키를 보내주게 된다.

7. 서버의 세션 저장소에는 쿠기 내 Session ID를 통해 인증된 사용자인지 확인한다.

8. 세션 저장소에서 인증된 사용자임을 확인한다.

9. 사용자가 요청한 데이터를 응답 형식으로 보내주게 된다.

이를 그림으로 나타내면 위와 같이 설명이 되겠다.

 

가만히 살펴보면 위와 같은 방식에는 단점이 존재하게 되는데,

로그인 한 사용자가 점점 많아질 수록, "세션 저장소"에 각 유저를 위한 공간을 만들어줘야 한다.

 

이렇게 될 경우, 서버에서 많은 공간을 차지해 부하가 올 수 있으며...

만약에..! 서버가 재부팅 될 경우, 세션 저장소는 날라가게 되어,

모든 사용자가 다시 로그인을 해야 하는 상황이 올 수 있다.

또한 브라우저 내의 쿠기(Cookie)

 

 

 

 

 

 

토큰(Token)을 통한 인증/인가 방법

 

토큰을 통한 인증/인가 방식은 생각보다 간단하다.

1번 - 2번: 위의 방식과 동일하다. ID와 Password를 확인하는 과정이다.

3번: 여기서 차이가 나는데, 별도의 세션과 같은 공간을 생성하지 않고, Access Token(JWT)를 발급하게 된다.

4번: 이렇게 발급한 Token을 응답 형식으로 사용자에게 보내주게 된다.

5번: 사용자가 데이터 요청을 할 경우, 본인이 받은 Token을 함께 보내준다.

6번: 서버에서는 사용자를 검증하고,

7번: 인증된 사용자일 경우, 요청 데이터를 보내주게 된다.

 

한마디로, 서버라는 영화관이 입장할 때, 세션과 토큰은 영화티켓과 같은 거다!