인증 방법: Cookies and Sessions, JWT, PASETO

개요

프로젝트를 진행하다 보면 사용자 인증이 꼭 필요한 경우가 있습니다. 사용자 인증은 사용자가 누구인지 확인하고 사용자의 권한을 확인하는 과정입니다. 최근에는 다양한 인증 방법이 등장하여 사용자 인증을 보다 효율적으로 할 수 있습니다. 이번 글에서는 Cookies and Sessions, JWT, PASETO를 비교 분석하여 사용자 인증 방법에 대해 정리해 보겠습니다.

어떤 인증 방법이 있는가?

최근 인증 방법으로는 Cookies and Sessions, JWT, PASETO가 있습니다.

• Cookies and Sessions: 서버에서 세션을 관리하고 클라이언트에 세션 ID를 전달하여 인증하는 방식입니다.
• JWT: JSON Web Token으로 클라이언트에 토큰을 전달하여 인증하는 방식입니다.
• PASETO: Platform Agnostic Security Token으로 JWT의 단점을 보완한 토큰입니다.

더 구체적으로 알아보기 전 Authentication과 Authorization에 대해 알아보겠습니다.

Authentication과 Authorization

• 인증(Authentication): 사용자가 누구인지 확인하는 과정입니다.
• 권한(Authorization): 사용자가 어떤 권한을 가지고 있는지 확인하는 과정입니다.

예를 들어, 우리 도메인의 사용자인 것을 증명하는 것은 인증이고, 그 사용자가 어떤 권한(예: 삭제 가능 여부, 새로운 포스트 작성 가능 여부)을 가지고 있는지 확인하는 것은 인가입니다.

Cookies and Sessions

Cookies

Cookies는 클라이언트에 저장되는 작은 데이터 파일입니다. Cookies는 웹 애플리케이션은 사용자의 상태를 유지하거나 사용자를 식별하는 데 사용하여 여러 요청을 할 수 있도록 도와주며, stateless 한 HTTP 프로토콜에서 상태를 유지할 수 있도록 도와줍니다.

 

Cookies은 다양한 목적에 사용됩니다.

• 세션 관리(Session Management): session ID를 저장하여 사용자를 추적합니다.
• 개인화(Personalization): 사용자의 선호도를 저장합니다.
• 분석 및 추적(Analytics and Tracking): 분석 및 추적을 위한 사용자 정보를 저장합니다.

인증에서 Cookies는 session ID를 저장하여 사용자를 추적하는 데 사용됩니다. 이 과정은 일반적으로 두 단계로 이루어집니다.

1. 유저 로그인
   1. 사용자가 자격 증명을 서버에 제공합니다. (예: 사용자 이름, 비밀번호)
   2. 서버는 사용자를 인증하고 사용자에게 session ID를 제공합니다.
   3. 클라이언트(브라우저)는 session ID를 Cookies에 저장합니다.
2. Cookies를 사용하여 사용자 요청
   1. 사용자가 서버에 요청을 보낼 때 Cookies에 저장된 session ID를 함께 보냅니다.
   2. 서버는 session ID를 사용하여 사용자를 식별합니다.

 

Cookies의 장점

Cookies의 주요 장점은 다음과 같습니다.

• 폭넓은 지원: 대부분의 브라우저가 Cookies를 지원합니다.
• 영구 저장: Cookies는 특정 시간 후에 만료되거나 사용자가 수동으로 삭제하기 전까지 유지됩니다.
• 자동 전송: 브라우저는 모든 요청에 그 도메인에 대한 Cookies를 자동으로 전송하므로 개발자가 Cookies를 수동으로 전송할 필요가 없습니다.
• 보안: Cookies는 HttpOnly, Secure, SameSite 등의 속성을 사용하여 보안을 강화할 수 있습니다.

Cookies 사용의 주의점

Cookies를 사용할 때 주의해야 할 점은 다음과 같습니다.

