241228 TIL Token Auth with JWT

1. Token Auth with JWT

JSON Web Token (JWT)

JWT 간단 개요

• Token: 랜덤하게 생긴 문자열
• 일정한 규칙을 가지고 있고 간단한 서명을 더한 문자열로 토큰 자체에 유저에 대한 간단한 정보가 들어있는 형태
• JWT 방식으로 Auth를 처리하면 Session DB나 인증을 위한 여러가지 로직 처리가 필요 없음

JWT 처리 방식

1. 클라이언트가 ID/PW를 서버로 전송
2. 서버에서 ID/PW를 검증하고 유효하다면 일정한 형식으로 서명 처리된 Token을 응답
3. 이후 클라이언트는 모든 요청 헤더에 토큰을 담아 서버로 요청을 전송
4. 서버는 해당 토큰의 유효성을 검증하고 유저의 신원과 권한을 확인 후 요청을 처리

세션과의 차이

• 세션 데이터베이스가 존재하지 않으며 데이터베이스가 필요 없음
• 토큰 자체가 하나의 인증 데이터
• 서버는 토큰이 유효한지만 검증하여 처리

장점과 단점

• 장점
  - 서버에서 관리하는 데이터가 없으므로 복잡한 처리 로직이 필요 없음
  - 세션이나 DB 없이 유저를 인증하는 것이 가능
• 단점
  - 일방적으로 로그인을 무효화하는 등의 처리가 불가능(세션 테이블 X)
  - Token 자체가 데이터를 담고있는 정보이므로 탈취당할 시 보안이 취약

JWT의 구조

• .을 기준으로 HEADER.PAYLOAD.VERIFY SIGNATURE 세 부분으로 구성

• HEADER
  - 토큰의 타입(jwt) 또는 서명 부분의 생성에 어떤 알고리즘(alg)이 사용되었는지 등을 저장

• PAYLOAD
  - 토근 발급자, 토큰 대상자, 토큰 만료시간, 활성날짜, 발급시간 등등 여러 데이터가 담겨있는 부분
  - 이곳에 서비스가 유저 정보를 담아서 인증
  - 누구나 풀어볼 수 있기 때문에 민감한 정보를 담지않고 최소의 정보만 저장
  - 각각의 데이터는 Claim이라고도 하며 Key-Value 형태로 구성됨

• SIGNATURE
  - HEADER + PAYLOAD + 서버의 비밀키 값을 HEADER에 명시된 암호 알고리즘 방식으로 생성한 값
  - PAYLOAD의 글자 하나만 달라져도 SIGNATURE는 완전히 다른 문자열로 변환되어 서버의 비밀키 값을 모른다면 유효한 서명값을 만들어내는 것이 불가능
  - 서버는 토큰을 받으면 HEADER + PAYLOAD + 비밀키로 생성한 서명값이 토큰의 서명값과 일치하는지를 확인하는 과정을 거쳐서 유효성 여부를 확인
  - 서명의 유효여부 + 유효기간 내의 토큰인지 확인하여 Auth 과정을 처리

Access Token과 Refresh Token

• Access Token
  - 요청할 때 인증을 위해 헤더에 포함해야하는 토큰
  - 매 요청시 보내는 토큰이므로 보안이 취약
  - 만료 기한을 짧게 잡아 만약 탈취 당해도 짧은 시간안에 유효하지 않은 토큰 형태가 되도록 함

• Refresh Token
  - Access Token이 만료되었을때 새로 Access Token을 발급받기 위한 Token
  - Access Token 보다 긴 유효 기간을 가짐
  - 주로 사용자의 기기에 저장해두고 사용되며 만약 Refresh Token까지 만료되었다면 다시 인증(로그인) 과정이 필요
  - Refresh Token의 탈취를 보완하기 위해 DB 리소스를 사용하는 다양한 방식도 존재(BlackList 등)