JWT

📙 Cookie & Session

💡 Cookie

• 클라이언트가 웹 사이트에 접속할 때 사용하게 되는 기록 파일 (client의 browse에 저장)
• Key, Value 형식의 문자열 형태로 저장

💡 Session

• 민감한 정보를 노출했을 때의 단점을 막기위함
• 클라이언트의 인증 정보를 Cookie가 아닌 서버 측에 저장하고 관리
• session에 대한 정보를 서버 메모리에 저장하는 부담
• 매번 요청 시 세션 저장소를 조회해야 한다.
• scale out시 로드 밸런싱 등 우려

📙 Token을 활용한 인증

💡 Token

• 클라이언트가 서버에 접속하여 사용자 인증을 했을 때 ‘토큰’을 발급한다.
• 서버에 요청을 보낼 때 요청의 헤더에 토큰을 넣어서 보낸다.
• 클라이언트가 보낸 토큰이 서버에서 발급한 토큰과 같은지를 체크하여 인증 처리한다.
• 토큰은 앱과 서버가 통신 및 인증할 때 사용한다.

💡 서버(session)기반 vs Token 기반 인증

서버 기반	토큰 기반
서버에 사용자 인증 정보를 관리	클라이언트에 토큰 발급
클라이언트로부터 요청을 받으면 클라이언트의 상태를 계속 유지 (stateful)	로그인이 필요한 작업일 경우 헤더에 토큰을 삽입하여 보내고 인증(stateless)
클라이언트가 많아지면 성능 문제 발생

💡 Token 단점

• 토큰 자체의 데이터 길이가 길다
  → 인증 요청이 많아질수록 네트워크 부하가 심해질 수 있음
• Payload 자체는 암호화 되지 X
  → 중요 정보 저장 X
• 네트워크 전송 방식
  → 토큰 탈취 우려

📙 JWT

💡 JWT이란?

• 인증에 필요한 정보를 암호화시킨 JSON 토큰
• JSON 데이터를 Base64 URL-safe-Encode를 통해 인코딩하여 직렬화
• 토큰 내부에 위/변조 방지를 위한 개인키를 통한 전자서명 포함

💡 JWT 구성

• Header
  • JWT에서 사용할 토큰의 타입과 암호화 알고리즘 정보로 구성
  • key - value 형태로 구성
• Payload
  • 서버로 보낼 사용자 권한 정보와 데이터로 구성 (key - value 형태)
  • 토큰에 담을 클레임 정보 포함
    ✔️ Claim이란❓
    • payload에 담는 정보의 한 조각
    • key-value 형식으로 이루어진 한 쌍의 데이터
  • 토큰에는 여러 개의 claim을 넣을 수 있다.
  • payload에는 민감한 정보를 넣으면 안된다. (암호화 X)
• Signature
  • Secret Key(서버의 개인기)를 포함하여 암호화
  • 토큰의 유효성을 검증하기 위한 문자열로 구성

💡 Refresh Token

• AccessToken을 탈취 당했을 경우에 대한 최소한의 대비
• AccessToken의 유효기간을 짧게 설정하여 탈취 되어도 사용기간을 줄이는 효과
• RefreshToken을 통해 다시 AccessToken을 발급받아 사용한다.
• 인증 정보를 담고 있지 않고, AccessToken 재발급 용도로만 사용한다.

💡AccessToken & Refresh Token 사용한 Login Process

1. 클라이언트가 ID, PW로 서버에게 인증을 요청하고 서버는 이를 확인하여 AccessToken과 RefreshToken을 발급
2. 클라이언트는 이를 받아 RefreshToken을 저장하고 AccessToken을 가지고 서버에 자유롭게 요청
3. 요청을 하던 도중 AccessToken이 만료되어 더 이상 사용할 수 없다는 오류를 서버로부터 전달받음
4. 클라이언트는 본인이 사용한 AccessToken이 만료되었다는 사실을 인지하고 본인이 가지고 있던 RefreshToken을 서버로 전송하여 새로운 AccessToken의 발급을 요청
5. 서버는 RefreshToken을 받아 서버의 RefreshToken Storage에 해당 토큰이 있는지 확인하고, 있다면 AccessToken을 생성하여 전달