[Web] Cookie & Session & Token 인증

인증 방식에 사용되는 Cookie, Session, Token에 대해 공부해보자 ❕

 

서버가 클라이언트의 인증을 확인하는 방법으로 쿠키, 세션, 토큰 인증 방식이 사용된다. 오늘날 많은 서비스들은 토큰 인증 방식인 JWT를 이용하는데, 왜 이 방식을 사용하는지를 이해하기 위해 쿠키, 세션, 토큰 인증 방식에 대해 먼저 정리해보려고 한다.

 

 

 

1. Cookie (쿠키)

---

쿠키는 클라이언트의 브라우저에 저장되는 작은 데이터 조각이다. 서버가 클라이언트에게 쿠키를 발급해주면, 클라이언트 브라우저에 쿠키가 저장된다. 이후 클라이언트가 서버에 리소스를 요청할 때마다 저장된 쿠키를 담아 보낸다.

쿠키는 HTTP Header를 통해 전달되며, 브라우저에 Key-Value 형태의 문자열로 저장되어있다.

 

 

개발자 도구 > Application > Cookies > 해당 사이트 탭으로 이동하면 사이트에서 발급해준 쿠키들을 확인할 수 있다.

(콘솔창에 `document.cookie`를 입력해도 나온다. 이렇게 볼 때는, httpOnly 설정된 것들은 보이지 않는다)

 

 

Cookie 인증 방식

 

1. 유저가 로그인 요청을 하면, 서버는 로그인 정보를 확인한 뒤 쿠키를 발급한다.
   (이 때, 제공하는 서비스에 적합한 쿠키 옵션을 설정해야 한다)
2. 서버는 클라이언트에 저장하고 싶은 정보를 HTTP Header의 Set-Cookie에 담아 응답을 보낸다.
3. 클라이언트 브라우저는 `Set-Cookie`를 확인해 전달된 쿠키를 쿠키 저장소에 저장한다.
4. 이후 클라이언트는 해당 서버에 요청을 보낼 때마다 HTTP Header의 Cookie에 쿠키를 담아 보낸다.
5. 서버는 Cookie 값을 확인해 클라이언트를 식별한다.

 

⇒ 쿠키는 인증 정보를 클라이언트에서 관리하기 때문에 서버 부하가 적고, 매 요청마다 쿠키를 이용해 사용자를 검증하므로 Stateless하다.

 

 

Cookie 인증 방식의 한계

• 쉽게 유출 및 조작할 수 있다.
• 용량 제한(4KB)이 있어 많은 정보를 담을 수 없다.
• 쿠키의 사이즈가 커질수록 네트워크 부하가 심해진다.

 

 

 

2. Session (세션)

---

세션은 클라이언트가 브라우저를 통해 서버에 접속한 시점부터 연결을 끝내는 시점까지 같은 사용자로부터 오는 일련의 요청을 하나의 상태로 보고, 그 상태를 일정하게 유지하는 기술이다.

 

즉, 클라이언트와 서버 간의 상태를 유지하기 위한 메커니즘

 

 

출처 : https://techbriefers.com/how-to-work-with-session-and-cookies-in-codeigniter/

 

세션은 인증정보를 브라우저가 아닌 서버의 메모리나 DB 등에 저장된다. Key-Value 형태로 Key에는 Session ID가 Value에는 세션 생성 시간, 마지막 접근 시간 및 유저가 저장한 속성 등이 Map형태로 저장된다.

 

 

Session 인증 방식

1. 유저가 로그인하면 서버 측에 세션이 생성된다.
2. 서버는 세션을 식별하는 Session ID를 쿠키에 담아 클라이언트에게 전달한다.
3. 이후 클라이언트는 해당 서버에 보내는 모든 요청에 해당 쿠키를 함께 전송한다.
4. 서버는 클라이언트가 보낸 쿠키를 확인해 Session ID를 추출하고, 서버 측에 저장된 Session ID와 비교해 인증을 수행한다.

 

