세션 / 토큰 / 쿠키

1. 세션

세션은 클라이언트와 서버 간의 여러 http 요청 및 응답 사이에 상태를 유지하기 위한 방법 (서버 측에서 유지되는 사용자의 상태정보)

일정 시간 동안 같은 사용자(브라우저)로부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 유지시키는 기술.

여기서 일정 시간은 방문자가 웹 브라우저를 통해 웹 서버에 접속한 시점부터 웹 브라우저를 종료하여 연결을 끝내는 시점

 

즉, 방문자가 웹 서버에 접속해 있는 상태를 하나의 단위로 보고 그것을 세션

(사용자와 서버의 관계가 기억되고 보존되어 있는 상태)

 

세션 : 현재 로그인한 유저들의 모든 세션ID 를 DB에 저장한다는 사실 !

요청이 들어올 때마다 서버는 쿠키를 받아서 세션 ID를 보고 세션 ID와 일치하는 유저를 찾아야 함. 

요청이 있을 때마다 DB를 찾아야한다는 의미. (유저가 늘어날수록 DB 리소스가 더 필요함.)

 

• 세션 ID:
  • 서버는 각 클라이언트에 대해 고유한 세션 ID를 생성
  • 세션 ID는 일반적으로 쿠키를 통해 클라이언트에 저장되며, 이후 요청 시마다 서버로 전송함.
• 세션 저장소:
  • 서버는 세션 데이터를 저장하기 위한 저장소를 관리. 저장소는 서버 메모리, 파일 시스템, 데이터베이스, 분산 캐시(예: Redis) 등이 될 수 있음.
• 세션 타임아웃:
  • 세션은 일정 시간 동안 활동이 없으면 자동으로 만료. 이 시간을 세션 타임아웃이라고 함.
• 세션 관리 방법:
  • 쿠키 기반 세션 관리: 세션 ID를 쿠키에 저장하여 관리.
  • 토큰 기반 인증 (JWT): 클라이언트가 JWT를 사용하여 서버에 인증을 요청합니다. JWT는 자체적으로 필요한 모든 정보를 포함하고 있어 서버에서 상태를 유지할 필요가 없음.

* 인증/인가에 대한 이해

인증 (Authenication) : 사용자 신원을 검증하는 프로세스 (쉽게말해서 로그인이라고 생각하면 됨 / ID와 PW를 통해 로그인하는 행위)

사이트에 가입된 회원임을, 증 특성 서비스에 일정 권한이 주어진 사용자임을 아이디랑 패스워드 등을 통해 말 그대로 인증받는 방법

 

인가 (Authorization) : 인증 이후의 프로세스 (인증을 받은 사용자가 서비스 안에서 돌아다닐 때 서버가 이 사용자가 로그인을 한 사용자라는 것을 알아보고 어서와~ 하고 승인해주는 느낌!)

인증된 사용자가 어떠한 자원에 접근할 수 있는지를 확인하는 절차가 바로 인가

 

모든 웹사이트의 인증/인가 과정이 필요하며, JWT는 인증보다는 인가 의 느낌 어떤 사이트나 서비스에 사용자가 로그인해있다는 사실을 서버가 인지할 수 있도록 하는 방법

 

• 보안 고려사항:
  • 세션 탈취를 방지하기 위해 세션 ID를 안전하게 관리하고, HTTPS를 사용하여 전송 중인 데이터를 보호.
  • 세션 고정 공격을 방지하기 위해 세션 ID를 주기적으로 갱신.

세션은 그냥 세션ID만 주면 된다.

세션에 대한 모든 정보는 세션 DB에 저장. 페이지에 요청하면, 세션ID를 DB에서 찾기!

 

 

세션의 경우에는 로그인 된 유저의 정보를 저장해서, 특정 유저를 쫓아내고 싶을 때 세션을 삭제하면 된다.

넷플릭스처럼 계정 공유 숫자를 제한할 수 있음 <- 서버가 누가 로그인 했는지 저장하고 세션DB가 있기 때문에 가능하다.

유저가 늘어나면, db도 늘어나야겠지? 이러한 목적을 수행하기 위한 DB가 redis 디비다.

 

