[FE] 인증/인가에서 세션 방식과 JWT 방식의 차이점

🗣️ 인증/인가의 관점에서 세션 방식과 JWT 방식의 차이점을 자세히 설명해주세요. 각 방식의 장단점과 실제 프로젝트 활용 경험이 있다면 공유해주세요.

• 의도: 인증/인가에서 세션 및 JWT에 대해 이해하고 있는지 확인하는 질문

• 팁: 세션 스토리지와 헷갈리지 말자.

• 나의 답안

  세션 방식과 JWT 방식은 모두 인증/인가를 처리하는 데 사용되는 기술입니다. 하지만 이 두 기술에는 차이점이 있습니다.

  세션 방식은 사용자가 웹 애플리케이션에 로그인하면, 서버는 사용자의 신원을 확인하고 인증을 수행합니다. 인증이 성공하면 서버는 세션을 생성합니다.
  서버는 고유한 세션 ID를 생성하고, 이를 클라이언트(사용자의 웹 브라우저)에 쿠키로 저장합니다.
  클라이언트가 서버에 요청을 보낼 때마다, 서버는 세션 ID를 확인하여 해당 세션이 유효한지 검사합니다.
  사용자가 로그아웃하면, 서버는 세션을 종료하고 클라이언트 측 쿠키에서 세션 ID를 삭제합니다.
  세션 기반 인증/인가 방식은 공격자가 세션 ID를 탈취하여 사용자의 세션을 도용하는 세션 하이재킹의 위험이 있고, 서버가 세션 데이터를 저장하고 관리하기 때문에, 서버의 메모리나 저장 공간을 소모할 수 있습니다.

  JWT는 JSON Web Token의 약자로, 토큰 기반 인증 시스템입니다.
  사용자가 로그인하면, 서버는 사용자의 신원을 확인한 후, JWT를 생성합니다.
  JWT에는 사용자의 ID, 권한 정보, 만료 시간 등 중요한 정보가 포함됩니다.
  클라이언트 측에서는 받은 JWT를 로컬 스토리지나 세션 스토리지에 저장합니다. 클라이언트는 이후 요청 시마다 이 토큰을 포함하여 서버에 보냅니다.
  클라이언트가 보호된 리소스에 접근하려고 할 때, 요청 헤더에 JWT를 포함하여 서버에 보냅니다.
  서버는 받은 JWT의 서명을 검증하여 토큰의 무결성을 확인합니다.
  서버는 JWT의 페이로드에 포함된 권한 정보를 확인하여 사용자가 요청한 리소스나 작업을 수행할 권한이 있는지 결정합니다.
  JWT는 만료 시간 정보를 포함하므로, 일정 시간이 지나면 만료됩니다.
  JWT 기반 인증/인가 방식은 모든 필요한 정보가 JWT에 포함되어 있어 사용자 세션 상태를 유지할 필요가 없으므로 무상태 인증을 지원합니다.
  또한 서버 간 세션 공유가 필요 없으므로 확장에 용이합니다.

  저는 팀 프로젝트를 진행했을 때 supabase를 사용하여 인증/인가를 구현한 경험이 있습니다.
  supabase는 인증 및 인가를 구현할 때 JWT 방식을 사용하기 때문에, 사용자가 로그인하면 supabase는 사용자를 인증하고 JWT 토큰을 생성하여 반환합니다.
  supabase는 기본적으로 access token과 refresh token을 제공합니다.
  access token은 짧은 유효기간을 가지며 주로 API 요청에 사용되고, refresh token은 만료된 access token을 갱신하는 데 사용됩니다.
  이러한 방식은 보안성을 높이는 데 유용합니다.
  supabase를 활용하면 JWT 기반 인증 시스템을 비교적 간단하게 구축할 수 있어, 프론트엔드 프로젝트 시 백엔드 구현이 편리합니다.

