진화하는 웹 세션 관리 전략

소개

빠르게 진화하는 웹 애플리케이션 환경에서 사용자 세션을 안전하고 효율적으로 관리하는 것은 매우 중요합니다. 강력한 세션 관리 전략은 인증된 사용자가 요청 간에 로그인 상태를 유지하도록 보장하며, 민감한 데이터를 보호하고 무단 액세스를 방지합니다. 웹 애플리케이션이 복잡해지고 모놀리식 아키텍처에서 분산 마이크로서비스로 전환됨에 따라, 전통적인 세션 관리 접근 방식은 종종 부족합니다. 이는 상태 없는 세상에서 사용자 상태를 처리하는 방식을 재평가할 필요성을 야기합니다. 이 글은 JavaScript 기반 웹 애플리케이션을 위한 현대적인 세션 관리 전략, 즉 JSON 웹 토큰(JWT), 플랫폼 비종속 보안 토큰(PASETO) 및 데이터베이스 기반 세션을 비교 분석하고, 각 원칙, 구현 및 실제 사용 사례를 설명하여 다음 프로젝트에 가장 적합한 것을 선택하는 데 도움을 줄 것입니다.

웹 세션 관리의 핵심 개념

다양한 전략을 자세히 살펴보기 전에 웹 세션 관리에 관련된 핵심 개념에 대한 공통된 이해를 확립해 봅시다.

• 상태 유지 vs. 상태 없는 세션:

  • 상태 유지 세션은 서버가 사용자 세션에 대한 정보를 저장해야 합니다(예: 메모리 또는 데이터베이스). 각 들어오는 요청은 서버가 이 상태를 조회해야 합니다.
  • 상태 없는 세션은 서버가 어떤 세션 정보도 저장하지 않음을 의미합니다. 필요한 모든 사용자 컨텍스트는 클라이언트가 보낸 토큰에 포함됩니다. 이는 애플리케이션을 수평으로 확장하는 데 특히 유용합니다.

• 인증 vs. 인가:

  • 인증은 사용자의 신원을 확인하는 프로세스입니다(예: 사용자 이름과 비밀번호).
  • 인가는 인증된 사용자가 수행할 수 있는 작업을 결정하는 프로세스입니다. 세션 토큰은 종종 인가 정보(예: 역할 또는 권한)를 포함합니다.

• 세션 토큰: 성공적인 인증 후 서버가 클라이언트에 발급하는 데이터 조각으로, 클라이언트는 이를 사용하여 자신의 신원 및 인가 를 증명합니다.

• 보안 고려 사항:

  • 기밀성: 세션 데이터에 대한 무단 액세스를 방지합니다.
  • 무결성: 세션 데이터가 변경되지 않았는지 확인합니다.
  • 가용성: 사용자가 세션에 안정적으로 액세스할 수 있는지 확인합니다.
  • 재현 공격: 공격자가 유효한 토큰을 가로채어 무단 액세스를 얻기 위해 재사용하는 경우입니다.
  • 크로스 사이트 스크립팅(XSS) 및 크로스 사이트 요청 위조(CSRF): 세션 토큰을 손상시킬 수 있는 일반적인 웹 취약점입니다.

이러한 용어를 명확히 한 후, 세션 관리 전략을 살펴보겠습니다.

JSON 웹 토큰(JWT)

JWT는 두 당사자 간에 전송될 클레임을 나타내는 작고 URL 안전한 방법입니다. 자체 포함 특성으로 인해 상태 없는 세션 관리에 인기 있는 선택입니다.

JWT 작동 방식

JWT는 점(.)으로 구분되는 세 부분으로 구성됩니다:

1. 헤더: 일반적으로 토큰 유형(JWT)과 서명 알고리즘(예: HS256, RS256)을 포함합니다.

   {
     "alg": "HS256",
     "typ": "JWT"
   }

2. 페이로드 (클레임): 엔티티에 대한 실제 데이터(클레임)와 추가 메타데이터를 포함합니다. 일반적인 클레임은 다음과 같습니다:
   • sub (subject): JWT의 주제인 주체를 식별합니다.
   • exp (expiration time): JWT가 수락되지 않아야 하는 만료 시간을 식별합니다.
   • iat (issued at time): JWT가 발급된 시간을 식별합니다.
   • 사용자 지정 클레임(예: 사용자 ID, 역할).

   {
     "userId": "123",
     "roles": ["admin", "editor"],
     "iat": 1678886400,
     "exp": 1678890000
   }

