TIL : 서버 인증 방식 (쿠키, 세션, 토큰) (15)

🍪 쿠키 인증 방식

쿠키란? 서버를 통해서 클라이언트 쪽에 저장되는 Key-Value 형식의 문자열 덩어리이다.

이 쿠키를 통해서 클라이언트가 누구인지 인증한다.

🌊 Flow

• 클라이언트가 서버에 요청을 보낸다.
• 서버가 요청에 대한 응답 헤더에 쿠키를 담아서 보낸다.
• 이후 클라이언트가 요청을 보낼 때마다 쿠키를 같이 보내고 서버는 해당 쿠키로 클라이언트를 확인한다.

🧷 단점

• 요청 시 쿠키의 값을 그대로 보내기 때문에 보안성이 떨어진다.
• 쿠키에는 용량 제한이 있다.
• 브라우저마다 쿠키 지원 형태가 다르기 때문에 공유가 불가능하다.

---

📖 세션 인증 방식

쿠키의 보안 이슈를 해결하기 위해 클라이언트 쪽이 아닌 서버 측 저장소에 보관하는 방식이다.

쿠키와 마찬가지로 Key-Value의 형태의 데이터를 저장하고 Key는 Session ID,

Value에는 세션 생성 시간, 접근 시간, User 데이터를 Map 형태로 저장한다.

🌊 Flow

• 클라이언트 쪽에서 ID, PW로 인증을 요청한다.
• 인증이 정상적으로 처리되면 서버는 세션 스토레지에 Session ID를 저장한다.
• 서버가 요청에 대한 응답에 Session ID를 같이 넣어서 보낸다.
• 클라이언트의 브라우저의 쿠키 영역에 Session ID를 저장한다.
• 이후 요청마다 쿠키 영역에 저장된 Session ID로 인증을 요청한다.
• 서버는 받은 Session ID와 저장된 Session ID를 비교하여 인증을 수행한다.

🧷 단점

• Session ID가 노출되면 보안상의 문제가 발생한다.
• 요청이 많아지면 서버 부하가 심해진다.
• 서버가 여러 개라면 서버마다 세션이 따로 존재하기 때문에 인증에 문제가 발생한다.

---

🪙 토큰 인증 방식

클라이언트의 인증이 완료되었을 때 서버가 클라이언트에게 일종의 통행증(토큰)을 부여하는 방식이다.

발급받은 토큰을 통해서 이후 인증들을 처리한다.

🌊 Flow

• 클라이언트 쪽에서 ID, PW로 인증을 요청한다.
• 인증이 정상적으로 처리되면 클라이언트에게 토큰을 발급한다.
• 클라이언트는 토큰을 저장해두고 이후 요청을 할 때마다 헤더에 토큰을 포함해서 전달한다.
• 서버는 전달받은 토큰을 검증하고 요청에 응답한다.

🧷 단점

• 토큰 자체의 데이터가 커서 요청이 많아지면 네트워크 부하가 심해질 수 있다.
• 토큰이 노출되면 대처하기 어렵다.

🧐 왜 토큰 인증 방식을 많이 쓸까?

웹과 달리 앱에는 쿠키와 세션이 존재하지 않는다. 따라서 토큰 방식이 적합하다.

서버가 많아져 세션 공간이 달라도 제한이 없고 단순히 유효한 토큰인지만 검사하면 되기 때문이다.