Please enable JavaScript.

Coggle requires JavaScript to display documents.

JWT를 적용한 인증 방식 - Coggle Diagram

- - - - Signature: 토큰을 인코딩하거나 위변조 방지를 위한 유효성 검증을 할 때 사용하는 고유한 암호화 코드.
        payload가 수정되더라도 signature에는 수정되기 전의 payload 내용이 이미 암호화 상태로 저장되어 있기 때문에, payload가 조작되었는지 검증할 수 있다. 이로 인해 토큰의 조작 여부를 검증하고, 조작된 토큰의 악용을 막을 수 있다.
        
        서명 생성 방법
        
        헤더와 페이로드의 값을 각각 Base64Url로 인코딩
        
        ⇒ 인코딩한 값을 비밀키(또는 공개키/개인키)를 이용해 헤더에서 정의한 알고리즘으로 해싱
        
        ⇒ 해싱된 값을 다시 Base64Url로 인코딩하여 생성
        
        대칭키(Symmetric Key)
        
        서명 생성/검증 시 같은 키 사용 ⇒ 속도 빠름
        
        대표적 알고리즘: HMAC 서명 알고리즘
        
        SHA256을 적용해 해싱 후 secret key로 HMAC 서명 생성
        
        secret key를 알고 있는 서버만 서명 유효성 검증 가능
        
        비대칭키(Asymmetric Key)
        
        서명 생성/검증 시 다른 키 사용 ⇒ 안전성 높음
        
        대표적 알고리즘: RSA 알고리즘
        
        마찬가지로, SHA256을 적용해 해싱 후 private key로 RSA 서명 생성
        
        public key(공개키)는 공개적으로 제공되며, 어떠한 서버든 이 public key를 이용해 서명 검증 가능
      - Payload: 토큰에 담아 보내고자 하는 데이터.클레임(claim)이라 불리는 사용자 식별 및 권한 정보, 유효기간 등의 값을 담고 있다. 노출과 수정이 가능한 지점이므로, 인증이 필요한 최소한의 정보만을 담아야 한다.
        
        포함 가능 정보: 권한 범위 / 토큰 발급일 / 토큰 만료일자 등
        
        포함 금지 정보: 비밀번호
        
        비공개 클레임(Private Claims)
        서버와 클라이언트 사이에 임의로 지정한 정보를 저장하는 사용자 정의 클레임
        
        등록된 클레임(Registered Claims)
        토큰의 정보를 표현하기 위해 이미 정의된 종류의 데이터들로, 모두 사용할 것이 권장되지만 선택적 작성 또한 가능하다.
        
        iss: 토큰 발급자(issuer)
        
        sub: 토큰 제목(subject)
        
        aud: 토큰 대상자(audience)
        
        exp: 토큰 만료 일자(expiration) - NumericDate 형식(ex. 1480849147370)
        
        nbf: 토큰 활성 날짜(not before) - 이 날짜 이전에는 활성화 X
        
        iat: 토큰 발급 시간(issued at) - 토큰 발급 이후의 시간을 알 수 있음
        
        jti: JWT 토큰 식별자(JWT ID) - 중복 방지를 위해 사용. 일회용 토큰(Access Token) 등에 사용
        
        공개 클레임(Public Claims)
        공개용 정보를 위해 사용하는 사용자 정의 클레임. 충돌 방지를 위해 IANA 등록 또는 URL 포맷을 이용한다.
        ex) { “http://loaclhost:8080 : true }
      - Header: 토큰의 종류와 Signature 생성을 위해 사용된 알고리즘 명시
        
        typ: 토큰 타입 (예: JWT)
        
        alg: 해싱 알고리즘 (예: HS256(SHA256), RS256 등)
    - - JSON 객체를 이용해 사용자의 정보 및 권한을 저장하는 클레임 기반의 웹 토큰.
        필요한 정보를 자체적으로 지니는 Self-contained 방식으로 안전한 정보 전달이 가능하다.
        
        특성
        
        JWT의 목적은 서명(인증), 즉, 정보 보호나 정보 전달이 아닌 위조 방지
        
        Self-contained
        
        Stateless
        
        URL-safe Base64 인코딩
        
        일반적인 Base64 Encode에서 URL에서도 오류 없이 사용하도록 '+', '/'를 각각 '-', '_'로 표현
        
        read-only: 클라이언트에서 유저들의 정보를 저장하게 되어 발생할 수 있는 정보의 수정/삭제를 막기 위해, JWT는 read-only 방법을 채택하여 데이터의 수정이 필요할 경우 반드시 서버를 통하도록 함
        
        일반 토큰: 검증에 필요한 정보들을 서버에 저장하므로 DB 접근이 필수
        
        클레임 토큰: 사용자 인증에 필요한 모든 정보를 토큰 자체에 담고 있어 별도의 저장소가 필요하지 않으며, 분산 마이크로 서비스 환경에서 중앙 집중식 인증 서버와 DB에 의존하지 않는 쉬운 인증을 제공해, 일반 토큰 기반 인증에 비해 편리
      - 탄생 배경
        
        세션 인증 단점 보완: RESTful 아키텍처의 확산으로 서버의 상태를 저장하지 않는(stateless) 설계가 중요해지면서, 서버 측 세션 저장소의 의존도를 줄이고 클라이언트가 인증 정보를 직접 저장하는 방식이 주목받게 됨
        
        분산 시스템/마이크로서비스 환경: 서로 다른 도메인 및 서버 간에 중앙 집중 없는 인증 정보 공유 필요성 증가
        
        모바일/SPA 증가: 쿠키 기반의 세션만으로는 CORS, CSRF 등의 보안 및 운영 이슈가 복잡해짐
    - - 로그인 요청
        사용자의 자격 증명 정보(ID/PW)를 서버로 전송
        
        인증 및 토큰 발급
        서버는 인증 후 사용자 정보(클레임)을 담은 JWT 발급
        
        클라이언트 저장
        클라이언트는 JWT를 Local Storage, Session Storage 또는 HTTP-only Cookie에 저장
        
        인증 요청
        이후 요청 시 HTTP Header 또는 Cookie에 JWT 포함
        HTTP Header: {Authorization: Bearer <JWT>}
        
        서버 검증
        
        서명(Signature) 검증: 토큰 위변조 여부 확인
        
        만료 시간(exp) 검증: 토큰의 유효 기간을 확인
        
        클레임 검증: 필요에 따라 사용자 권한(roles, scopes 등)을 확인
        
        자원 접근 허용
        검증이 완료되면 요청된 API/리소스 접근 허용
        
        1 more item...
    - - 장점
        
        데이터 위변조 방지
        Header와 Payload를 이용해 Signature를 생성하므로 데이터의 위변조를 방지할 수 있음
        
        Self-contained
        토큰에 필요한 기본 정보, 전달할 정보, 토큰이 검증되었음을 증명하는 서명 등 필요한 모든 정보를 자체적으로 지니고 있어, 리소스 서버에서 추가적인 요청 없이 자체적으로 토큰을 검증할 수 있음
        
        Stateless 아키텍처
        클라이언트 인증 정보를 저장하는 세션(stateful)과는 다르게, 서버는 상태를 저장하지 않음.
        따라서, 별도의 세션 저장소나 서버 간의 세션 공유가 필요 없음.
        이로 인해 서버의 수평 확장과 로드밸런싱이 간편해짐.
        
        마이크로 서비스 친화적
        분산 환경에서 중앙 관리 없이 인증 정보 공유가 가능해, 토큰 기반으로 서비스 간 로그인 및 권한 공유(SSO)가 용이
      - 취약점
        
        Payload 노출
        JWT Payload는 암호화 되지 않고 단순 Base64로 인코딩 되기 때문에,
        토큰이 탈취될 경우 간단한 디코딩만으로도 내부 정보를 열람할 수 있는 위험이 있음
        
        토큰 탈취 위험
        XSS 공격이나 네트워크 도청 등으로 토큰 탈취될 수 있으며,
        토큰 자체에 사용자 정보가 포함되어 있어 탈취 시 민감 정보가 그대로 노출될 수 있음
        
        네트워크 부하
        토큰 내에 여러 클레임을 포함하기 때문에, 정보가 많아질수록 토큰의 길이가 늘어나 네트워크 전송 시 오버헤드가 발생할 수 있음
        
        무효화 어려움
        JWT는 서버에서 상태를 저장하지 않기 때문에, 한 번 발급된 토큰을 중간에 강제로 만료시키는 것이 불가능. 따라서, 탈취된 토큰은 만료 시간까지 악용될 우려가 있으며, 이를 보완하기 위해 OAuth 2.0 흐름에서는 리프레시 토큰과 함께 사용됨.
  - - - 장점
        
        서버 통제력 강화: 토큰과 달리 서버가 세션을 직접 관리해, 언제든 강제 만료 등 제어 가능
        
        세션 무효화 용이: 사용자 로그아웃, 권한 변경, 해킹 의심 시 즉각적 세션 만료 가능
        
        Payload 노출 없음: 인증 정보가 클라이언트에 저장되지 않으므로, 탈취 시에도 직접적인 정보 노출이 없음
        
        단점
        
        상태 저장 필요: 서버가 사용자 상태(state)를 저장하므로, 확장성과 분산 시스템 설계에 제약이 있음
        
        세션 공유 어려움: 서버 간 세션을 공유하려면 별도의 세션 저장소(예:Redis)가 필요
        
        로드밸런싱 제약: Sticky session이 필요하거나, 상태 동기화를 위한 복잡도 증가
        
        CSRF 공격에 취약: 기본적으로 쿠키를 사용하는 구조이므로 CSRF 대응 필요
      - 인증 과정
        
        로그인 요청
        사용자의 ID/PW 등 자격증명을 서버로 전송
        
        인증 및 세션 생성
        서버가 자격 증명을 검증하고, 고유한 세션 ID를 생성하여 서버 측 저장소에 사용자 정보 매핑
        
        쿠키 전송
        생성된 세션 ID를 Set-Cookie 헤더를 통해 클라이언트에 전달
        
        인증 유지
        이후 요청 시 클라이언트는 해당 세션 ID가 담긴 쿠키를 자동으로 전송
        
        서버 검증
        서버는 쿠키에 담긴 세션 ID를 기준으로 세션 저장소에서 사용자 정보를 조회하고 요청을 처리
        
        1 more item...