3. 서명: 인코딩된 헤더, 인코딩된 페이로드, 비밀 키 및 헤더에 지정된 알고리즘을 사용하여 생성됩니다. 이 서명은 JWT 발신자가 누구인지 verif y하고 메시지가 변경되지 않았는지 확인하는 데 사용됩니다.

세 부분은 base64-url로 인코딩되고 점으로 연결됩니다: header.payload.signature.

구현 예제(Node.js와 jsonwebtoken)

const jwt = require('jsonwebtoken');

const SECRET_KEY = 'your_super_secret_key'; // 실제 앱에서는 환경 변수 사용

// 1. 성공적인 로그인 시 JWT 생성
function generateToken(user) {
    const payload = {
        userId: user.id,
        username: user.username,
        roles: user.roles
    };
    // 토큰은 1시간 후에 만료됩니다.
    return jwt.sign(payload, SECRET_KEY, { expiresIn: '1h' });
}

// 2. 후속 요청에서 JWT verif y
function verifyToken(req, res, next) {
    const authHeader = req.headers['authorization'];
    if (!authHeader) return res.status(401).send('Authorization header missing');

    const token = authHeader.split(' ')[1]; // "Bearer TOKEN" 예상
    if (!token) return res.status(401).send('Token missing');

    try {
        const decoded = jwt.verify(token, SECRET_KEY);
        req.user = decoded; // 요청에 사용자 정보 첨부
        next();
    } catch (err) {
        return res.status(403).send('Invalid or expired token');
    }
}

// 예제 사용법
const user = { id: 1, username: 'alice', roles: ['user'] };
const token = generateToken(user);
console.log('Generated JWT:', token);

// 요청 시뮬레이션
const mockRequest = {
    headers: {
        authorization: `Bearer ${token}`
    }
};
const mockResponse = {
    status: (code) => ({ send: (msg) => console.log(`Response ${code}: ${msg}`) })
};
const mockNext = () => console.log('Token verified, proceeding to route handler.');

verifyToken(mockRequest, mockResponse, mockNext);

애플리케이션 시나리오

JWT는 다음을 위해 이상적입니다:

• 상태 없는 API 및 마이크로서비스: 서비스가 공유 세션 저장소 없이 사용자 신원을 verif y해야 하는 경우.
• 모바일 애플리케이션: 일반적으로 토큰이 장치에 안전하게 저장됩니다.
• 단일 로그인(SSO): 인증 서버가 여러 애플리케이션에서 사용할 수 있는 토큰을 발급하는 경우.

JWT의 장단점

장점:

• 상태 없음: 서버 부하를 줄이고 수평 확장을 단순화합니다.
• 자체 포함: 필요한 모든 정보가 토큰에 있습니다.
• 분산: 공유 세션 데이터베이스가 필요 없어 마이크로서비스에 이상적입니다.
• 표준화: 널리 채택되었습니다(RFC 7519).

단점:

• 토큰 무효화: 블랙리스트 메커니즘 없이는 만료 전에 JWT를 취소하는 것이 어렵습니다. 이는 상태를 다시 도입합니다.
• 토큰 크기: 페이로드에 너무 많은 데이터를 저장하면 토큰이 커져 성능에 영향을 미칠 수 있습니다.
• 암호화 부족: JWT는 기본적으로 서명만 되고 암호화되지는 않습니다. 페이로드의 민감한 데이터는 base64로 인코딩될 뿐 보안되지 않습니다.
• CSRF 취약점: 쿠키에 저장된 경우 JWT는 적절한 방어 조치(예: SameSite 쿠키, CSRF 방지 토큰)가 없는 한 CSRF에 취약합니다.

플랫폼 비종속 보안 토큰(PASETO)

P ASETO는 JWT의 많은 암호화 약점과 복잡성을 해결하는 현대적이고 안전한 대안입니다. 단순성, 기본적으로 안전한 관행 및 강력한 암호화에 중점을 둡니다.

PASETO 작동 방식

JWT와 달리 PASETO는 임의의 알고리즘이나 서명되지 않은 토큰을 허용하지 않아 일반적인 공격 벡터를 제거합니다. 서명 및 선택적으로 토큰을 암호화하기 위한 모범 사례를 엄격하게 시행합니다. PASETO 토큰은 vX.purpose.payload.footer와 같이 표시되며, 여기서 X는 버전(예: v3), purpose는 local(암호화됨) 또는 public(서명됨)이고 payload에는 클레임이 포함됩니다.