⇒ 세션은 인증 정보를 서버에서 유지하고 관리하기 때문에(stateful) 비교적 안전하고, 한 사용자의 다중 디바이스 접근을 제어할 수 있다. 만약 비정상적인 접근이라면 서버에서 해당 세션을 삭제해 로그아웃시킬 수 있다.

 

 

Session 인증 방식의 한계

• 쿠키가 외부에 노출되더라도 Session ID 자체는 유의미한 정보를 담지 않는다. 하지만 Session ID를 이용해 인증된 유저인척 위장해 서버에 요청을 보낼 수 있다.
• 서버에 저장되므로, 요청이 많아지면 서버에 부하가 생긴다.
• 세션을 서버 메모리에 저장한다면, 서버를 껐다 켰을 때 세션정보가 없어진다.
• 여러 대의 서버로 운영되는 서비스의 경우, 한 서버에서 인증을 했더라도 다른 서버에서는 해당 세션 정보가 없으므로 또다시 인증과정을 거쳐야 한다.
• 세션을 DB에 저장한다면, 매 요청마다 DB 요청을 해야하므로 비효율적이다.

 

 

3. Token (토큰)

---

토큰도 마찬가지로 사용자를 인증하고 권한을 부여하기 위해 사용되는 메커니즘이며, 암호화된 문자열 형태이다.

토큰은 세션과 달리 서버가 아닌 클라이언트 측에 저장되기 때문에 서버의 부담을 덜 수 있다.

토큰은 주로 JWT(Json Web Token)형식으로 사용되며, 서버에서 발급한 토큰은 클라이언트의 쿠키나 스토리지에 저장된다.

 

 

Token 인증 방식

1. 유저가 로그인 요청을 하면, 서버는 로그인 정보를 확인한 뒤 토큰을 발급한다.
2. 서버는 클라이언트에게 토큰을 전달한다.
3. 클라이언트는 전달받은 토큰을 브라우저(쿠키 or 스토리지)에 저장하고, 서버에 요청을 할 때마다 HTTP Header에 토큰을 포함시켜 전달한다.
4. 서버는 전달받은 토큰을 검증하고 요청에 응답한다.

 

⇒ 토큰은 사용자 인증 정보를 클라이언트가 관리하기 때문(stateless)에 서버 부하가 적고, 매 요청마다 서버에서 토큰 검증을 거쳐 안전하게 관리할 수 있다.

 

 

Token 인증 방식의 한계

• 토큰 자체의 데이터 길이가 길어, 인증 요청이 많아질수록 네트워크 부하가 심해질 수 있다.
• Payload(토큰의 내용) 자체는 암호화되지 않기 때문에 유저의 중요한 정보는 담을 수 없다.
• 토큰을 탈취당하면 대처하기 어렵다.

 

 

 

4. 어떤 인증 방식을 택해야 할까?

---

쿠키, 세션, 토큰 방식 모두 장단점이 있기 때문에 서비스의 특성에 맞는 방식을 택해야 한다.

 

쿠키 방식은 인증 정보를 그대로 쿠키에 담아 전송하므로 인증 정보가 중요하지 않거나, 보호해야 할 정보가 없을 경우 도입을 고려할 수 있을 것이다.

세션 방식은 확장성이 떨어지므로 서비스의 크기가 작고, 서버의 성능이 좋다면 도입을 고려할 수 있을 것이다.

 

요즘 대부분의 웹서비스는 토큰을 이용해 사용자 인증 작업을 처리하는데, 그 중 JWT(Json Web Token)을 사용해 사용자 인증을 진행한다. 서버가 사용자 인증에 필요한 정보들을 서명으로 암호화시킨 후 토큰을 발급해 클라이언트에게 전달하는 형태이다. 토큰을 탈취당하면 대처하기 어렵다는 문제를 해결하기 위한 방법으로 토큰 만료시간을 설정하고, AccessToken & Refresh Token으로 토큰을 관리하는 방법이 있다.

 

 

JWT 인증

JWT 토큰 인증 (Access Token & Refresh Token)

 

 

 

 

참고자료

https://velopert.com/2350#google_vignette

https://inpa.tistory.com/entry/WEB-📚-JWTjson-web-token-란-💯-정리