서버 클라이언트 인증 방식, Cookie/Session/Token

HTTP 통신은 stateless
-> 상태를 기억하기 위해 쿠키, 세션, 토큰을 사용

 

Cookie

• 서버가 사용자의 웹 브라우저에 전송하는 작은 데이터 조각으로, key=value 형식의 문자열 데이터 묶음
• 브라우저에 저장됨 (클라이언트가 조작할 수 있고, 
• 서버는 쿠키에 담긴 정보를 바탕으로 클라이언트 식별, 광고 추천 등
• 세션 관리, 개인화, 트래킹에 사용

Cookie 인증 방식

1. 브라우저(클라이언트)가 서버에 요청(접속)을 보냄
2. 서버는 클라이언트의 요청에 대한 응답을 작성할 때, 저장하고 싶은 정보를 응답 헤더의 Set-Cookie에 담음
3. 이후 클라이언트가 재요청 할 때마다 저장된 쿠키를 요청 헤더의 Cookie에 담아 요청을 보냄

Cookie 단점

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

 

Session

• 쿠키의 보안적 이슈 때문에, 세션은 클라이언트의 민감한 인증 정보를 브라우저가 아닌 서버 측에 저장하고 관리
• 세션을 사용하지 않고 쿠키만으로 데이터를 주고 받는 경우는, 클라이언트가 이미 모든 데이터를 알고 있는 것!
• Key(SESSION ID) 와 Value( 세션 생성 시간, 마지막 접근 시간, User가 저장한 속성 등을 Map 형태로 저장)

Session 인증 방식

1. 유저가 웹사이트에 로그인하면 세션이 서버 메모리(혹은 DB) 상에 저장됨
2. 서버에서 브라우저의 쿠키에 세션 ID 저장
3. 쿠키에 정보가 담겨있기 때문에 브라우저는 해당 사이트에 대한 모든 요청에 세션 ID를 쿠키에 담아 전송
4. 서버는 클라이언트가 보낸 세션 ID 와 서버 메모리로 관리하고 있는 세션 ID를 비교하여 인증을 수행

Session 장점

• 서버가 클라이언트의 웹 브라우저에 의존하지 않아도 됨
• 쿠키를 포함한 요청이 외부에 노출되어도 세션 ID 자체는 유의미한 개인 정보를 가지고 있지 않음
• 각 사용자마다 공유한 세션 ID가 발급되기 때문에, 요청이 들어올 때마다 회원 정보를 확인(로그인)할 필요가 없음

Session 단점

• 해커가 세션 ID를 중간에 탈취하여 클라이언트인 척 위장할 수 있음
• 서버에서 세션 저장소를 사용하므로 요청이 많아지면 서버에 부하가 발생할 수 있음

 

Token (JWT : JSON Web Token)

• 인증에 필요한 정보를 암호화 시킨 토큰
• 세션/쿠키와 유사하게 사용자는 Access Token(JWT 토큰)을 HTTP 헤더에 담아 서버로 보냄
• Header, Payload, Signature로 구성
  • Header : 암호화 방식(해시 알고리즘 종류), 타입 등
  • Payload : 서버에 보낼 데이터 (유저의 고유 ID값, 유효기간 등)
  • Signature : Header + Payload를 Base64 방식으로 인코딩 후 헤더에 명시한 해시함수를 적용하고, 비밀키로 서명하여 생성

Token 인증 방식

1. 클라이언트 요청 시, 서버는 검증 후 클라이언트 고유 ID 등의 정보를 Payload에 담음
2. 암호화할 비밀키를 이용해 Access Token(JWT)을 발급
3. 클라이언트는 전달받은 토큰을 저장해두고, 서버에 요청 시 토큰을 헤더(Authorization)에 포함시켜 함께 전달
4. 서버는 토큰의 Signature을 비밀키로 복호화하여 위변조 여부 및 유효 기간 등을 확인
5. 유효한 토큰인 경우 요청에 응답

Token 장점

• Header와 Payload를 가지고 Signature를 생성하므로 데이터 위변조를 막을 수 있음
• Signature는 토큰의 위변조 여부를 확인하는 데 사용됨 (서버 측에서 관리하는 비밀키가 유출되지 않는 이상 복호화 불가능)
• 인증 정보에 대한 별도의 저장소가 필요 없음 (별도의 I/O 작업이 필요 없음)
• JWT는 토큰에 대한 기본 정보와 전달할 정보 및 토큰이 검증됐음을 증명하는 서명 등 필요한 모든 정보를 자체적으로 지니고 있음
• 클라이언트의 인증 정보를 저장하는 세션과 다르게, 서버는 Stateless
• 우수한 확장성
• 토큰 기반으로 다른 로그인 시스템에 접근 및 권한 공유가 가능

Token 단점

• 쿠키, 세션과 다르게 JWT는 토큰의 길이가 길어, 인증 요청이 많을수록 네트워크 부하가 심해짐
• Payload 자체는 암호화되지 않기 때문에 유저의 중요한 정보(패스워드 등)는 담을 수 없음
• 토큰을 탈취당하면 대처하기 어려움 (한번 발급되면 유효기간 만료 시까지 사용 가능)
• 이미 발급된 JWT는 돌이킬 수 없음 (쿠키/세션 기반 인증은 서버 단에서 쉽게 삭제 가능하지만, 토큰은 안됨)

Refresh Token

• Access Token(JWT)의 문제점 = 토큰을 제 3자에게 탈취 당하는 경우 보안에 취약
  • 유효기간을 늘리면? 토큰을 탈취당했을 때 보안에 더 취약해짐
  • 유효기간을 줄이면? 자주 토큰을 발급받아야 하므로 불편함
• 긴 유효기간(보통 2주)을 가지면서, Access Token이 만료됐을 때 새로 발급해주는 열쇠
• Access Token의 유효기간을 짧게 만들고, 유효기간이 만료될 때마다 Refresh Token을 통해 새로운 Access Token을 만들어서 보안을 조금이라도 더 안전하게 한 것 !