[Network] 쿠키/세션, JWT 개념

📖 HTTP 특성

• Connectionless(비연결지향) : 클라이언트가 서버에 요청을 하고 응답을 받으면 연결이 끊어지는 특징.
• Stateless(상태 정보 유지X) : 연결이 끊어지고 상태 정보는 유지하지 않는것이 특징. 계속해서 통신 연결을 유지하지 않기때문에 리소스 낭비가 줄어주는 장점과 확장성 및 서버 단순성을 증가하지만, 상태 정보를 유지해야 한다면 추가적으로( 쿠키, 세션, JWT ) 필요합니다.

 

🍪 (쿠키/세션/JWT) 인증방식을 알아보기 전에 인증/인가 란 무엇인지 알아봅시다.

• 인증(Authentication) : (식별가능한 정보로) 서비스에 등록된 유저의 신원을 입증하는 과정
  • ex) ID, PW로 로그인 요청을 하는 행위
• 인가(Authorization) : 인증을 받은 사용자가 서비스를 이용할때 사용자의 권한을 허가해주는것
  • ex) 판매자 페이지 - 판매자 권한

---

1. 쿠키

1-1 쿠키의 개념

• 쿠키 : 클라이언트의 브라우저에 저장되고 클라이언트의 정보가 담겨있다. 통신할 때 HTTP 헤더에 포함되는 텍스트 데이터 파일이름, 만료기간, 도메인 등이 있고 키와 값으로 구성되어 있다.

 

1-2 쿠키 인증절차

• 클라이언트가 서버에 요청을 하면 서버는 클라이언트 측에 저장할 정보를 set-cookie에 담아서 클라이언트에게 보내준다.
• 이후 클라이언트는 요청 할 때마다 저장된 쿠키를 헤더의 cookie라는곳에 담아서 보낸다.
• 서버는 쿠키에 담긴 정보를 통해서 해당 요청의 클라이언트를 식별 할 수 있다.

 

1-3 쿠키 장단점

• 쿠키는 제 3자가 조회하는 것도 가능하기 때문에 보안상 민감한 정보를 저장하기에는 적합하지 않다. 그래서 남에게 탈취되거나 조작되어도 크게 문제되지 않을 정보를 브라우저에 저장함으로써 웹사이트 이용을 편리하게 도와주는것이 쿠키이다.

---

2. 세션

2-1 세션의 개념

• 세션 방식은 웹 애플리케이션에서 사용자를 인증하고, 인증된 상태를 유지하기 위해 서버 측에 사용자의 세션 정보를 저장하는 인증 방식.
• 로그인한 사용자의 상태를 관리하고, 각 요청이 인증된 사용자의 요청인지 확인하는데에 사용.

 

2-2 세션 인증절차

• 사용자가 로그인을 하면 서버에서는 계정 정보를 읽어 사용자를 확인한 후, Session ID 값을 세션 저장소에 저장한 후, Session ID를 사용자에게 제공합니다.
• 사용자는 Session ID값을 Cookie에 저장한 후, 어떠한 요청을 할 때에 Cookie를 헤더에 실어서 요청합니다.
• 서버에서는 Cookie를 받아서 세션 저장소에 있는 데이터와 비교해본 후 그에 따른 정보를 제공.

 

2-3 장점

• 사용자의 중요 데이터는 서버에서 관리하기 때문에, 사용자의 데이터가 Cookie에 담겨있는것보다 안전하다.
• 서버가 세션 상태를 관리하므로, 사용자의 데이터관리 및 로그인 상태를 관리하기에 용이하다.
• ex) A라는 모바일 기기에서 로그인이 되어있는데, B라는 기기에 로그인을 했을시에 A기기의 로그인 연결을 끊을 수 있다.
• 일정시간 활동이 없으면 세션이 만료되도록 설정 할 수 있어서, 보안성을 높일 수 있다.

 

2-4 단점

• 모든 세션 데이터를 서버 측에 저장하므로, 사용자 수가 많아지면 서버의 메모리나 저장소에 부담이 간다.
• 이를 보완하기위해서 데이터베이스에 저장(속도가 느림) 하거나 Redis나 메모리형 데이터베이스 서버에 보관하기도 합니다.
• Cookie에 유의미한 정보가 담겨있지는 않지만, 해커가 Session ID를 탈취하여 클라이언트인척 위장을 할 수 있다는 한계가 존재한다.

---

3. JWT 토큰

3-1 JWT 란?

• JWT(JSON Web Token)방식은 인증에 필요한 정보들을 암호화 시킨 토큰을 의미한다.
• 서버가 사용자의 정보를 기억하고 있지않다.
• 최근 들어 더 안정적이고 모바일 환경에 더 적합한 방식으로 사용되는 추세이다.

 

3-2 JWT 인증절차

• 사용자가 로그인을 하면 서버는 데이터를 검증하고, 유효한 경우 사용자 정보를 기반으로 JWT 토큰을 생성한다.
• 토큰의 구조는 헤더(Header), 페이로드(Payload), 서명(Signature)로 나뉘게 된다. 이렇게 토큰에 담긴 사용자 정보등의 데이터를 Claim이라고 한다.
  • Header를 디코딩 해보면 2가지의 정보가 담겨있다. 먼저 type: 토큰의 타입인데 여기에는 언제나 JWT가 고정값으로 들어간다. 다른 하나는 alg인데 알고리즘의 약자이다. 여기에는 Signature의 값을 만드는데 사용 될 알고리즘 값이 지정된다. HS256, HS384 등 여러 암호화 방식 중 하나를 지정 할 수 있다.
  • Payload에는 토큰이 나타내는 실제 데이터를 포함하는 부분이다. ID또는 Role과 같이 사용자의 정보를 저장하는 방식이 아닌, 토큰 자체가 정보를 가지고있는 방식이다.
• Base64로 인코딩된 Header 와 Payload를 합쳐서 나온 문자열을 알고리즘과 Server에 존재하는 Secret키를 사용해서 암호화 된 Signature를 생성하고 사용자에게 access토큰과 refresh토큰을 발급한다.
• 사용자가 서버로 요청을 할때 access token을 요청 header인 Authoriztion에 담아 함께 전달한다. 서버는 이를 검증하고 서버에서 발행한 토큰이라면 인증을 통과시켜준다.
• 사용자가 서버에 요청을 했는데, access token의 유효기간이 만료되었다면, 사용자는 서버에게 refresh token을 건내주고 서버는 새로운 access token과 refresh token을 발급해준다.

 

3-3 장점

• 간편하다. 세션/쿠키는 별도의 저장소의 관리가 필요하다면 JWT는 발급한 후 검증만 하면 되기때문에 추가 저장소가 필요가없어서 관리하기에 편리하다.
• 확장성이 뛰어나다. 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능하다.

 

3-3 단점

• 이미 발급된 JWT에 대해서는 돌이킬 수 없다. 세션/쿠키의 경우에 쿠키가 악의적으로 사용되고있다면, 해당 세션을 지워버리면 되지만 JWT는 유효기간이 완료 될 때까지 사용 가능하다.
• 이에 따른 해결책은 access token의 유효기간을 짧게 설정하고 refresh token을 발급해서 유효기간을 연장하는 방식을 사용 할 수 있다.
• 토큰의 길이가 길어서 인증 요청이 많을수록 네트워크 부하가 심해진다.
• Payload 자체는 암호화되지 않기때문에 유저의 중요한 정보를 담으면 안된다( password 등)