[ 사용자 인증 / 인가 ] Session & Cookie VS Token

 

Session과 Token은 무엇일까?

 

 

👉   사용자가 로그인되어있는 상태를 서버가 인지할 수 있도록 하는 방법들 중 하나.

 

 

 

인터넷을 이용할 때 쓰는 HTTP는 Stateless(상태가 없는, 무상태의) 프로토콜이라,

모든 요청이 이전 요청과 독립적으로 다뤄지기 때문에 요청끼리 서로 연결되지 않는다.

이 말은 하나의 요청이 끝나면 서버는 이전 요청에 대한 사용자가 누구인지 잊어버리기 때문에

사용자가 이미 로그인된 상태여도 로그인이 필요한 서비스 or 화면에 접근하려면

새로운 요청을 할 때마다 사용자는 계속 로그인을 반복하며 서버에게 자신이 누구인지

알려주어야 한다는 것이다.

 

그래서 이번 포스팅에서는 이러한 문제를 해결하기 위한 방안들 중에 하나인

session(세션)과 token(토큰)을 이용한 방법에 대해 알아보려고 한다.

 

 

 

---

 

 

 

세션과 토큰에 대해 알아보기 전에 먼저 Authentication(인증)과 Authorization(인가, 허가)에 대해 간단히 알아보자.

 

 

 

👉  Authentication(인증)

인증은 쉽게, 로그인 하는 과정이라고 생각하면 된다.

해당 서비스의 사용자가 맞는지 신원을 확인하는 과정이다.

 

 

👉  Authorization(인가)

인가는 인증(로그인)된 사용자에게 리소스에 접근할 수 있도록 사용 권한을 부여하는 작업으로,

액세스가 허용된 데이터 및 해당 데이터로 할 수 있는 작업들을 지정한다.

 

🧚🏻  나의 상상력을 총동원한 예시 상황 🧚🏻

바다 위에 떠있는 초호화 크루즈라고 상상해보면 🚢
크루즈에 탑승한 탑승객들은 < 크루즈 승선권 > 을 통해 탑승객임을 Authentication(인증) 받은 사람들이다.
그런데 이 크루즈 안에는 아주 유명하고 멋진 초호화 럭셔리 라운지가 있는데,
이 라운지는 모든 탑승객이 이용할 수 있는 곳이 아니라 100% 예약제로만 운영되는 라운지였다.
그래서 모든 탑승객이 이용할 수는 없고,  라운지 입구에 있는 예약자 명단에서
< 해당 탑승객의 이름이 예약자 명단에 있는지 확인 - Authorization(인가) > 의
순서를 거쳐야만, 마침내! 라운지에 입장이 가능한 것이다.

 

위에 적은 예시가 적절하지 않을 수 있지만....😂 

상황을 정리해 보면,

 

 

🍒  탑승권으로 크루즈에 승선하는 행위 = 로그인 = Authentication(인증)

🍑  크루즈 탑승객 = 로그인된 사용자

🫒  개인 객실 = 인가받은 사용자만 확인할 수 있는 화면 및 정보들 (나의 정보, 관리자 권한으로 할 수 있는 것들 등등)

🫐  개인 객실 이용객 = 요청에 대한 접근 권한을 Authorization(인가) 받은 사용자.

 

 

으로 이해하면 될 것 같다. 😄😄

 

 

 

 

---

 

 

 

1. Session & Session Cookie

 

세션은 어떤 사용자가 로그인이 되어있다는 것을 <session id> 를 통해 서버가 인지하고있는 상태이다.

전체적은 flow는 아래와 같다.

 

 

출처:https://hackernoon.com/using-session-cookies-vs-jwt-for-authentication-sd2v3vci

 

1) 사용자가 로그인에 성공하면 서버가 사용자를 위한 세션을 만들고, 세션 데이터를 서비스 환경에 따라

     메모리, 하드디스크, DB 등에 저장한다. ( 이때 세션을 식별하기 위한 세션 id를 기준으로 정보를 서버 측에 저장. )

2) 서버에서 클라이언트(사용자 측)로 세션 id가 담긴 쿠키를 보내고(Set-cookie),  이 세션 id는

     사용자가 인증이 필요한 활동을 하는 동안 클라이언트 측 브라우저에 있는 쿠키에 저장된다. 

3)  클라이언트는 해당 사이트에 대한 사용자의 인가가 필요한 모든 요청에 세션 id를 쿠키에 담아 서버에 전송한다.