• 버전: PASETO는 암호화 민첩성을 보장하고 취약한 알고리즘을 사용 중단하기 위해 버전을 정의합니다.
• 목적:
  • local: 암호화된 토큰용입니다. 페이로드는 인증된 암호화(예: AES-GCM 또는 XChaCha20-Poly1305)로 암호화됩니다. 이는 기밀성과 무결성을 모두 제공합니다.
  • public: 서명된 토큰용입니다. 페이로드는 비대칭 암호화(예: EdDSA)로 서명됩니다. 이는 무결성과 인증을 제공합니다.
• 푸터: 인증되지만 암호화되지는 않는 선택적 필드입니다. 민감하지 않은 메타데이터(예: 키 ID)를 저장하는 데 유용합니다.

구현 예제(Node.js와 paseto)

const { V3 } = require('paseto');
const { generateSync, decode } = V3; // 최신 알고리즘용 V3 사용
const { generateKey } = require('crypto'); // 키를 안전하게 생성하기 위해

// 전역 키 저장소를 확보하거나 구성에서 검색해야 합니다.
let privateKey, publicKey_PASETO;
generateKey('ed25519', {}, (err, pKey) => { // 공개(서명됨) 토큰용
    if (err) throw err;
    privateKey = pKey.export({ type: 'pkcs8', format: 'pem' });
    publicKey_PASETO = pKey.export({ type: 'spki', format: 'pem' });
});

let symmetricKey; // 로컬(암호화됨) 토큰용
generateKey('aes', { length: 256 }, (err, sKey) => {
    if (err) throw err;
    symmetricKey = sKey.export().toString('base64'); // base64 문자열로 저장
});


// 쉬운 저장을 위한 base64url 인코딩/디코딩 도우미(PASETO 사양은 아님, 그러나 일반적)
function base64url(str) {
  return Buffer.from(str).toString('base64url');
}

// 1. 로그인 시 공개(서명됨) PASETO 토큰 생성
async function generatePublicPaseto(user) {
    // 실제 앱에서는 privateKey가 안전한 소스에서 로드됩니다.
    // 데모의 경우 위에서 생성된 키를 사용합니다.
    // 키 생성이 한 번 수행되고 재사용되도록 합니다.
    if (!privateKey) throw new Error("Private key not yet generated.");

    const payload = {
        userId: user.id,
        username: user.username,
        roles: user.roles,
        iat: new Date().toISOString(),
        exp: new Date(Date.now() + 3600 * 1000).toISOString() // 1시간 만료
    };

    // V3.public은 Ed25519로 암호화합니다.
    const token = await V3.sign(payload, privateKey, {
        footer: JSON.stringify({ kid: 'my_public_key_id' }) // 선택적 인증된 푸터
    });
    return token;
}

// 2. 공개 PASETO 토큰 verif y
async function verifyPublicPaseto(token) {
    if (!publicKey_PASETO) throw new Error("Public key not yet generated.");

    try {
        const { payload, footer } = await V3.verify(token, publicKey_PASETO, {
            // 푸터를 verif y하기 위한 선택적 콜백
            callback: (f) => {
                const parsedFooter = JSON.parse(f);
                if (parsedFooter.kid !== 'my_public_key_id') {
                    throw new Error('Invalid key ID in footer');
                }
            }
        });
        return { payload, footer: JSON.parse(footer || '{}') };
    } catch (err) {
        console.error('PASETO verification failed:', err);
        throw new Error('Invalid or expired PASETO token');
    }
}

// 3. 민감한 데이터를 위한 로컬(암호화됨) PASETO 토큰 생성
async function generateLocalPaseto(data) {
    if (!symmetricKey) throw new Error("Symmetric key not yet generated.");

    const token = await V3.encrypt(data, symmetricKey, {
        footer: JSON.stringify({ purpose: 'internal_data' })
    });
    return token;
}

// 4. 로컬 PASETO 토큰 복호화
async function decryptLocalPaseto(token) {
    if (!symmetricKey) throw new Error("Symmetric key not yet generated.");

    try {
        const { payload, footer } = await V3.decrypt(token, symmetricKey);
        return { payload, footer: JSON.parse(footer || '{}') };
    } catch (err) {
        console.error('PASETO decryption failed:', err);
        throw new Error('Invalid or un-decryptable PASETO token');
    }
}

// 예제 사용법
(async () => {
    const user = { id: 2, username: 'bob', roles: ['moderator'] };

    // 키가 생성될 때까지 기다립니다(비동기 작업).
    await new Promise(resolve => setTimeout(resolve, 100)); // 키 생성을 위한 짧은 지연

    const publicToken = await generatePublicPaseto(user);
    console.log('\nGenerated Public PASETO:', publicToken);

    try {
        const { payload: publicPayload } = await verifyPublicPaseto(publicToken);
        console.log('Verified Public PASETO Payload:', publicPayload);
    } catch (e) {
        console.error(e.message);
    }

    const sensitiveInfo = { creditCardLastFour: '1234', secretNote: 'top secret' };
    const localToken = await generateLocalPaseto(sensitiveInfo);
    console.log('\nGenerated Local PASETO:', localToken);

    try {
        const { payload: localPayload } = await decryptLocalPaseto(localToken);
        console.log('Decrypted Local PASETO Payload:', localPayload);
    } catch (e) {
        console.error(e.message);
    }
})();

