Please enable JavaScript.

Coggle requires JavaScript to display documents.

인증방식에 JWT를 사용한 이유 - Coggle Diagram

- - - - session : Stateful
      - JWT : Stateless
    - - session : server
      - JWT : Client
    - - session : 세션 공유를 위한 추가적인 기술 필요
      - JWT : 토큰만 검증하면 됨, 분산 환경에 유리
    - - session : 세션 ID 탈취 시 해당 세션으로 위장 가능성 존재
      - JWT : 토큰 자체는 암호화되지 않으므로 민감한 정보 포함 주의 필요
    - - session : 세션 아이디만 전달
      - JWT : 사용자 정보를 포함하므로 길이가 길어질 수 있음
    - - session : 주로 웹 브라우저 환경
      - JWT : 앱, 웹 다양한 환경에서 가능
  - - - 모바일 환경의 한계
        
        모바일 애플리케이션은 기본적으로 쿠키를 제공하지 않는 경우가 많음
      - 확장성 문제
        
        사용자가 많아질수록 서버는 더 많은 세션 정보를 저장하고 관리해야 하므로 서버에 부하가 가중됨
      - 서버 부하 증가
        
        여러 서버를 사용하는 분산 환경에서는 세션 정보를 모든 서버가 공유해야 하는 문제
        
        특정 서버에만 세션 정보가 저장되어 있다면, 로드 밸런서가 다른 서버로 요청을 보냈을 때 인증이 풀리는 현상이 발생
    - - 즉각적인 세션 제어 가능
        
        서버 측에서 사용자의 세션 정보를 직접 관리하므로, 특정 사용자를 강제로 로그아웃시키거나 세션을 즉시 무효화하는 것이 매우 간단
      - 상태 정보 저장의 용이성
        
        인증 상태 외에도 사용자의 활동 기록, 장바구니 내역 등 다양한 데이터를 세션에 저장하고 관리하기 편리
      - 구현의 단순성
        
        대부분의 웹 프레임워크가 세션 관리를 위한 기능을 기본적으로 내장하고 있어 개발자가 비교적 쉽게 구현하고 이해할 수 있습니다.
      - 보안
        
        사용자 정보와 같은 민감한 데이터를 클라이언트(브라우저)가 아닌 서버에 저장하므로 상대적으로 안전
- - - - 토큰의 타입(JWT)과 서명에 사용된 해싱 알고리즘(예: HMAC SHA256, RS256) 정보를 담고 있습니다.
        
        HMAC SHA256
        
        대칭키를 이용한 메세지 인증 방식
        
        비밀키와 메세지 결합 : 전송하고자 하는 원본 메시지와 사전에 공유된 비밀키를 결합
        
        HMAC 값은 원본 메시지와 함께 수신자에게 전송됩니다. 수신자는 동일한 비밀키를 사용하여 받은 메시지로 똑같은 과정을 거쳐 HMAC 값을 생성하고, 두 값을 비교하여 메시지의 위변조 여부와 송신자의 신원을 확인
        
        API 인증: 클라이언트와 서버 간의 요청이 변조되지 않았음을 확인하는 데 널리 사용
        
        데이터 무결성 보호: 전송 중 데이터가 변경되지 않았는지 검증하는 데 필수적
        
        웹훅(Webhook) 검증: 쇼피파이(Shopify)와 같은 여러 서비스에서 웹훅 요청의 진위 여부를 가리는 데 사용
        
        해시 함수 적용: 결합된 데이터를 SHA-256 해시 함수를 이용해 해시값을 생성
        
        인증 코드 생성: 생성된 해시값에 다시 비밀키를 결합하여 최종적으로 HMAC 값을 만들어냅니다.
        
        RS256
        
        비대칭키를 이용한 디지털 서명
        
        비대칭키 방식은 공개키와 개인키라는 한 쌍의 키를 사용하며, 개인키는 소유자만이 안전하게 보관하고 공개키는 외부에 공개할 수 있습니다.
        
        해싱: 먼저 전송할 메시지를 SHA-256 알고리즘으로 해싱
        
        개인키로 서명(암호화): 생성된 해시값을 개인키를 이용해 암호화하여 디지털 서명을 생성
        
        검증: 메시지를 수신한 측에서는 공개키를 사용하여 서명을 복호화
        
        무결성 확인: 복호화된 해시값과 수신한 메시지를 직접 해싱한 값을 비교하여 메시지의 무결성과 서명의 유효성을 검증
        
        xxxx.yyyy.zzzz 구조
        
        HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
    - - 토큰에 담을 정보, 즉 클레임(Claim)을 포함합니다. 클레임은 사용자의 ID, 이름, 만료 시간 등과 같은 정보를 의미하며, name/value 쌍으로 이루어집니다. 페이로드는 Base64로 인코딩될 뿐 암호화되지 않으므로, 민감한 개인 정보는 담지 않도록 주의해야 합니다.
    - - 헤더의 인코딩 값과 페이로드의 인코딩 값을 합친 후, 서버가 가진 비밀 키(Secret Key)로 해싱하여 생성합니다. 이 서명은 토큰의 위변조 여부를 확인하는 데 사용됩니다.
  - - - API 요청 시 JWT 포함
        
        서버의 JWT 검증
        
        서버는 클라이언트로부터 받은 JWT의 서명을 비밀 키를 사용하여 검증합니다. 서명이 유효하면 토큰이 위변조되지 않았음을 신뢰하고, 페이로드에 담긴 사용자 정보를 기반으로 요청을 처리
        
        클라이언트는 발급받은 JWT를 저장해두었다가, 서버에 API를 요청할 때마다 요청 헤더(Authorization Header)에 JWT를 담아 보냅니다.
        
        Authorization: Bearer <accessToken>
      - 서버는 사용자 인증에 성공하면, 헤더, 페이로드, 서명을 조합하여 JWT를 생성합니다. 생성된 JWT는 클라이언트에게 전달
        
        accessToken: 유저 정보 포함, 유효기간 짧음 (ex. 15분~1시간)
        
        refreshToken: 재발급용, 보안 고려해 httpOnly 쿠키 등에 저장
    - - 유효한 사용자인지 판단