서버는 각 요청이 들어올 때마다 이를 보낸 사용자가 계정으로 로그인, 인증 과정을 거친 상태인지 확인을 해서 각 서비스에 대한 허용을 해줄지 말지를 결정해서 응답을 해줘야함.

매 요청마다 아이디, 패스워드가 실려서 나가면 보안상 이슈도 있고, 시간이랑 자원을 많이 잡아서 요청마다 하는 것은 어려움

 

sessionid를 사용해서 서버에 로그인 되어있음을 지속하는 상태를 => 세션

어떤 사용자들이 현재 로그인해있는지를 가져다가 서버가 기억을 해두고 있는것을 세션 !

메모리에다가 세션 반쪽 올려두면 사용자가 많이 접속하면 메모리가 부족하겠지. 메모리는 휘발성이라 날라가고. 서버가 재부팅하는 상황이 오면 세션이 날라갈 수 있음.

 

2.  쿠키 = 옮기는 시스템 ! 매개체 역할 !! 

쿠키 :  클라이언트(보통 웹 브라우저)에 저장되는 작은 데이터 조각. 쿠키 사용해서 서버는 브라우저에 데이터를 넣을 수 있음.

클라이언트의 상태를 유지하기 위해 사용. 쿠키는 서버가 클라이언트에게 전송하며, 클라이언트는 이 쿠키를 저장하고 이후 요청마다 서버에 다시 전송. 

 

쿠키는 여러가지 정보를 저장할 수 있음.

 

예시 - 웹사이트 언어설정을 바꾸면 서버는 쿠키를 주고, 내가 선택한 언어를 저장함. 이에 다음에 내가 해당 웹사이트에 방문할 때, 쿠키는 요청과 함께 서버로 보내지고 덕분에 서버는 쿠키가 기억해둔 언어설정의 페이지를 제공하는 형태 

 

 

• 사용자가 웹 사이트에 접속하면 서버는 사용자의 브라우저에 세션 ID를 포함한 쿠키를 설정.
• 사용자가 웹 사이트의 다른 페이지를 방문할 때마다 브라우저는 해당 쿠키를 서버로 전송. 
• 서버는 쿠키에 포함된 세션 ID를 통해 사용자의 상태를 유지
  
  쿠키는 공간제약이 있음 (일반적으로 4KB)

중요한 유저 정보는 모두 서버에 있다. 쿠키는 세션ID를 전달하기 위한 매개체 일 뿐, 세션을 이용해 ios,안드로이드 앱을 만들 수 있지만, 쿠키는 사용할 수 없음 (브라우저에만 있기 때문에!) --> 이런 경우에 TOKEN 을 사용함.

 

3. 토큰 = 서버가 기억하는 이상하게 생긴 텍스트 (ID 카드 처럼 서버에게 보여주는 것) / JWT = 정보를 가지고 있는 토큰, DB 없이 검증 가능

다양한 웹 애플리케이션과 API에서 사용자 인증 및 권한 부여를 위해 널리 사용

대표적으로 , JWT가 토큰 형식이다.

 

JWT - Json Web Token

JWT는 세션DB를 가질 필요가 없고, 서버는 유저 인증을 위해 많은 일을 하지 않아도 됨. (세션이나 DB없이 유저 인증!!) 

 

길이의 제약이 없어서, 엄청 길어도 됨.

동일하게 로그인했지만 DB를 건드리는 대신에 정보를 사인하고 전달하는 것이라고 생각하면 됨! (DB 안건들임!!)

 

 

서버가 기억하고 있지 않고, 토큰만 줘버리고 서버는 잊어버린다.

JWT 를 사용하면, 생성된 토큰을 추적하지 않으며, 서버가 아는  것은 토큰의 유효한가 여부만 알 수 있다.

 

이에 강제 로그아웃하는 기능 같은 경우는 사용할 수 없다.

예시 - 코로나 QR 체크인 하는 경우가 jwt 가 들어간 QR코드 인 것 !

 

 

JWT에서 서버는 유저를 인증하는데 필요한 정보를 토큰에 저장 / 그리고 해당 토큰을 줌

