[Network]토큰(Token) 기반 인증

토큰(Token)

• 인증에 대한 정보를 사용자가 저장
• 등장 이유 :
  • 시스템의 규모가 커짐에 따라 서버(세션) 기반 인증 방식의 한계 드러남
  • 웹/앱 어플리케이션이 발달하면서 서버 확장하기 어려워짐
• 서버가 각각의 클라이언트를 구분하기 위해 발급하는 클라이언트의 정보를 담은 암호화 데이터
• 요즘에는 JWT(JSON Web Token) 주로 사용

 

서버(세션) 기반 인증 방식

• 서버 측에서 사용자의 정보를 기억해야 함
• 사용자들의 정보를 기억하기 위해서는 세션 유지해야 함
  • 메모리 or 디스크 or 데이터 베이스로 관리
• Stateful server : 클라이언트의 상태를 계속해서 유지하고 이 정보를 서비스에 이용하는 역할의 서버

 

🔴 단점

1. 세션(Session)
   • 대부분 메모리에 세션 저장하는데 로그인 중인 사용자가 늘어나는 경우에는 RAM 과부하
   • 데이터베이스에 저장하면 데이터베이스에 무리
2. 확장성(Extensibility)
   • 사용자가 늘어나면 여러 프로세스를 돌리거나 컴퓨터를 추가해야 함 (많은 트래픽 처리)
   • 세션 분산하는 시스템 설게해야 하지만 매우 복잡
3. CORS(Cross-Origin Resource Sharing)
   • 쿠키는 단일 도메인 및 서브 도메인에서만 작동
   • 쿠키를 여러 도메인에서 관리하는 것이 어려움

 

 

토큰 기반 인증 방식

• 인증받은 사용자들에게 토큰을 발급하고, 서버에 요청을 할 때 헤더에 토큰을 함께 보내도록 하여 유효성 검사 진행
• 사용자의 인증 정보를 서버나 세션에 유지하지 않음
• 라이언트 측에서 들어오는 요청만으로 작업을 처리
• 상태를 유지하지 않으므로 Stateless한 구조

 

🛠️ 동작 방식

1. 사용자 로그인
2. 서버 측에서 클라이언트의 정보 검증
3. 정보 정확하면 서버가 사용자에게 signed 토큰 발급
   • signed : 해당 토큰이 서버에서 정상적으로 발급된 토큰임을 증명
4. 클라이언트는 서버에게서 받은 토큰을 저장
5. 서버에 요청할 때마다 토큰을 함께 전달 (HTTP reuqest header에 토큰 포함)
6. 서버는 토큰 검증 후 요청 응답

 

🔵 장점

1. 무상태성(statless) & 확장성(Scalability)
   • 토큰은 클라이언트에 저장 ⇒ 서버는 stateless
   • 서버와 클라이언트의 연결고리가 없어서 확장하기 용이
2. 보안성
   • 쿠키를 전달하지 않기 때문에 쿠키 사용에 의한 보안 취약점 ❌
   • BUT 토큰 환경 취약점에 대비해야 함
3. 확장성(Extensibility)
   • Extensibility : 로그인 정보가 사용되는 분야의 확장
   • 토큰에 선택적인 권한만 부여하여 발급할 수 있음
4. 여러 플랫폼 및 도메인
   • CORS 해결
   • 어떤 디바이스, 어떤 도메인에서도 토큰의 유효성 검사를 진행한 후에 요청을 처리 가능

 

🔴 단점

1. 토큰의 길이가 길어서 인증 요청이 많을수록 네트워크 부하가 오기 쉬움
2. payload 자체는 암호화되지 않아 사용자의 중요한 정보 저장 ❌
3. 토큰 탈취당하면 대처하기 어려움

참고
https://mangkyu.tistory.com/55
https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-JWTjson-web-token-%EB%9E%80-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC#Token_%EC%9D%B8%EC%A6%9D