[Server] 쿠키(Cookie) / 세션(Session) / 토큰(Token) 인증 방식이란?

🔗 Cookie / Session / Token 인증 방식의 종류

• 일반적으로 서버가 클라이언트의 권한을 확인하는 방식은 대표적으로 쿠키, 세션, 토큰의 3가지 방식이 있다.

---

🔗 Cookie

• 쿠키란 Key - Value 형식의 문자열 덩어리이다.
• 클라이언트가 어떠한 웹사이트를 방문할 경우, 그 사이트가 사용하고 있는 서버를 통해 클라이언트의 브라우저에 설치되는 작은 기록 정보 파일이다. 각 사용자마다의 브라우저에 정보를 저장하니 고유 정보 식별이 가능한 것이다.

📍Cookie 인증 동작 과정

   1. 클라이언트가 서버에 요청을 보낸다.

   2. 서버는 클라이언트의 요청에 대한 응답을 작성할 때 클라이언트에 저장했으면 하는 정보를 담은 쿠키 생성

   3. 생성한 쿠키를 클라이언트의 요청에 대한 응답에 담아 보낸다.

   4. 클라이언트에 쿠키가 저장되고, 로컬 PC에 저장하다가 다시 서버에게 요청을 보낼 때 함께 헤더에 담아서 보낸다. 

   5. 서버는 클라이언트가 요청을 하며 담아 보낸 쿠키에 담긴 정보를 바탕으로 해당 요청의 클라이언트가 누구인지 식별한다.

https://velog.io/@narangke3/%EC%9D%B8%EC%A6%9D-%EB%B0%A9%EC%8B%9D%EC%BF%A0%ED%82%A4-%EC%84%B8%EC%85%98-jwt

https://inpa.tistory.com/559

 

📍Cookie 인증 방식의 단점

• 보안에 취약하다.
• 요청 시 쿠키의 값을 그대로 보내기 때문에 유출이나 조작의 위험이 존재한다.
• 쿠키에는 용량 제한(하나의 쿠키는 4kb까지 저장이 가능)이 있어 많은 정보를 담을 수 없다.
• 웹 브라우저마다 쿠키에 대한 지원 형태가 다르기 때문에 브라우저간 공유가 불가능하다.
• 쿠키의 사이즈가 커질수록 네트워크의 부하가 심해진다.

---

🔗 Cookie vs Session

https://velog.io/@narangke3/%EC%9D%B8%EC%A6%9D-%EB%B0%A9%EC%8B%9D%EC%BF%A0%ED%82%A4-%EC%84%B8%EC%85%98-jwt

---

🔗 Session

• 이러한 쿠키의 보안적인 문제 때문에, 세션은 비밀번호와 같은 클라이언트의 민감한 인증 정보를 클라이언트(브라우저)가 아닌 "서버" 측에 저장하고 관리한다.
• 일정 시간동안 클라이언트로부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 일정하게 유지시키는 기술이다.
• 여기서 일정 시간은 방문자가 웹 브라우저를 통해서 서버에 접속한 시점부터, 웹 브라우저를 종료하여 연결을 끝내는 시점을 말한다. → 방문자가 웹 서버에 접속해 있는 상태를 하나의 "단위"로 보고, 그것을 세션이라고 한다.
• 서버의 메모리에 저장하기도 하고, 서버의 로컬 파일이나 데이터베이스에 저장하기도 한다.
• 중요한 것은 중요한 정보는 클라이언트에 보내지 않고 서버에서 모두 관리한다는 점이다.

 

📍Session 인증 방식 동작 과정

1. 유저가 웹사이트에서 로그인 하면 세션이 서버 메모리나 데이터베이스 상에 저장된다.

2. 서버는 클라이언트마다 개별 Session ID를 부여한다.

3. Session ID를 브라우저 쿠키에 담아 응답을 전송한다.

4. 클라이언트는 요청할 때마다 쿠키에 Session ID를 담아 전송한다.

5. 서버는 Session ID가 메모리나 DB에 있는지 확인하고, 이를 통해 클라이언트에 대한 인증을 수행한다.

https://velog.io/@narangke3/%EC%9D%B8%EC%A6%9D-%EB%B0%A9%EC%8B%9D%EC%BF%A0%ED%82%A4-%EC%84%B8%EC%85%98-jwt

https://inpa.tistory.com/559

📍Session 인증 방식의 단점