페이지를 요청하면, 서버는 해당 토큰이 유효한지만 검증하면 됨! DB를 거칠 필요가 없음!!!

구성 요소

JWT는 세 부분으로 구성된 문자열로, 각 부분은 마침표로 구분

1. 헤더(Header)
2. 페이로드(Payload)
3. 서명(Signature)

 

-- token 예시

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

 

1번 헤더, 2번 페이로드, 3번 서명 (마침표에 따라 구분) 

 

2번 페이로드는 JSON 형식으로 누가 누구에게 발급했는지 , 언제까지 유효한지, 그리고 서비스가 사용자에게 이 토큰을 통해 공개하기 원하는 내용 -> 이를 테면 사용자의 닉네임과 서비스상의 레벨, 관리자 여부 등을 서비스 측에서 원하는대로 담아줌.

이렇게 토큰에 담긴 사용자 정보 등의 데이터를 claim 이라고 함.

 

이게 그 이후 요청들마다 사용자로부터 서버한테 보내지고, 사용자가 받아서 갖고 있는 토큰 자체 정보들이 들어있으며 서버가 요청마다 일일일이 확인해야할 것들이 줄겠지.

1번 헤더 - 디코딩해보면 두가지 정보가 들어가있어.  토큰의 타입인데 여기에 언제나 JWT가 들어감.

다른 하나는 alg가 들어감 (알고리즘의 약자), 3번 서명값을 만드는데 사용될 알고리즘이 지정 (여러 암호화 중 하나 지정)

 

1번 헤더 + 2번 페이로드 + 그리고 '서버에 감춰놓은 비밀값' 셋을 이 암호화 알고리즘에 넣고 돌리면 3번 서명값이 나온다.

--> stateless

 

세션은 stateful - 기억할 수 있는 상태를 제어할 수 있어.

하나의 기기에서만 로그인이 가능하다고 하면, 다른 기기에서 로그인이 진행되었을 때 기존 세션을 종료할 수 있음.

JWT에 가장 큰 결점 - 통제가 어려움. 쥐고 있을 필요가 없어서 편하긴하나, 세션 종료 같은 부분이 어렵다는 단점이 있음.

 

장점:

• 확장성: 서버는 사용자 상태를 저장하지 않으므로, 수평 확장이 용이
• 효율성: 클라이언트가 JWT를 포함하여 요청을 보내므로, 상태 정보를 재확인할 필요
• 보안: 서명된 JWT는 변조가 불가능하며, HTTPS를 통해 전송되면 보안이 강화

단점:

• 탈취 위험: JWT가 탈취되면 만료 시간까지 유효하므로, 공격자가 악용할 수 있음
• 토큰 관리: 토큰을 수동으로 만료시키는 것이 어려움. (예: 사용자가 로그아웃했을 때)
• 페이로드 크기: 많은 데이터를 포함하면 JWT의 크기가 커질 수 있음.

 

비교

특성	토큰	쿠키	세션
저장 위치	클라이언트	클라이언트	서버
용도	인증 및 권한 부여	상태 유지 및 세션 ID 저장	사용자 상태 관리
확장성	높음	보통	서버 리소스 사용
보안	클라이언트 저장으로 탈취 가능성 있음	클라이언트 저장으로 조작 가능성 있음	서버에 저장되어 상대적으로 안전함
상태 유지	상태 비유지	상태 유지 가능	상태 유지 가능
크기 제한	보통 없음	4KB 제한	서버 리소스에 의존

 

 

참고 자료 :

https://www.okta.com/kr/identity-101/what-is-token-based-authentication/

토큰 기반 인증이란? 인증 토큰의 종류와 JWT의 이점 | Okta Identity Korea

https://www.youtube.com/watch?v=1QiOXWEbqYQ

https://jwt.io/

JWT.IO

https://youtu.be/tosLBcAX1vk?si=dRNNEu-GGn2gnLAM

https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html

https://www.baeldung.com/

https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies

Using HTTP cookies - HTTP | MDN

https://velog.io/@ddangle/Session%EC%84%B8%EC%85%98%EA%B3%BC-Token%ED%86%A0%ED%81%B0%EC%9D%98-%EC%B0%A8%EC%9D%B4%EB%8A%94