[네트워크] 토큰 기반 인증(+JWT), 서버(세션)기반 인증

토큰(Token) 기반 인증

• 클라이언트가 서버에 접속 시 서버에서 해당 클라이언트에게 인증의 의미로 '토큰'을 부여 -> 인증(Authentication)
• 클라이언트는 또 다시 서버에 요청을 보낼 때 발급받은 토큰을 요청 헤더에 심어 전송
• 서버는 헤더 내 토큰을 열어 자신이 제공한 토큰이 맞는지 확인하여 인증 과정 처리 -> 인가(Authorization)

💡용어 정리
- 인증(Authentication): 자신이 누구인지 증명하고 검증하는 과정 (로그인)
- 인가(Authorization): 인증 작업 이후에 인증된 사용자에 대한 자원 접근 확인 및 허가 절차 (권한 확인)

• 장점
  • 토큰 정보를 클라이언트 측에서 저장하기 때문에 stateless(무상태)하며, 서버 확장에 용이 (서버 부담 X)
  • 토큰은 한 번 발급되면 유효기간이 만료될 때까지 계속 사용 가능
  • 토큰에는 기본 정보, 전달할 정보, 토큰이 검증되었다는 서명 등 필요한 모든 정보를 자체적으로 지니고 있음
  • header와 payload를 가지고 signature을 생성하므로 데이터 위변조 방지
• 단점
  • 쿠키/세션과 다르게 토큰 자체의 데이터 길이가 길어, 인증 요청이 많아질수록 네트워크 부하 발생
  • Payload 자체는 암호화되지 않기 때문에 유저의 중요한 정보는 담을 수 있음
  • 토큰을 탈취 당할 경우 대처가 어려움

 

토큰 인증 과정

1. 사용자가 아이디와 비밀번호로 로그인
2. 서버는 클라이언트(사용자)에게 토큰을 발급
3. 클라이언트는 서버 측에서 전달받은 토큰을 쿠키나 스토리지에 저장
4. 서버에 요청 시마다 해당 토큰을 HTTP 요청 헤더에 포함시켜 전달
5. 서버는 전달받은 토큰을 검증하고, 요청에 응답

 

JWT (JSON Web Token)

• 인증에 필요한 정보들을 암호화시킨 JSON 토큰을 의미
• JWT 토큰은 점(.)으로 구분된 Header, Payload, Signature로 구성
  1. Header(헤더): 보통 토큰의 타입이나 서명 생성에 어떤 알고리즘이 사용되었는지 저장
  2. Payload(내용):  사용자 권한 정보와 실제로 사용될 정보(JWT를 통해 알 수 있는 데이터)를 저장
  3. Signature(서명): 'Header+Payload'와 서버가 가지고 있는 유일한 Key값을 헤더에서 정의한 알고리즘으로 암호화한 값 (비대칭 암호화) -> Authorization(인가) 작업으로 토큰의 유효성 검증 시 사용

 

 

서버(세션) 기반 인증

• 클라이언트가 서버에 접속 시 서버는 클라이언트(사용자)의 정보를 서버의 세션 저장소에 저장 후 세션ID 발급 -> 인증(Authentication)
• 클라이언트는 또 다시 서버에 요청을 보낼 때 발급받은 세션ID을 요청 헤더와 함께 전송
• 서버는 헤더 내 세션ID를 통해 세션 저장소에 접근한 후 세션ID에 해당하는 세션 정보가 존재하는지 확인하여 인증 과정 처리 -> 인가(Authorization)

 

• 장점
  • 모든 인증 정보를 서버에서 관리하기 때문에 보안성이 높음 
• 단점
  • 서버 측 (세션 저장소)에서 정보가 저장되므로 요청이 많아지면 서버 부하가 심해짐
  • 공격자가 세션ID를 탈취하여 정상 클라이언트인 척 위장 가능 
  • 서버 확장 시 세션 분산 작업이 어려움

 

※ 쿠기와 세션에 대한 내용은 아래 포스팅 참고바랍니다.
https://zu-techlog.tistory.com/67

[네트워크] 쿠키(Cookie)와 세션(Session) 특징, 차이