• 티스토리 홈
  • 프로필사진
    유니얼
  • 방명록
  • 공지사항
  • 태그
  • 블로그 관리
  • 글 작성
유니얼
  • 프로필사진
    유니얼
    • 분류 전체보기 (295)
      • Unity (17)
        • 게임 개발 (5)
      • Unreal (24)
        • 게임 개발 (20)
      • DirectX (36)
      • 코딩테스트 (91)
        • 프로그래머스 (25)
        • 백준 (66)
      • Google Workspace (1)
      • Programing (102)
        • C# (68)
        • C++ (24)
        • JavaScript (10)
      • 게임 서버 프로그래밍 (17)
      • Web (6)
        • 슈퍼코딩 (6)
  • 방문자 수
    • 전체:
    • 오늘:
    • 어제:
  • 최근 댓글
    등록된 댓글이 없습니다.
  • 최근 공지
    등록된 공지가 없습니다.
# Home
# 공지사항
#
# 태그
# 검색결과
# 방명록
  • (2024.12.09(월요일)) 슈퍼코딩 (신입연수원) 3주차 Day 2 후기
    2024년 12월 10일
    • 유니얼
    • 작성자
    • 2024.12.10.:06
    728x90

    JWT와 Session 인증 방식 비교 정리

    1, JWT란?

    JWT는 JSON Web Token의 약자로 JSON 형식으로 정보를 저장하고, 서명(Signature)을 통해 무결성을 보장하느 토큰 기반 인증 방식입니다. 주로 헤더(Header), 페이로드(Payload), 서명(Signature)으로 구성됩니다.

    2. JWT을 활용한 사용자 인증

    1, 로그인 요청:

    - 사용자가 ID/PW를 통해 로그인 요청을 보냄

    - 서버는 사용자 정보를 검증한 후 JWT를 생성하여 클라이언트에 전달

    2, JWT 전달:

    - 클라이언트는 JWT를 저장(로컬스토리지, 쿠키 등)하고, 이후 요청 시 HTTP 헤더( Authorization: Bearer <JWT> )에 포함하여 전송

    3, 서버 검증:

    - 서버는 클라이언트가 보낸 JWT의 서명을 검증,

    - 서명이 유효하면 PayLoad의 사용자 정보를 추출하여 요청 처리

    4, 토큰 만료:

    - JWT는 자체적으로 만료 시간을 포함하므로, 만료된 경우 클라이언트는 Refresh Token을 사용하여 새 JWT를 요청

    3, Refresh Token을 활용한 사용자 인증 과정

    1, 로그인 및 초기 인증:

    - 사용자가 ID/PW를 통해 로그인 요청을 보냄

    - 서버는 사용자 정보를 검증하고, Access Token과 Refresh Token을 둘 다 발급합니다.

         - Access Token: 짧은 만료 시간(15~60분)

         - Refresh Token: 긴 만료 시간(7일~30분)

    - Access Token을 발급받는 클라이언트는 Access Token을 메모리나 로컬 스토리지에 저장하여 API 요청시 사용합니다. Refresh Token은 사용자 ID와 함께 서버 DB에 저장합니다.

    2, Access Token 재발급 엔드포인트 설계:

    - 클라이언트가 Access Token이 만료되었음을 감지하면, 새로운 Access Token을 발급 받을 수 잇는 토큰 갱신 API로 요청을 보냄.

    3, Refresh Token 검증:

    - Access Token 재발급 요청 시, 전달된 Refresh Token의 유효성을 검증합니다.

    - 데이터베이스에서 Refresh Token을 조회하고, 만료 여부를 확인, 유효한 경우에만 Access Token을 재발급하고, 유효하지 않는 경우에는 로그아웃 처리를 합니다.

    4, 로그아웃 로직:

    - 사용자가 로그아웃 시 Refresh Token도 폐기

    - 데이터베이스에서 Refresh Token 삭제 또는 만료 처리.

    4, Session을 통한 관리

    작동 방식:

    • 사용자가 로그인하면 서버는 세션 ID를 생성하고, 이를 클라이언트에게 쿠키로 전달.
    • 서버는 생성된 세션 ID를 데이터베이스나 메모리에 저장하고, 세션 ID와 사용자 인증 정보를 연결.
    • 이후 클라이언트가 요청을 보낼 때, 브라우저는 자동으로 쿠키에 포함된 세션 ID를 전송.
    • 서버는 세션 ID를 기반으로 사용자의 인증 상태를 확인하고 요청을 처리.

    특징:

    • 서버가 상태를 관리하여 인증 상태를 유지함.
    • 실시간 연결 기반 애플리케이션(예: 소켓 기반 게임)과 잘 맞음.
    • 즉각적인 로그아웃 처리 가능: 사용자가 로그아웃하면 서버에서 세션을 삭제하여 모든 인증 상태가 즉시 무효화됨.

    단점:

    • 서버가 상태 정보를 관리해야 하므로, 확장성에 제약이 있음.
    • 다중 서버 환경에서는 세션 동기화를 위해 Redis 같은 외부 캐시 시스템 필요.
    • 클라이언트와의 연결이 끊어진 상태(비연결형)에서는 세션 관리가 비효율적.

    5. 차이점 (JWT vs Session)

    특징 JWT (토큰 기반 인증) Session (세션 기반 인증)
    저장 위치 클라이언트(로컬스토리지, 메모리 등) 서버(메모리, Redis 등)
    상태 관리 무상태(Stateless) 상태 유지(Stateful)
    확장성 서버 부담 적음, 확장성 높음 다중 서버 환경에서 세션 동기화 필요
    보안 클라이언트 저장 시 탈취 위험 서버가 상태를 관리하므로 상대적으로 안전
    로그아웃 처리 클라이언트에서 토큰 삭제 필요 서버에서 세션 삭제로 즉시 로그아웃 처리 가능
    적용 사례 RESTful API, 모바일 앱 실시간 연결 게임, 서버 중심 애플리케이

    6. 일일 보고 양식

    부족한 점: JWT 기반 인증과 Session 기반 인증의 보안 및 확장성 고려 사항에 대한 실무적 이해 부족.

    스스로 시도해본 것들: JWT와 Session의 인증 방식 및 차이점을 중심으로 설계 방법 조사.

    알게된 점:

    - JWT는 서버가 무상태로 동작해 확장성이 뛰어나며, 클라이언트 중심의 인증 방식에 적합하다.

    - Session 기반 인증은 서버가 상태를 관리하여 보안성이 높지만, 확장성을 위해 세션 동기화가 필요하다.

    회고:

    - 프로젝트를 통해 데이터베이스 설계와 RESTful API 개발의 실무 감각을 익혔으며, 이를 바탕으로 보안 강화 방안을 학습해야 함을 깨달음.

    - 특히, JWT와 Session의 차이를 명확히 이해했으며, 상황에 따라 인증 방식을 적절히 선택하는 중요성을 인식함.

    반응형
    다음글
    다음 글이 없습니다.
    이전글
    이전 글이 없습니다.
    댓글
조회된 결과가 없습니다.
스킨 업데이트 안내
현재 이용하고 계신 스킨의 버전보다 더 높은 최신 버전이 감지 되었습니다. 최신버전 스킨 파일을 다운로드 받을 수 있는 페이지로 이동하시겠습니까?
("아니오" 를 선택할 시 30일 동안 최신 버전이 감지되어도 모달 창이 표시되지 않습니다.)
목차
표시할 목차가 없습니다.
    • 안녕하세요
    • 감사해요
    • 잘있어요

    티스토리툴바