애플리케이션 시나리오

PASETO는 다음을 위해 적합합니다:

• JWT가 사용되는 모든 시나리오, 그러나 보안 기본값에 대한 강력한 강조가 있습니다.
• 서명되고 선택적으로 암호화되는 토큰이 필요한 애플리케이션.
• 강력한 기밀성이 필요한 토큰에서 민감한 데이터를 처리하는 시스템.
• 암호화 민첩성이 중요한 미래 보장형 시스템 구축.

PASETO의 장단점

장점:

• 설계상 보안: 안전한 알고리즘 및 키 관리 관행을 시행합니다.
• 알고리즘 혼동 없음: "none" 알고리즘 사용을 방지합니다.
• 무결성 및 선택적 기밀성: 서명된 토큰과 암호화된 토큰을 모두 지원합니다.
• 명확한 버전 관리: 암호화 민첩성을 제공합니다.
• 암호화 공격에 대한 내성: 현대적인 보안을 염두에 두고 설계되었습니다.

단점:

• 최신 표준(JWT보다 널리 보급되지 않음): JWT에 비해 라이브러리와 커뮤니티 리소스가 적습니다.
• 복잡성(초기 설정): "local" 토큰의 경우 대칭 키가 필요하므로 키 관리가 약간 더 복잡해 보일 수 있습니다.
• 토큰 무효화: JWT와 마찬가지로 만료 전 무효화는 서버 측 메커니즘이 필요합니다.

데이터베이스 기반 세션

데이터베이스 기반 세션은 세션 관리에 대한 보다 전통적이고 상태 유지적인 접근 방식을 나타냅니다. 여기에서는 서버가 고유한 세션 ID를 생성하고, 이 ID와 연결된 세션 데이터를 데이터베이스(예: SQL, NoSQL, Redis)에 저장하고, 세션 ID를 클라이언트(일반적으로 쿠키)에 보냅니다.

데이터베이스 기반 세션 작동 방식

1. 로그인: 사용자가 자격 증명을 제공합니다.
2. 인증: 서버가 자격 증명을 verif y합니다.
3. 세션 생성: 서버가 고유하고 암호적으로 안전한 세션 ID를 생성합니다.
4. 세션 저장: 서버가 사용자 정보(예: userId, roles, lastActivity)를 세션 ID를 인덱스로 사용하여 데이터베이스에 저장합니다.
5. 쿠키 발급: 서버가 세션 ID를 클라이언트에 다시 보내고, 일반적으로 HttpOnly 및 Secure 쿠키에 담습니다.
6. 후속 요청: 클라이언트가 각 요청과 함께 세션 쿠키를 포함합니다.
7. 세션 조회: 서버가 쿠키에서 세션 ID를 추출하고 데이터베이스를 쿼리하여 세션 데이터를 검색합니다.
8. 인가: 서버가 검색된 세션 데이터를 사용하여 요청된 작업에 대한 사용자를 인가합니다.

구현 예제(Node.js와 Express 및 Redis 저장소 사용 express-session)

const express = require('express');
const session = require('express-session');
const RedisStore = require('connect-redis').default;
const { createClient } = require('redis');

const app = express();
app.use(express.json()); // 요청 본문 파싱용

// 1. Redis 클라이언트 구성
let redisClient = createClient({ legacyMode: true }); // connect-redis용 legacyMode
redisClient.connect().catch(console.error);

// 2. Redis 세션 저장소 구성
let redisStore = new RedisStore({
    client: redisClient,
    prefix: 'myapp:', // Redis에서 세션 키 접두사
});

// 3. Express 세션 미들웨어 구성
app.use(
    session({
        store: redisStore,
        secret: 'a_very_secret_string', // ENV에서 가져온 강력하고 무작위 문자열 사용
        resave: false, // 수정되지 않은 세션 저장 안 함
        saveUninitialized: false, // 무언가 저장될 때까지 세션 생성 안 함
        cookie: {
            secure: process.env.NODE_ENV === 'production', // 프로덕션에서는 secure 쿠키 사용
            httpOnly: true, // 클라이언트 측 JS에서 쿠키 액세스 방지
            maxAge: 1000 * 60 * 60 * 24, // 24시간
            sameSite: 'Lax', // CSRF 방지
        },
    })
);