• 제공된 답안 (모범 답안)

  세션 방식과 JWT 방식 모두 인증/인가를 처리하는 데에 사용되는 대표적인 기술입니다만 때와 장소에 따라 장단점과 차이점이 있습니다.

  우선 세션 방식에 대해 말씀드리겠습니다.
  세션 방식은 유저가 로그인하면 서버는 이 유저 정보를 세션에 저장하고, 발급된 세션 ID를 쿠키를 통해 클라이언트 브라우저에 전달합니다.
  이후 유저 인증이 필요할 때마다 클라이언트에서는 쿠키에 담긴 세션 ID를 통해 전송하고, 서버는 이 세션 ID를 받아 유저가 누구인지 확인해 인증을 허가합니다.

  다음으로 JWT는 JSON Web Token의 약자로, 유저가 로그인하면 서버는 유저 데이터, 만료 기간 등을 포함하는 토큰을 생성해 클라이언트에 전달합니다.
  이때 토큰에는 민감한 정보를 포함해서는 안 됩니다.
  클라이언트는 받아온 토큰을 로컬 스토리지나 쿠키에 저장하고, 유저 인증이 필요한 요청에 해당 토큰을 포함하여 서버로 전송합니다.
  서버는 받아온 토큰을 검증하고, 만료되지 않은 토큰이라면 인증을 진행합니다.

  여기서 큰 차이점은 서버 부하를 예시로 들 수 있습니다.
  세션의 경우에는 서버에서 세션 정보를 저장하고 있기 때문에 서버 부하가 증가할 수 있는 단점이 있습니다.
  그에 비해 JWT는 무상태이기 때문에 서버에 유저 세션 정보를 저장하지 않아 부하가 적습니다.
  다만 JWT는 토큰의 서명 키가 노출되지 않게 관리해야 한다는 특징을 가지고 있습니다.

  저는 이전에 했던 프로젝트에서 이러한 회원가입 및 로그인을 구현한 일이 있었습니다.
  그때 JWT를 이용했었고, 역할 기반으로 접근 권한을 주기 위해 토큰 내용에 유저의 역할을 넣어주었습니다.
  또한, 보안 강화를 위해 httpOnly 옵션을 준 쿠키를 사용해 토큰에 저장하였습니다.

---

📝 개념 정리

• JWT와 Session은 서버가 인증을 처리하는 방식으로, 먼저 인증과 인가의 개념에 대해 알 필요가 있다.

• 인증과 인가는 정보 보안 및 시스템 접근 제어에서 매우 중요한 개념이다. 이 두 용어는 비슷하게 사용되지만, 실제로는 서로 다른 역할을 가지고 있다.

  • 인증 (Authentication)

    💖 개념

    • 사용자의 신원을 확인하는 과정
    • 사용자가 시스템이나 네트워크에 접근하려고 할 때, 시스템은 사용자가 주장하는 신원이 실제로 맞는지 확인한다.

    💖 방법

    1. 비밀번호 : 가장 일반적인 인증 방법이다. 사용자는 자신의 비밀번호를 입력하여 신원을 증명한다.
    2. 생체 인식 : 지문, 얼굴 인식, 홍채 인식 등 생체 정보를 사용하여 신원을 확인한다.
    3. 토큰 : 물리적인 장치나 소프트웨어를 사용하여 인증을 수행한다. 예를 들어, OTP(One-Time Password) 생성기나 스마트카드가 있다.
    4. 이메일 링크 또는 SMS 코드 : 이메일이나 문자 메시지를 통해 전송된 링크나 코드를 입력하여 인증을 수행한다.

    💖 목표

    사용자가 누구인지 확인하고, 그 신원이 시스템의 기록과 일치하는지 검증한다.

    💖 예시

    당신이 온라인 뱅킹 시스템에 로그인하려고 할 때, 시스템은 당신이 입력한 사용자 이름과 비밀번호를 검증하여 당신의 신원을 확인한다.

  • 인가 (Authorization)

    💖 개념

    • 인증된 사용자가 특정 자원이나 기능에 접근할 수 있는 권한이 있는지를 결정하는 과정
    • 사용자가 시스템에 로그인한 후, 그 사용자가 어떤 작업을 수행할 수 있는지, 어떤 데이터에 접근할 수 있는지를 설정한다.

    💖 방법

    1. 권한 설정 : 시스템 관리자는 사용자 계정에 대한 권한을 설정한다. 예를 들어, 관리자, 사용자, 게스트 등의 역할에 따라 접근 권한을 부여할 수 있다.
    2. 역할 기반 접근 제어 (RBAC) : 사용자의 역할에 따라 권한을 부여하는 방식이다. 예를 들어, 관리자에게는 모든 데이터에 대한 접근 권한을 주고, 일반 사용자에게는 제한된 접근만 허용한다.
    3. 정책 기반 접근 제어 (PBAC) : 정책에 기반하여 접근을 제어한다. 예를 들어, 특정 조건이 충족될 때만 접근을 허용하는 방식이다.

    💖 목표

    인증된 사용자가 접근할 수 있는 자원과 수행할 수 있는 작업을 정의하여 보안을 강화한다.

    💖 예시

    로그인한 후, 시스템은 당신의 계좌 정보나 거래 기능에 접근할 수 있는지, 또는 다른 사용자 계좌에 대한 정보에 접근할 수 있는지 여부를 결정한다.

---

🌟 세션 (Session)

• 민감한 정보가 브라우저(클라이언트)에 저장되는 쿠키의 보안적 이슈를 해결하기 위해 나온 방식

• 세션은 비밀번호같이 민감한 정보를 브라우저가 아닌 서버에 저장하고 관리한다.