• 크로스 사이트 스크립팅(Cross-Site Scripting, XSS)에 대한 취약점: 악성 스크립트가 웹사이트에 주입되면 민감한 정보가 포함된 Cookies를 탈취할 수 있습니다. JavaScript를 사용할 때 HttpOnly 속성을 사용하여 JavaScript에서 Cookies에 접근할 수 없도록 해야 합니다.
• 중간에서 탈취에 대한 취약점(Man-in-the-Middle Attack, MITM): Cookies는 암호화되지 않은 HTTP 통신을 통해 전송되므로 중간에서 탈취될 수 있습니다. Secure 속성을 사용하여 HTTPS에서만 Cookies를 전송하도록 해야 합니다.
• CSRF(Cross-Site Request Forgery)에 대한 취약점: 사용자가 악의적인 웹사이트를 방문하면 사용자의 Cookies를 사용하여 사용자의 권한으로 요청을 보낼 수 있습니다. SameSite속성을 사용하여 Cookies를 제한하고 CSRF Token을 사용하여 요청을 검증해야 합니다.
• Storage 제한: 브라우저는 도메인당 Cookies를 크기(일반적으로 4KB)와 개수(일반적으로 20개)로 제한합니다. 그래서 꼭 필요한 정보만 Cookies에 저장해야 합니다.
• Cookies Overflow: 너무 많은 Cookies를 사용하면 서버에 요청할 때 성능 문제나 요청 거부로 이어질 수 있습니다. 그래서 신중하게 사용해야 합니다.

브라우저 개발자 도구에서 Cookies 확인하기

1. 브라우저에서 개발자 도구를 엽니다.(예: Chrome에서 F12를 누릅니다.)
2. Application 탭을 선택합니다.
3. Cookies 섹션에서 Cookies를 확인할 수 있습니다.
4. name, value, domain, path, expires, size, httpOnly, secure, sameSite 등의 정보를 확인할 수 있습니다.

Sessions

Sessions은 애플리케이션 서버에서 사용자 인증 정보를 저장하는 방법입니다. Sessions은 사용자의 상태를 유지하고 사용자를 식별하는 데 사용하며 Sessiion ID만 클라이언트에 전달합니다.

 

Sessions의 동작 방식

1. 사용자가 로그인
   1. 사용자가 로그인하기 위해 자격 증명을 제공합니다. (예: 사용자 이름, 비밀번호)
   2. 서버는 자격 증명을 검증하고 사용자를 인증합니다.
2. Session ID 생성
   1. Session ID는 사용자 세션과 연결된 임의의 고유 식별자입니다.
   2. Session ID는 Cookies나 다른 방법(예: 응답 본문)을 통해 클라이언트에 전달됩니다.
3. Session 데이터 저장
   1. 서버는 Session 데이터를 메모리, 데이터베이스 또는 다른 스토리지 시스템에 저장합니다.
   2. Session ID를 키로 사용하여 이 데이터를 검색하는 데 사용합니다.
4. Session 유지
   1. 클라이언트가 서버에 요청을 보낼 때 Session ID를 함께 보냅니다.
   2. 서버는 Session ID를 사용하여 사용자를 식별하고 Session 데이터를 검색하고 요청을 처리합니다.
5. Session 만료
   1. Session은 비활성 기간 또는 최대 수명(Time-to-Live, TTL)이 지나면 만료됩니다.
6. Session 무효화
   1. 사용자가 로그아웃하거나 세션을 무효화하면 서버는 Session 데이터를 삭제되고 Session ID도 무효화됩니다.

 

Sessions 사용의 장점

Sessions의 주요 장점은 다음과 같습니다.

• 보안된 저장소: Sessions 데이터는 서버에 저장되므로 클라이언트에서 직접 액세스 할 수 없습니다. 그래서 크로스 사이트 스크립팅(Cross-Site Scripting, XSS)에 대한 취약점이 줄어듭니다.
• 유연성: Sessions은 클라이언트에 저장되는 Cookies와 달리 서버에 저장되므로 더 많은 데이터(예: 사용자 정보, 권한)를 저장할 수 있습니다.
• 무효화: Sessions은 서버에서 만료 및 무효화할 수 있으므로 액세스 권한을 즉시 취소할 수 있습니다.

Sessions 사용의 주의점

Sessions를 사용할 때 주의해야 할 점은 다음과 같습니다.