4) 서버는 클라이언트가 보낸 세션 id와 서버 측에 저장된 세션 id를 비교하여 verification(유효성 검증) 및

     Authorization(인가)을 통해 해당 요청에 대한 Response를 클라이언트 측에 보낸다.

5) 이후 서버는 사용자가 처음 로그인할 때 저장된 세션 id로 쿠키에 담긴 세션 id를 확인할 수 있다.
    사용자가 웹사이트에서 로그아웃하면 해당 세션 데이터가 서버 측에서 삭제된다.

 

 

 

session & cookie 방식을 이용하게 되면 이렇게 인가가 필요한 요청이 있을 때마다 쿠키에 담긴 세션 id를 보고,

서버측에 저장된 세션 id와 비교 및 탐색을 해야 하고,  사용자가 늘어남에 따라 세션 Id를 저장할 공간도 더 확보해야 한다.

하지만 사용자의 로그인 상태를 모두 저장하고 있기 때문에Stateful의 장점을 활용할 수 있는데,

강제 로그아웃( 그냥 세션을 삭제하면 된다. ),  접속 인원 제한( 넷플릭스 ), 로그인된 모든 디바이스 정보 확인 등등 

로그인과 관련된 다방면으로 활용이 가능하다.

 

 

 

Cookie 란?

 Cookie(쿠키)란 웹 사이트에 접속할 때 서버에 의해 사용자의 브라우저에 저장되는 정보를 의미한다.
사용자를 식별하고, 세션을 유지하는 방식이며, 웹 사이트는 저장된 사용자의 정보를
사용자 측 브라우저에 남겨, 필요할 때마다 재사용하며 모든 브라우저에서 지원한다.
다만 사용자의 정보가 컴퓨터에 남기 때문에 사생활 침해 및 보안 이슈들이 있다.

쿠키는 Key=value 형태로 이루어져 있다.
타입은 String이고, 공간 제약이 있어서 4KB 이상 저장이 불가능하다.

Set-Cookie: <cookie-name>=<cookie-value>​

 

❖ 쿠키는 유효기간이 있고, 서버가 정한 기간에 따라 유효하다.
❖ 쿠키는 인증뿐만 아니라, 다양한 목적으로 사용된다.
       1) 세션 관리 : 서버에 저장해야 할 로그인, 장바구니, 게임 스코어 등의 정보 관리.
       2) 개인화 : 사용자 선호, 테마 등의 세팅.
       3) 트래킹 : 사용자 행동을 기록하고 분석하는 용도.
❖ 세션 쿠키는 현재 세션이 끝날 때 삭제가 된다. 브라우저는 "현재 세션"이 끝나는 시점을 정의한다.
     어떤 브라우저들은 재시작할 때 세션을 복원해서 세션 쿠키가 무기한 존재할 수 있도록 한다.
❖ 지속 쿠키는 Expires 또는 Max-Age 라는 속성에 명시된 날짜에 삭제가 된다.
❖ 쿠키는 브라우저에만 있다. 👉  Native App에서 사용 불가.
❖ 도메인과 패스 디렉티브는 쿠키의 스코프를 정의한다.(어떤 URL로 쿠키를 보내야 하는지) 

쿠키에 대해 더 알아보기

 

 

 

 

 

---

 

 

 

 

2. JWT(Json Web Token)

JWT는 정보를 가지고 있는 토큰으로, 이 인증 방식은 사인(Signature)된 토큰을 통해

해당 토큰이 유효한지 검증하기 때문에 별도의 DB 없이 인증 및 인가가 가능하다. 

토큰 기반 인증 방식과 세션 기반 인증 방식의 가장 큰 차이점은 사용자의 정보를 서버 측에 저장하는지의 여부이다.

 

 

xxxxx.yyyyy.zzzzz 

JWT는 이렇게 점(.) 구분자로 연결돼 있는 3가지의 부분으로 구성된 문자열이다.

 

 

JWT의 Encoded 생김새 - 출처 jwt.io

 

 

1. 빨간 글씨 부분은 Header

2. 보라색 글씨 부분은 Payload

3. 하늘색 글씨 부분은 Signature

 

 

 

 

JWT의 Decoded 생김새 - 출처 jwt.io

 

 

Header 부분을 디코딩 하면 2가지 정보가 담겨있는데 토큰의 타입(토큰의 타입은 JWT 고정값)과