• 세션 저장 시에는 세션 불일치 문제를 해결하기 위해 메모리(Redis)나 데이터베이스(JDBC)에 저장한다.

• 인증/인가 방식

  1. 세션 생성

     1) 로그인 과정

     • 사용자가 웹 애플리케이션에 로그인하면, 서버는 사용자의 신원을 확인하고 인증을 수행한다.
     • 인증이 성공하면 서버는 세션을 생성한다.

     2) 세션 ID 발급

     • 서버는 고유한 세션 ID를 생성하고, 이를 클라이언트(사용자의 웹 브라우저)에 쿠키로 저장한다.
     • 이 세션 ID는 사용자의 세션을 식별하는 데 사용된다.

  2. 세션 저장

     1) 서버 측 저장

     • 세션 데이터는 서버의 메모리, 데이터베이스, 파일 시스템 등 서버 측 저장소에 저장된다.
     • 이 데이터에는 사용자 정보, 인증 상태, 권한 정보 등이 포함될 수 있다.

     2) 클라이언트 측 쿠키

     • 세션 ID는 클라이언트 측 쿠키에 저장된다.
     • 클라이언트는 이후 요청 시 이 쿠키를 서버에 전송하여 자신의 세션을 식별한다.

  3. 세션 관리

     1) 세션 유효성 검사

     클라이언트가 서버에 요청을 보낼 때마다, 서버는 요청에 포함된 세션 ID를 확인하여 해당 세션이 유효한지 검사한다.

     2) 세션 타임아웃

     • 서버는 세션의 유효 기간을 설정하고, 일정 시간 동안 사용자가 활동이 없으면 세션을 자동으로 만료시킬 수 있다.
     • 이를 통해 세션 하이재킹과 같은 보안 위험을 줄일 수 있다.

  4. 인가 처리

     1) 권한 검사

     • 인증된 사용자가 특정 리소스나 기능에 접근할 때, 서버는 해당 사용자의 권한을 확인한다.
     • 이 정보는 서버에 저장된 세션 데이터에서 가져오며, 사용자가 요청한 작업이 허용되는지 검사한다.

     2) 역할 기반 접근 제어 (RBAC)

     사용자의 역할(예: 관리자, 일반 사용자)에 따라 접근 권한을 설정하고, 이를 세션 데이터에 포함시켜 관리한다.

  5. 로그아웃 및 세션 종료

     1) 로그아웃

     용자가 로그아웃하면, 서버는 세션을 종료하고 클라이언트 측 쿠키에서 세션 ID를 삭제한다.

     2) 세션 만료

     • 세션이 일정 시간 동안 비활동 상태에 있을 때 자동으로 만료될 수 있다.
     • 이 경우, 사용자는 다시 로그인해야 한다.

• 세션 기반 인증/인가의 장점

  1. 상태 유지 : HTTP는 무상태(stateless) 프로토콜이므로, 세션을 통해 사용자 상태와 상호작용을 유지할 수 있다.
  2. 보안 : 세션은 서버 측에서 데이터와 상태를 관리하므로, 중요한 정보는 클라이언트 측에 저장되지 않는다.
  3. 편리함 : 사용자가 로그인 후 여러 페이지를 탐색하거나 여러 작업을 수행할 때, 매번 인증을 다시 할 필요가 없다.

• 세션 기반 인증/인가의 단점 및 보안 고려사항

  1. 세션 하이재킹

     • 공격자가 세션 ID를 탈취하여 사용자의 세션을 도용할 수 있다.
     • 이를 방지하기 위해 세션 ID를 안전하게 저장하고 전송하며, HTTP5를 사용하는 것이 중요하다.

  2. 세션 고정

     • 공격자가 고정된 세션 ID를 사용하여 사용자의 세션을 탈취할 수 있다.
     • 따라서, 사용자가 로그인할 때마다 새로운 세션 ID를 발급하는 것이 좋다.

  3. 서버 자원 소모

     • 서버가 세션 데이터를 저장하고 관리하기 때문에, 서버의 메모리나 저장 공간을 소모할 수 있다.

  4. 세션 타임아웃 및 만료

     • 세션이 너무 오래 유지되면 보안 위험이 증가할 수 있다.
     • 적절한 타임아웃 설정과 로그아웃 기능이 필요하다.

---

🌟 JWT (JSON Web Token)

• 토큰 기반 인증 시스템