• 확장성: 분산 시스템(예: 마이크로서비스)에서 Sessions 데이터를 공유해야 하므로 중앙 데이터베이스 또는 분산 캐시(예: Redis)와 같은 추가 인프라가 필요합니다. 이러한 솔루션은 복잡하며 잠재적인 병목 현상을 초래할 수 있습니다.
• Session 하이재킹: Session ID를 탈취하면 사용자의 세션을 탈취할 수 있습니다. 이는 HTTPS를 사용하여 Session ID를 암호화하고 HttpOnly, Secure, SameSite 등의 속성도 사용하고 Session 시간을 짧게 유지하여 완화할 수 있습니다.
• Storage Overhead: Sessions 데이터는 서버 메모리 또는 데이터베이스에 저장되므로 서버 리소스를 소비할 수 있습니다. 그래서 Session 데이터를 최소화하고 최적화해야 합니다.

JWT

JWT는 JSON Web Token의 약자로 클라이언트와 서버 간에 인증 정보를 안전하게 전달하는 간결하고 URL-safe하며 독립적인 방법입니다.

 

JWT는 stateless하며 확장 가능한 시스템에서 인증 및 인가를 구현하는 데 자주 사용됩니다. 토큰에는 사용자 정보, 권한, 만료 시간 등의 모든 정보가 포함되어 있으므로 서버에서 세션을 관리할 필요가 없습니다.

JWT의 구조

JWT의 구조는 아래 그림과 같습니다.

JWT는 Base64로 인코딩 된 세 부분으로 구성됩니다.

• Header: JWT의 유형(typ), 서명 알고리즘(alg) 등의 메타데이터를 포함합니다.
• Payload: 클레임(claim) 정보(예: 사용자 ID, 권한, 만료 시간)를 포함합니다.
  • Registered Claims: iss(발급자), sub(주제), aud(대상자), exp(만료 시간)와 같은 표준 클레임입니다.
  • Public Claims: 공개적으로 사용할 수 있는 사용자가 정의한 클레임입니다.
  • Private Claims: 사용자가 정의한 비공개 클레임입니다.
• Signature: Header와 Payload를 서명하여 토큰의 무결성을 보장합니다. Header와 Payload를 Base64로 인코딩한 후 서버에서 비밀 키로 서명합니다.

JWT를 사용하는 방법

1. 토큰 발행
   • 사용자가 로그인하면 서버는 사용자 정보(예: 사용자 ID, 권한)를 페이로드에 포함하여 JWT를 생성합니다.
   • JWT는 secret key(대칭 암호화) 또는 private key(비대칭 암호화)를 사용하여 서명됩니다.
   • 서명된 토큰은 일반적으로 응답 본문 또는 Cookies에 응답 헤더에 포함됩니다.
2. JWT 포함 요청
   • 클라이언트는 JWT를 요청 Authorization 헤더에 Bearer 스키마로 포함하여 서버에 요청을 보냅니다.
3. 토큰 검증
   • 서버는 토큰의 만료 시간(exp), 대상자(aud), 서명을 확인하여 토큰의 유효성을 검사합니다.

JWT의 인증 과정은 아래 그림과 같습니다.

JWT의 stateless 한 특징

JWT는 stateless 한 특징을 가지고 있습니다.

• 서버는 세션 데이터를 저장할 필요가 없습니다. 모든 사용자 인증 정보가 토큰에 포함되어 있습니다.
• 서버는 토큰을 검증하는 데 필요한 서명 키만 알고 있으면 되므로 분산 시스템에서 확장성이 좋습니다.

JWT의 장점

JWT의 주요 장점은 다음과 같습니다.

• 확장성: JWT는 stateless 하여 서버에서 세션을 관리할 필요가 없으므로 마이크로서비스나 분산 시스템에서 사용하는데 적합합니다.
• 간결성과 전송 용이성: JWT는 URL-safe 하고 Base64로 인코딩 되어 있어서 HTTP 헤더, 쿠키 등에 쉽게 포함할 수 있습니다.
• 교차 도메인(Cross-Domain) 지원: JWT는 클라이언트와 서버 간에 도메인이 다른 경우에도 사용할 수 있어 SSO(Single Sign-On)에 적합합니다.
• 보안성: JWT는 서명된 토큰이므로 토큰의 무결성을 보장할 수 있습니다.

JWT의 주의점

JWT를 사용할 때 주의해야 할 점은 다음과 같습니다.