알고리즘 정보가 들어있다.

 

Payload 부분은 사용자의 정보나 데이터 속성 등의 claim이 들어있는데,

서비스 측에서 사용자에게 이 토큰을 통해 공개하기 원하는 내용이 들어간다.

보통 누가 누구에게 발급했는지, 토큰의 유효기간, 사용자 이름, role 등을 Json형태로 원하는 대로 담을 수 있다.

 

Signature는 서명 부분으로, Header + Payload + <서버에 감춰둔 Secret Key> 을

Header의 알고리즘에 넣고 돌리면 Signature(서명) 값이 나온다.

 

 

 

 

 

출처:https://hackernoon.com/using-session-cookies-vs-jwt-for-authentication-sd2v3vci

1) 사용자가 로그인에 성공하면 서버에서는 JWT형태의 암호화된 토큰을 발급(생성)한다. 

2) 생성된 토큰(암호화된 JWT)을 클라이언트에 보낸다.

 

3) 클라이언트가 해당 토큰을 받으면 일반적으로 클라이언트 측의 localStorage에 저장하고, 사용자가 로그아웃하면

토큰이 클라이언트 측(localStorage)에서 삭제된다.

 

4) 사용자가 인증 및 인가가 필요한 요청을 할 때 header에 발급받은 토큰을 담아서 보낸다.

 

5) 서버 측에서는 요청에 토큰 값이 실려오면, JWT의 header와 payload값을 서버측에 감춰둔 secret key와 함께 돌려서

계산된 결괏값이 Signature 값과 일치하는 결과가 나오는지 확인한다.( JWT 유효성 검사 )

 

6) 서명 값과 계산 값이 일치하고, 유효기간도 지나지 않았다면 해당 사용자는 이후 모든 요청에 대해 로그인된 회원으로 권한을 인가(Authorization)한다.

 

 

 

JWT는 서버 측에서 토큰을 추적하는 게 아니기 때문에 편리할 수 있으나, 그렇기 때문에 통제가 불가능하다.

예를 들어 해커가 토큰을 탈취한다면, 해커가 가진 토큰을 무효화할 방법이 없다.

그래서 보통 토큰의 수명을 30분 정도로 짧게 잡는다.

 

로그인에 성공하면 2개의 토큰을 준다.

1) 수명이 몇 시간 또는 몇 분단위로 짧은 access 토큰.

2) 좀 더 긴 수명을 가지고 있는 ( 보통 2주가량 ) refresh 토큰.

 

이 2개의 토큰은 서비스에 맞게 잘 활용하여 여러 가지의 방법으로 구현하면 된다.

 

 

 

---

 

 

Session & Cookie VS JWT

 

이제 이 포스팅의 주제인 세션과 쿠키 방식 VS JWT 방식을 비교해보자 -! 

 

Session-Based Authentication 장점

세션을 이용하면 서버 측은 로그인된 사용자의 모든 정보를 저장하기 때문에 사용자 로그인 관리에 용이하고,

stateful 한 기능들을 사용할 수 있다. (강제 로그아웃 기능, 로그인된 모든 디바이스 정보 확인 기능, 접속 인원 제한 기능(넷플).. 등등)

 

Session-Based Authentication 단점

서버 측에 사용자 로그인 정보가 저장돼 있고, 세션 DB가 필요하기 때문에 트래픽이 많아지면 데이터를 저장할 공간이 더 필요하게 된다.

 

 

 

Token-Based Authentication 장점

토큰 기반 인증은 클라이언트 측에 저장되기 때문에 별도의 DB 없이 로그인 구현이 가능하다.

생성된 토큰을 추적하지 않고 서버가 아는 것은 토큰의 유효성 여부이기 때문에 서버의 부담이 적다.

 

 

Token-Based Authentication 단점

로그인된 사용자를 통제하기 어렵고, 토큰이 만료되기 전까지는 유효하기 때문에 강제 로그아웃 같은 기능을 사용할 수 없고,

해커가 토큰을 탈취했을 때 해당 토큰을 무효화시킬 즉각적인 대응이 불가능하다.

 

 

 

 

---

 

참고 및 출처

 

얄코 Session VS Token Youtube

Nomad Coders의 Differences Between Cookis, Sessions and Tokens Youtube

Session 기반 인증과 Token 기반 인증 참고 블로그

Cookie 내용 참고 블로그