- - - - 토큰 자체에 필요한 모든 정보를 담고 있어, 별도의 인증 정보 조회가 필요 없습니다.
    - - 웹, 모바일 등 다양한 플랫폼과 프로그래밍 언어에서 지원
  - - - 세션 ID에 비해 토큰의 길이가 길어, 요청이 많아질수록 네트워크 부하가 증가할 수 있습니다.
    - - 페이로드는 암호화되지 않으므로 민감한 정보를 담을 수 없습니다.
    - - 토큰이 탈취되면 유효기간이 만료될 때까지 악의적인 사용이 가능
      - 대응법
        
        Access Token
        
        실제 API 요청에 사용되는 토큰으로, 비교적 짧은 유효기간을 가집니다.
        
        Refresh Token
        
        Access Token이 만료되었을 때 새로운 Access Token을 발급받기 위해 사용되는 토큰으로, Access Token보다 긴 유효기간을 가집니다.
        
        Refresh가 탈취 당했을 때
        
        Refresh Token 회전 (Rotation)
        
        Refresh Token을 사용하여 새로운 Access Token을 발급받을 때마다 기존의 Refresh Token을 무효화하고 새로운 Refresh Token을 발급하는 방식입니다. 이를 통해 탈취된 Refresh Token이 재사용되는 것을 방지할 수 있습니다.
        
        탈취 탐지 메커니즘
        
        만약 서버가 이미 만료된 Refresh Token을 사용한 요청을 감지하면, 해당 Refresh Token이 탈취되었을 가능성이 높다고 판단하고 관련된 모든 Refresh Token을 무효화하는 조치를 취할 수 있습니다.
        
        짧은 Refresh Token 유효기간
        
        Refresh Token의 유효기간을 적절하게 설정하여 탈취 시 피해를 최소화
        
        Secure, HttpOnly 쿠키 사용
        
        Refresh Token을 클라이언트의 자바스크립트에서 접근할 수 없도록 HttpOnly 속성을 설정하고, HTTPS를 통해서만 전송되도록 Secure 속성을 설정한 쿠키에 저장하여 XSS(Cross-Site Scripting) 공격으로부터 보호합니다.
    - - 한 번 발급된 JWT는 정보를 변경하거나 폐기하기 어렵습니다.
- - - - 서버가 사용자 인증 상태를 기억하지 않아도 되는 구조
        
        Statelee(무상태)인증 구조
        
        서버의 부하가 줄고 수평적 확장이 매우 용이