• 토큰 도난: JWT는 클라이언트에 저장되므로 탈취되면(예: XSS) 사용자의 권한이 탈취될 수 있습니다. HTTPS를 사용하여 통신을 암호화하고 HttpOnly, Secure, SameSite 등의 속성을 사용하여 보안을 강화할 수 있습니다.
• 만료 관리: JWT의 만료 시간을 짧게 유지합니다. 이 문제는 리프레시 토큰을 사용하면 다시 로그인 없이 토큰을 갱신할 수 있습니다.
• 토큰 크기: JWT는 페이로드에 사용자 정보를 포함하므로 토큰의 크기가 커질 수 있습니다. 이는 성능에 영향을 줄 수 있으므로 필요한 정보만 포함하도록 해야 합니다.
• 액세스 제어: JWT는 한 번 발급되면 무효화할 수 없으므로 토큰의 액세스 권한을 제어하는 방법을 고려해야 합니다. 이 문제는 JWT의 만료 시간을 짧게 유지하고 Blacklist를 사용하여 무효화할 수 있습니다.

PASETO: JWT에 대한 보안 대안

PASETO는 Platform Agnostic Security Token의 약자로 JWT에 대한 보안 대안입니다. 이는 보안, 단순성, 암호화를 초첨을 두고 설계되었습니다.

PASETO는 JWT와 어떻게 다른가? 

PASETO는 JWT와 다음과 같은 차이점이 있습니다.

• 더 강력한 암호화 봉자:
  • PASETO는 강력하고 현대적인 암호화 알고리즘을 사용하도록 강제합니다. 이는 안전하지 않거나 오래된 알고리즘을 사용하는 JWT의 취약점을 보완합니다.
  • 예를 들어, JWT는 개발자가 약한 암호화 알고리즘(예: HS256)을 사용할 수 있지만, PASETO는 다음과 같은 강력한 암호화 알고리즘을 사용합니다.
    • AES-GCM for encryption (symmetric): 기밀성과 무결성을 위해 대칭 암호화를 사용합니다.
    • Ed25519 for signing (asymmetric): 인증 및 부인 방지를 위해 비대칭 암호화를 사용합니다.
• 단순한 구조:
  • PASETO는 명확한 방식을 채택하여 JWT의 취약점 중 하나인 알고리즘 협상을 피함으로써 불필요한 복잡성을 줄입니다.
  • JWT와 달리 각 PASETO 버전은 고유한 암호화 및 서명 알고리즘을 사용하므로 알고리즘 협상이 필요하지 않습니다.
• 가독성 및 안전성:
  • PASETO는 local 토큰과 public 토큰을 제공하여 암호화된 토큰과 서명된 토큰을 구분합니다. 민감한 정보를 포함하는 local 토큰은 암호화되어 있고 공개적인 정보를 포함하는 public 토큰은 서명되어 있습니다.
  • JWT는 암호화 된 경우에도 일반 텍스트로 디코딩할 수 있으므로 민감한 정보를 포함하는 경우 보안에 취약할 수 있습니다.
• 내장된 취약점 방지 기능:
  • PASETO는 JWT에서 흔히 발생하는 알고리즘 변경과 같은 취약점을 방지하기 위해 설계되었습니다.

PASETO의 구조 

PASETO의 구조는 아래 그림과 같습니다.

PASETO는 다음과 같은 부분으로 구성됩니다.

• Version: PASETO 버전을 나타냅니다. 버전은 암호화 및 서명 알고리즘을 결정합니다.
• Purpose: local(암호화된 토큰) 또는 public(서명된 토큰)을 나타냅니다.
• Payload: 클레임 정보(예: 사용자 ID, 권한)를 포함합니다.
  • local 토큰의 경우 암호화된 Base64Url-encoded 문자열로 인코딩됩니다.
  • public 토큰의 경우 평문을 유지하며 Base64Url-encoded 문자열로 인코딩됩니다.
• Footer: 추가 정보(예: 발행자-iss, 받는 사람-aud)를 포함합니다.

Local PASETO와 Public PASETO

Local PASETO은 암호화되어 토큰에 포함된 데이터의 기밀성을 보장합니다. 대칭 암호화 알고리즘(AES-GCM 등)을 사용하여 암호화된 local 토큰은 공유 비밀 키를 사용하여 복호화 할 수 있습니다.

 

아래 그림은 Local PASETO의 작동 방식을 보여줍니다.

