보통 서버가 클라이언트 인증을 확인하는 방식으로 크게 3가지로 나눌 수 있다- (Cookie/ Session/ Token)
1. Cookie 인증
- Key-Value 형식의 String문
- 클라이언트가 어떤 웹사이트를 방문했을 때, 서버를 통해 클라이언트의 브라우저에 설치되는 작은 기록 데이터 파일이다. 각 유저마다의 브라우저에 정보를 저장하기 때문에 고유 정보 식별이 가능하다.
- 브라우저마다 저장되는 쿠키가 다르다.
1-1. Cookie 인증방식
1️⃣ 클라이언트가 서버에 요청을 보낸다.
2️⃣ 서버는 클라이언트의 요청에 대한 응답을 작성할 때, 클라이언트 측에 저장하고 싶은 정보를 응답 헤더의 Set-Cookie에 담는다.
3️⃣ 이후 해당 클라이언트는 요청을 보낼 때 마다 매번 저장된 쿠키의 요청 헤더의 Cookie에 담아 보낸다.
1-2. 장점
- 각각의 유저들의 정보를 저장하고 있기 때문에 로그인과 같은 번거로운 작업등을 편리하게 처리할 수 있음
- 사용자마다 저장하는 정보가 다르기 때문에 사용자에 맞게 웹사이트 모드를 설정할 수 있기 때문에 클라이언트 입장에서는 편리함
1-3. 단점
- 보안에 취약함 (요청 시에 쿠키의 값을 그대로 보내기 때문에 유출 및 조작 당할 위험성)
- 웹 브라우저마다 쿠키에 대한 지원 형태가 다르기 때문에 브라우저간 공유가 불가능함
2. Session 인증
- 비밀번호 등 클라이언트의 민감한 인증 정보들을 브라우저가 아닌 서버 측에 저장하고 관리 (쿠키의 보안적 이슈 보완함)
- 클라이언트가 아닌 서버에서 모두 관리
2-1. Session 인증 방식
1️⃣ 유저가 웹사이트에서 로그인할 때 세션이 DB에 저장된다.
2️⃣ 서버에서 브라우저의 쿠키에 Session ID를 저장한다.
3️⃣ 브라우저는 해당 사이트에 대한 모든 Request에 Session ID를 쿠키에 담아 전송해준다.
4️⃣ 서버는 클라이언트가 보낸 Session ID와 DB에서 관리하고 있는 Session ID와 비교하여 일치하면 인증을 수행한다.
2-2. 단점
- 서버에서 세션 저장소를 사용하므로 요청이 많아지면 서버에 부하가 심해짐
3. Token 인증
- 유저가 서버에 접속하면 서버에서 해당 유저에게 인증되었다는 의미로 '토큰'을 발급시켜준다.
3-1. Token의 인증방식
1️⃣ 유저가 아이디와 비밀번호로 로그인을 한다.
2️⃣ 서버 측에서 유저에게 유일한 토큰을 발급해준다.
3️⃣ 클라이언트는 서버에게 부여받은 토큰을 쿠키나 스토리지에 저장해두고, 서버에 요청할 때마다 해당 토큰을 HTTP 요청 헤더에 포함시켜 전달한다.
4️⃣ 서버는 전달받은 토큰을 검증하고 요청에 응답한다.
3-2. Token 방식의 단점
- 쿠키/세션과 달리 토큰 자체 데이터 길이가 길기 때문에, 인증 요청이 많아질수록 네트워크 부하가 심해질 가능성이 높다.
- 토큰을 탈취당하면 이에 대처하기 어렵다.
JWT은
인증에 필요한 정보들을 암호화시킨 객체이다.
세션과 다르게 서버는 Secret key로 토큰을 받아 복호화만 하면 되므로, 별도의 저장공간이 필요없게 된다.
이는 인증을 stateless하게 만들기 때문에 서버확장이 자유로워진다.
장점
- 사용자 인증에 필요한 모든 정보가 토큰 자체에 포함되기 때문에 (self-contained) 별도의 인증 저장소가 필요없음
- 쿠키를 전달하지 않아도 되기 때문에 쿠키를 사용함으로써 발생하는 취약점이 사라짐
- 트래픽에 대한 서버부담이 낮음
- REST 서비스로 제공 가능
단점
- Stateless: 토큰을 임의로 삭제하는 것이 불가능하기 때문에 토큰 만료시간이 필요하다.
Soogineer's Devlog