• 토큰 (Token)

  • 사용자(클라이언트)가 서버에 인증 요청을 보내면 서버에는 인증 절차를 수행하고 유효한 사용자면 인증되었다는 토큰을 부여한다.

  • 이 토큰은 유일하며 토큰을 발급받은 클라이언트는 서버에 요청을 보낼 때마다 요청 헤더가 토큰을 담아 보내고, 서버는 제공한 토큰과 사용자의 토큰의 일치 여부를 체크한다.

  • 인증 정보가 서버에 저장되는 세션과 달리 토큰은 클라이언트에 저장된다. 그렇기 때문에 서버의 부담을 덜 수 있다.

• JSON 형식의 정보를 안전하게 전달하기 위해 설계된 웹 토큰

• 세 부분(헤더, 페이로드, 서명)으로 구성된 인코딩된 문자열

  • 헤더(Header) : 토큰의 유형(JWT)과 해싱 알고리즘(예: HMAC SHA256)을 포함한다.

  • 페이로드(Payload) : 토큰에 포함된 클레임(사용자 정보 및 기타 데이터)을 포함한다.

  • 서명(Signature) : 헤더와 페이로드를 인코딩한 후 비밀 키로 서명하여 토큰의 무결성을 검증한다.

• 인증/인가 방식

  1. 로그인 및 토큰 발급

     • 사용자가 로그인하면 서버는 사용자의 신원을 확인한 후, JWT를 생성한다. JWT에는 사용자의 ID, 권한 정보, 만료 시간 등 중요한 정보가 포함된다.
     • 서버는 헤더와 페이로드를 조합하여 비밀 키로 서명하고, 클라이언트에게 이 토큰을 반환한다.

  2. 클라이언트 측 저장

     • 클라이언트는 받은 JWT를 로컬 스토리지나 세션 스토리지에 저장한다.
     • 클라이언트는 이후 요청 시마다 이 토큰을 포함하여 서버에 보낸다.

  3. 서버 측 인증

     • 클라이언트가 보호된 리소스에 접근하려고 할 때, 요청 헤더에 JWT를 포함하여 서버에 보낸다.
     • 서버는 받은 JWT의 서명을 검증하여 토큰의 무결성을 확인한다. 서명이 유효하다면, 서버는 페이로드의 정보를 사용하여 사용자를 인증한다.

  4. 인가 처리

     • 서버는 JWT의 페이로드에 포함된 권한 정보를 확인하여 사용자가 요청한 리소스나 작업을 수행할 권한이 있는지 결정한다.
     • 필요 시, 추가적인 권한 검사를 수행할 수도 있다.

  5. 토큰 갱신

     • JWT는 만료 시간(exp) 정보를 포함하므로, 일정 시간이 지나면 만료된다.
     • 클라이언트는 토큰이 만료되기 전에 갱신 요청을 하여 새로운 토큰을 받을 수 있다.

• JWT 기반 인증/인가의 장점

  1. 무상태성 (Stateless)

     • 서버는 사용자 세션 상태를 유지할 필요가 없다.
     • 모든 필요한 정보는 JWT에 포함되어 있어 서버는 단순히 토큰을 검증하기만 하면 된다.

  2. 확장성 (Scalability)

     • 서버 간 세션 공유가 필요 없으므로, 수평 확장이 용이하다.
     • 이는 마이크로서비스 아키텍처에 매우 유리하다.

  3. 효율성 (Efficiency)

     • JWT는 클라이언트 측에서 저장되고, 클라이언트가 요청 시마다 서버에 토큰을 보내기 때문에 인증 및 인가 과정이 빠르고 효율적이다.

• JWT 기반 인증/인가의 단점 및 보안 고려사항

  1. 토큰 탈취 위험

     • JWT가 탈취되면 공격자가 이를 사용하여 인증된 사용자로서 행동할 수 있다.
     • 이를 방지하기 위해 HTTPS를 사용하여 토큰을 안전하게 전송해야 한다.

  2. 토큰 만료 관리

     • JWT는 기본적으로 무상태이므로, 만료된 토큰을 강제로 무효화하는 것이 어렵다.
     • 이를 해결하기 위해, 짧은 만료 시간을 설정하고 리프레시 토큰을 사용하는 방법이 있다.

  3. 토큰 크기

     • JWT는 페이로드에 많은 정보를 포함할 수 있어 토큰의 크기가 커질 수 있다.
     • 이는 네트워크 트래픽에 영향을 미칠 수 있다.

---

🌟 JWT와 세션 기반 인증의 비교

	세션 기반 인증	JWT 기반 인증
상태 유지	서버가 세션 상태를 유지한다.	서버는 무상태로 작동하며, 클라이언트가 상태 정보를 유지한다.
확장성	서버 간 세션 상태 공유가 필요하여 확장이 어려울 수 있다.	서버 간 상태 공유가 필요 없어 확장이 용이하다.
보안	세션 탈취와 세션 고정 공격에 취약할 수 있다.	토큰 탈취 및 만료 관리가 주요 보안 고려사항이다.