// 4. 로그인 라우트
app.post('/login', (req, res) => {
    const { username, password } = req.body;
    // 사용자 인증 시뮬레이션
    if (username === 'test' && password === 'password123') {
        req.session.user = { id: 1, username: 'test', roles: ['user'] };
        req.session.isAuthenticated = true;
        req.session.save((err) => { // resave:true가 아니면 수동으로 세션 변경 저장
            if (err) return res.status(500).send('Login failed');
            res.json({ message: 'Logged in successfully', user: req.session.user });
        });
    } else {
        res.status(401).send('Invalid credentials');
    }
});

// 5. 보호된 라우트 미들웨어
function requireAuth(req, res, next) {
    if (req.session.isAuthenticated && req.session.user) {
        next();
    } else {
        res.status(401).send('Unauthorized');
    }
}

app.get('/protected', requireAuth, (req, res) => {
    res.json({ message: `Welcome, ${req.session.user.username}! This is protected data.`, user: req.session.user });
});

// 6. 로그아웃 라우트
app.post('/logout', (req, res) => {
    req.session.destroy((err) => {
        if (err) {
            console.error('Session destruction error:', err);
            return res.status(500).send('Could not log out');
        }
        res.clearCookie('connect.sid'); // 세션 쿠키 지우기
        res.send('Logged out successfully');
    });
});

const PORT = 3000;
app.listen(PORT, () => console.log(`Server running on port ${PORT}`));

애플리케이션 시나리오

데이터베이스 기반 세션은 다음을 위해 적합합니다:

• 전통적인 웹 애플리케이션: 서버 측 렌더링 또는 밀접하게 결합된 모놀리식 서비스가 일반적인 경우.
• 즉각적인 세션 취소가 필요한 애플리케이션: 보안에 민감한 애플리케이션(예: 은행)에 중요합니다.
• 복잡한 세션 데이터가 필요한 애플리케이션: 세션 상태가 동적이며 자주 업데이트되어야 하는 경우.
• "Remember me" 기능과 강력한 무효화가 필요한 시나리오.

데이터베이스 기반 세션의 장단점

장점:

• 손쉬운 세션 취소: 데이터베이스에서 세션을 삭제하여 즉시 무효화할 수 있습니다.
• 중앙 집중식 상태: 모든 세션 데이터가 한 곳에 있어 관리 및 업데이트가 용이합니다.
• 풍부한 세션 데이터: 토큰 크기에 영향을 주지 않고 복잡한 객체와 많은 양의 데이터를 저장할 수 있습니다.
• CSRF 보호: 세션 ID가 HttpOnly 쿠키에 저장되고 CSRF 토큰(요청 본문에 포함)과 함께 사용되면 좋은 CSRF 보호 기능을 제공합니다.

단점:

• 확장성 문제: 수평 확장을 위해 공유 세션 저장소(Redis 또는 Memcached와 같은)가 필요하며, 이는 인프라 복잡성과 지연 시간을 추가합니다.
• 서버 부하 증가: 모든 요청마다 데이터베이스 조회가 필요하므로 트래픽이 많은 경우 병목 현상이 발생할 수 있습니다.
• 단일 장애점: 고가용성이 없는 경우 세션 저장소가 SPOF가 될 수 있습니다.
• 네트워크 오버헤드: 애플리케이션 서버와 세션 저장소 간의 통신입니다.

결론

올바른 세션 관리 전략을 선택하는 것은 애플리케이션 아키텍처, 보안 요구 사항 및 확장성 요구 사항에 따라 크게 달라집니다. JWT와 PASETO는 상태 없는 분산 시스템에 대한 강력한 이점을 제공하여 서버 부하를 줄이고 수평 확장을 단순화하며, PASETO는 향상된 보안 상태를 제공합니다. 그러나 주요 단점은 상태를 다시 도입하지 않고 토큰 무효화를 어렵게 한다는 것입니다. 데이터베이스 기반 세션은 일반적으로 더 상태 유지적이고 리소스 집약적이지만, 즉각적인 세션 취소 및 더 풍부하고 동적인 세션 데이터가 필요한 시나리오에서 탁월하며, 전통적이거나 보안에 매우 민감한 애플리케이션에 대한 확실한 선택이 됩니다. 궁극적으로 최신 JavaScript 웹 애플리케이션의 경우 이러한 트레이드오프를 신중하게 분석하면 강력하고 안전한 세션 관리 솔루션으로 안내될 것입니다.