• 쿠키를 포함한 요청이 외부에 노출되더라도 Session ID 자체가 유의미한 개인정보를 담고 있지 않는다. 그러나 Session ID를 탈취하여 클라이언트인척 할 수 있다.(이 문제는 서버에서 IP를 특정하여 해결할 수 있는 문제이긴 하다.)
• 서버에서 세션 저장소를 사용하기 때문에 요청이 많아지면 서버의 부하가 심해진다.

---

🔗 Token 

• 토큰이란? - 인증을 위해 사용되는 암호화된 문자열
• 토큰 기반 인증 시스템은 클라이언트가 서버에 접속을 하면 서버에서 해당 클라이언트에게 인증되었다는 의미로 "토큰"을 부여한다. 이 토큰은 "유일"하며 토큰을 발급받은 클라이언트는 또 다시 서버에 요청을 보낼 때 헤더에 토큰을 심어 보내고, 서버에서는 클라이언트로부터 받은 토큰을 서버에서 제공한 토큰이 맞는지 확인하고, 인증 과정을 처리한다.
• 세션 기반 인증은 서버가 DB나 메모리에 세션 정보를 저장하고 있어야 하고, 이걸 조회하는데 굉장이 많은 오버헤드가 발생한다. 하지만 토큰은 세션과 달리 서버가 아니라 "클라이언트에 저장"되므로 DB나 메모리에 세션을 관리했던 서버의 부담을 덜 수 있다. 토큰 자체에 데이터가 들어있기 때문에 클라이언트로부터 받아 위조되었는지 판별만 하면 되기 때문.
• 토큰이 인증을 위해 가장 많이 사용되는 이유: 웹에는 쿠키와 세션이 있지만, 앱에는 없기 때문이다.

 

📍Token 인증 방식 동작 과정

1. 유저가 로그인을 한다.

2. 서버에서 유저가 맞는지 확인하고, 인증이 완료 되었다면 클라이언트에게 "유일한 토큰"을 발급한다.

3. 클라이언트는 서버가 준 토큰을 쿠키 혹은 스토리지에 저장해두고, 서버에 요청을 할 때마다 해당 토큰을 서버 HTTP 요청 헤더에 포함시켜 전달한다.

4. 서버는 전달받은 토큰을 검증하고 요청에 응답한다. 토큰 자체에 요청한 사람의 정보가 인코딩되어 담겨있어 서버는 DB를 조회하지 않고 누가 요청하는지 알 수 있다.

https://inpa.tistory.com/559

 

📍Token 방식의 단점

1. 쿠키와 세션과 다르게 토큰 자체의 데이터의 크기가 크기 때문에, 인증 요청이 많아질수록 네트워크의 부하가 심해진다.

2. Payload 자체는 암호화 되지 않기 때문에 유저의 중요한 정보는 담을 수 없다. (jwt 디코딩 하는 사이트 들어가보면 다 나온다. 절대로 중요한 정보는 담으면 안된다. ex. 비밀번호, 사용자 정보 ...)

* JWT(Json Web Token)란 인증에 필요한 정보들을 암호화시킨 JSON 토큰을 의미한다.

3. 토큰은 탈취당하면 대처하기 어렵다. (따라서 만료 기간을 짧게 제한하는 식으로 극복한다.)

 

Token 인증 방식에서 사용되는 토큰인 JWT에 대해서 정리해놓은 글이다. JWT는 토큰 인증 방식을 이해하기 위해 꼭 필요한 개념이므로 숙지하는 것이 좋다.

https://suucong.tistory.com/28 

[Server] JWT란?

---

🔗 Session vs Token

📍Session

• 서버측에서 사용자의 인증정보를 관리하기 때문에, 클라이언트로부터 요청을 받으면 클라이언트의 상태를 계속해서 유지하며 사용해야한다. → Stateful
• 이는 사용자가 증가함에 따라서 성능의 문제를 일으킬 수 있고, 확장성이 어렵다는 단점이 있다.

📍Token

• Session 기반 인증의 단점을 극복하기 위해 등장하였다. 인증받은 사용자에게 토큰을 발급하고, 로그인이 필요한 작업일 경우에 헤더에 토큰을 함께 보내서 인증받은 사용자인지 확인한다. 
• 클라이언트가 요청에 토큰을 담아서 보낼 때만 토큰을 확인하여검증하고 바로 응답을 보내주기 때문에 상태를 유지할 필요가 없다는 장점이 있다. → Stateless

---

🔗 References

https://inpa.tistory.com/559

https://velog.io/@narangke3/%EC%9D%B8%EC%A6%9D-%EB%B0%A9%EC%8B%9D%EC%BF%A0%ED%82%A4-%EC%84%B8%EC%85%98-jwt