Public PASETO는 서명되어 토큰의 무결성을 보장합니다. 이는 데이터의 변조를 방지하고 데이터의 출처를 인증할 수 있지만 데이터의 기밀성은 보장하지 않습니다. 이러한 토큰은 누구나 읽을 수 있지만 서명키 보유자만 검증할 수 있습니다. 즉, 서명을 무효화하지 않고는 토큰을 변경할 수 없습니다.

 

Public PASETO은 비대칭 암호화 알고리즘(Ed25519 등)을 사용하여 서명되며 공개 키를 사용하여 검증할 수 있습니다. 이는 클라이언트가 페이로드를 읽어야 하지만 변조 방지 기능을 유지해야 하는 경우에 적합합니다.

 

아래 그림은 Public PASETO의 작동 방식을 보여줍니다.

PASETO의 장점 

PASETO의 주요 장점은 다음과 같습니다.

• 안전한 설계: PASETO은 안전하지 않거나 더 이상 사용되지 않는 암호화 알고리즘이 없으므로 개발자가 취약한 알고리즘을 사용하는 것을 방지합니다. JWT의 none 알고리즘이나 안전하지 않은
  알고리즘(예: HS256)을 사용하는 것을 방지합니다.
• 사용 편의성: 알고리즘 협상이 없으므로 구현이 간소화되고 구성 오류의 위험이 줄어듭니다.
• 완전 암호화 가능: PASETO는 local 토큰을 사용하여 데이터의 기밀성을 보장하므로 민감한 정보를 포함하는 토큰을 안전하게 전송할 수 있습니다. JWT는 사인 된 경우에도 일반 텍스트로
  디코딩할 수 있으므로 민감한 정보를 포함하는 경우 보안에 취약할 수 있습니다.
• 상위 호환성: PASETO는 버전이 관리되므로(예: v1,v2) 새로운 알고리즘을 추가하거나 개선 사항을 이전 버전과 호환성 있게 도입할 수 있습니다.
• 크로스 플랫폼 지원: PASETO는 플랫폼에 구애받지 않으므로 다양한 프로그래밍 언어 및 플랫폼에서 사용할 수 있습니다.

PASETO의 주의점 

PASETO를 사용할 때 주의해야 할 점은 다음과 같습니다.

• 제한된 사용: PASETO는 JWT보다 비교적 새로운 표준이므로 덜 사용되고 있습니다. 이는 PASETO를 지원하는 라이브러리 및 프레임워크가 적다는 것을 의미합니다.
• 학습 곡선: JWT에 익숙한 개발자에게는 PASETO의 새로운 구조와 사용법을 익히는 데 시간이 걸릴 수 있습니다.
• 생태계 성숙도: PASETO 표준은 명확하게 정의되어 있지만 JWT와 같이 널리 사용되지 않으므로 생태계가 덜 성숙합니다. 미들웨어, 라이브러리, 프레임워크의 지원이 부족합니다.

비교 분석

Cookies and Sessions, JWT, PASETO의 비교 분석은 다음과 같습니다.

특징	Cookies and Sessions	JWT	PASETO
상태 관리	상태 기반 (Stateful)	무상태 (Stateless)	무상태 (Stateless)
저장소	서버	클라이언트 토큰	클라이언트 토큰
확장성	분산 시스템에서 한계	우수	우수
기밀성	우수(서버에서 관리)	상대적으로 부족	암호화된 토큰 지원
무효화	쉽다	어렵다	어렵다
구현 복잡성	비교적 간단	복잡하다	JJWT보다 간단
생태계 성숙도	매우 성숙	성숙	성숙도가 낮음

결론

이번 글에서는 Cookies and Sessions, JWT, 그리고 PASETO를 비교 분석하며 사용자 인증 방법에 대해 알아보았습니다. 각각의 방법은 고유한 장단점이 있으며, 사용 사례에 따라 적합한
선택이 달라질 수 있습니다.

• 모노리틱 애플리케이션에서는 Cookies and Sessions가 안정적이고 효율적인 선택입니다.
• 반면, 마이크로서비스나 분산 시스템에서는 확장성과 무상태성을 제공하는 JWT 또는 PASETO가 적합합니다.
• 그러나 주의해야 할 점도 있은 PASETO는 아직 생태계가 충분히 성숙하지 않아 사용에 어려움이 있을 수 있습니다.

최종적으로, 인증 방식을 선택할 때는 시스템 구조와 요구 사항을 종합적으로 고려해야 합니다.