인증과 권한 관리 기초

앞 글 웹 보안 기초 (HTTPS, XSS, CSRF)에서는 요청이 지나가는 구간마다 방어를 겹쳐 두는 방법을 살펴봤습니다. 그 가운데 서버에서 꼭 해야 하는 일이 인증(authentication)과 인가(authorization, 권한 부여라고도 합니다)입니다. 대부분의 웹 애플리케이션은 로그인한 사용자에게 맞춘 화면을 보여 주고, 역할에 따라 쓸 수 있는 기능을 제한해야 하므로, 인증과 권한 관리는 웹 보안의 핵심입니다.

이 글에서는 인증과 인가를 구별하고, 세션 기반 인증과 토큰 기반 인증이 어떻게 동작하는지, 역할과 속성으로 권한을 관리하는 기본 원칙은 무엇인지 정리합니다.

인증과 권한 부여

두 용어는 자주 섞어 쓰이지만 뜻이 분명히 다릅니다. 인증은 누구인지 확인하는 과정으로, 사용자가 주장하는 신원이 실제와 맞는지 검증합니다. 아이디와 비밀번호로 로그인하거나, 지문을 인식하거나, 일회용 비밀번호(OTP)를 입력하는 것이 인증입니다.

인가는 무엇을 할 수 있는지 정하는 과정으로, 인증된 사용자가 특정 데이터나 기능에 접근해도 되는지를 판단해 허락하거나 거부합니다. 로그인한 사용자가 자기 프로필을 고칠 수 있는지, 관리자만 게시물을 지울 수 있는지, 유료 구독자만 프리미엄 콘텐츠를 볼 수 있는지를 판단하는 것이 인가입니다. 줄여서 인증은 신원 확인이고, 인가는 허락된 작업의 범위를 정하는 일입니다.

이 글의 보호된 API는 인증으로 신원을 확인한 뒤 권한을 검사합니다. 다만 공개된 글처럼 로그인하지 않은 사용자에게도 허락하는 접근이 있으므로, 모든 권한 정책에 로그인이 필요한 것은 아닙니다.

위 그림은 보호된 API로 들어온 요청이 두 단계의 검사를 거치는 모습입니다. 먼저 인증 단계에서 세션이나 토큰 같은 자격 증명이 유효한지 확인합니다. 자격 증명이 없거나 유효하지 않으면 401로 응답하고 작업을 멈춥니다. 유효하면 인가 단계로 넘어가, 이 사용자가 요청한 작업을 해도 되는지 역할뿐 아니라 대상과 소유 관계까지 확인합니다. 권한이 없으면 403으로 거부하고, 허락되면 핸들러가 업무를 처리합니다.

그림은 이 글의 Express 미들웨어 예제를 그대로 옮긴 것으로, authenticateToken, authorizeRoles, 핸들러의 순서로 실행됩니다. 관리자 화면(admin-dashboard)은 admin 역할만, 게시물 생성은 admin이나 user 역할을 허락합니다. 두 검사를 통과해도 입력이나 업무 규칙의 검증에서 실패할 수 있으므로, 성공 응답이 항상 보장되는 것은 아닙니다. 예제 코드는 Bearer 형식의 확인, 토큰 검증의 세부 옵션, 대상의 소유자 확인을 생략했습니다.

그림 아래의 설명처럼 401은 유효한 인증 자격 증명이 필요하다는 뜻이며, 어떤 방식으로 인증해야 하는지 알려 주는 WWW-Authenticate 헤더를 함께 보냅니다. 403은 서버가 이 요청을 처리하지 않겠다는 뜻입니다. 공개 자원은 로그인 없이 허락할 수 있고, 민감한 대상이 있는지조차 숨기려고 403 대신 404를 돌려주는 정책은 따로 정합니다.

사용자 인증 방식

웹 애플리케이션이 사용자를 인증하는 대표적인 방식은 세션 기반 인증과 토큰 기반 인증입니다. 두 방식 모두 로그인할 때 한 번 신원을 확인하고, 그 뒤의 요청마다 이미 확인된 사용자라는 표시를 함께 보냅니다. 차이는 그 상태를 서버가 기록해 두느냐, 서명한 토큰에 담아 클라이언트가 들고 다니느냐에 있습니다. 아래에서 두 방식을 차례로 보고 비교합니다.

세션 기반 인증

세션 기반 인증(session-based authentication)은 전통적인 웹 애플리케이션에서 널리 쓰여 온 방식입니다. 사용자가 아이디와 비밀번호로 로그인하면, 서버는 신원을 확인한 뒤 예측하기 어려운 세션 ID를 만들어 서버의 메모리나 데이터베이스에 사용자 정보와 함께 저장하고, 그 세션 ID를 담은 쿠키를 응답으로 보냅니다. 브라우저는 이 쿠키를 저장해 두었다가, 도메인과 경로, Secure와 SameSite 속성, 요청의 자격 증명(credentials) 조건에 맞는 요청마다 함께 보냅니다. 서버는 요청에 담긴 세션 ID를 저장된 세션과 비교해 일치하면 로그인한 사용자로 보고 요청을 처리하며, 로그아웃하면 서버의 세션 정보를 지웁니다.

세션 방식은 사용자 정보를 서버에 두고, 세션의 만료나 강제 로그아웃을 서버가 직접 제어할 수 있습니다. 다만 유효한 세션 ID는 로그인 상태에 연결된 비밀이라서, 탈취되면 그 세션을 악용할 수 있으므로 잘 보호하고 만료와 폐기를 관리해야 합니다.

단점도 있습니다. 서버가 세션 상태를 유지하므로, 여러 서버에 요청을 나눠 보낸다면 모든 서버가 세션을 함께 볼 수 있도록 Redis 같은 공유 저장소를 쓰거나, 한 사용자의 요청을 같은 서버로 보내는(sticky session) 설정이 필요합니다. 다른 출처 사이의 요청에서는 쿠키가 전송되지 않거나 추가 설정이 필요해 복잡해질 수 있고, 모바일 앱에서는 웹 쿠키를 직접 다루기 어렵습니다.

더 깊이: 세션 쿠키 이름에 붙이는 __Host- 접두사

세션 ID를 담은 쿠키는 HttpOnly, Secure, SameSite 속성만으로는 막기 어려운 공격이 하나 남습니다. 같은 도메인의 다른 하위 도메인이나 HTTP로 열린 페이지가 같은 이름의 쿠키를 먼저 심거나 덮어써, 공격자가 아는 세션 ID를 피해자의 브라우저에 넣는 것입니다. 쿠키 이름의 접두사(cookie prefix)는 이런 덮어쓰기를 브라우저가 거부하게 하는 장치입니다.

이름이 __Secure-로 시작하는 쿠키는 HTTPS 페이지에서 Secure 속성과 함께 설정해야 받아들여집니다. __Host-는 더 엄격해서, 여기에 더해 Domain 속성이 없어야 하고 Path가 /여야 합니다. 그래서 Set-Cookie: __Host-session=값; Secure; HttpOnly; Path=/로 만든 쿠키는 그 쿠키를 설정한 호스트에만 전송되고, 하위 도메인이나 다른 경로에서 같은 이름으로 덮어쓸 수 없습니다. MDN은 이 조합을 출처를 보안의 단위로 다루는 데 가장 가까운 쿠키라고 설명합니다.

조건을 하나라도 어기면 브라우저는 쿠키를 저장하지 않습니다. 예를 들어 Path=/가 빠지거나 Domain=example.com을 적은 __Host- 쿠키는 거부됩니다. 다만 접두사를 지원하지 않는 브라우저에서는 이 확인이 이루어지지 않고 그냥 일반 쿠키로 받아들여지므로, 접두사는 다른 속성을 대신하지 않고 그 위에 더하는 장치입니다. 규칙은 MDN의 Set-Cookie 설명의 쿠키 접두사 항목에 있습니다.

토큰 기반 인증

토큰 기반 인증(token-based authentication)은 SPA, 모바일 앱, 마이크로서비스 등에서 쓰는 방식이며, 대표적인 형식이 JWT(JSON Web Token)입니다. 앱의 종류만으로 어느 방식이 맞는지 정하지 말고, 토큰의 수명과 폐기, 검증 규칙을 비교해 고릅니다.

사용자가 로그인하면 서버는 신원을 확인한 뒤 사용자 ID 같은 정보(payload)를 담고 서버의 키로 서명(signature)한 토큰을 만들어 응답으로 보냅니다. 이런 자체 포함(self-contained) 토큰은 요청마다 세션 기록을 조회하지 않고도 서명을 검증해 확인할 수 있습니다. 클라이언트는 토큰을 저장해 두었다가 요청에 담아 보내는데, 자바스크립트가 읽을 수 있는 곳에 저장해 Authorization: Bearer <token> 헤더에 넣는 방식과, HttpOnly 쿠키에 담아 브라우저가 쿠키로 보내게 하는 방식이 있습니다. 쿠키 방식은 자바스크립트로 토큰을 읽지 않는 대신 CSRF와 쿠키 정책을 따로 챙겨야 합니다. 서버는 받은 토큰의 서명과 만료 시간 등을 검증하고, 유효하면 권한을 확인해 요청을 처리합니다.

이 글에서 다루는 서명된 JWT(JWS 형식)는 Header.Payload.Signature의 세 부분으로 이루어집니다. 헤더에는 토큰의 종류와 서명 알고리즘이, 페이로드에는 사용자 ID와 만료 시간 같은 정보인 클레임(claim)이 들어 있고, 서명은 인코딩한 헤더와 페이로드에 MAC이나 전자 서명을 적용해 내용이 바뀌지 않았는지 검증하게 해 줍니다. 서명은 내용을 감추는 암호화가 아니므로, 페이로드는 누구나 디코딩해 읽을 수 있습니다. 암호화한 JWT(JWE 형식)는 구성이 다르므로 모든 JWT가 세 부분이라고 생각하지는 않습니다.

토큰 방식은 여러 서버가 검증 키만 공유하면 세션 기록 없이 토큰을 검증할 수 있고, 모바일 앱에서도 저장하고 보내기 쉬우며, 프런트엔드와 백엔드가 완전히 나뉜 구조에 잘 맞습니다. Authorization 헤더를 쓰더라도 다른 출처로 보내는 요청은 브라우저의 CORS 검사를 받으므로, 서버가 출처와 헤더를 허락하고 사전 요청(preflight)을 처리해야 합니다.

단점은 토큰이 클라이언트에 있다는 점입니다. 자바스크립트가 읽을 수 있는 곳에 둔 토큰은 XSS 공격으로 탈취될 수 있습니다. 서명만 검증하는 토큰은 따로 폐기를 검사하지 않으면 발급할 때 정한 만료 시간까지 계속 유효하므로, 즉시 무효화해야 한다면 폐기 목록을 두거나, 수명을 짧게 하고 새 토큰을 받는 데 쓰는 리프레시 토큰(refresh token)을 함께 설계해야 합니다. 이런 리프레시와 폐기에는 결국 서버의 상태가 필요할 수 있습니다. 페이로드에 많은 정보를 담으면 토큰이 커져 모든 요청이 무거워지는 점도 주의합니다.

세션과 토큰 비교

위 그림은 같은 로그인 뒤에도 두 방식의 수명이 어떻게 다른지 나란히 비교합니다. 위쪽의 서버 세션은 로그인을 검증한 뒤 예측하기 어려운 세션 ID를 만들어 서버의 사용자 상태와 연결하고, 보통 Secure, HttpOnly, SameSite 속성을 붙인 쿠키로 보냅니다. 요청이 오면 서버가 세션 기록과 만료, 폐기 상태를 조회하며, 로그인하거나 권한이 바뀔 때는 세션 ID를 새로 발급해 공격자가 미리 정해 둔 ID를 쓰게 하는 세션 고정(session fixation) 공격을 막습니다. 로그아웃하면 서버의 기록을 무효로 하고 쿠키도 지우며, 사용하지 않은 시간과 최대 수명의 정책을 적용합니다.

아래쪽의 서명된 JWT는 로그인을 검증한 뒤 필요한 클레임과 만료 시간을 담아 서명하고, 필요하면 리프레시 토큰을 따로 발급합니다. 토큰은 Authorization 헤더나 쿠키 가운데 하나로 보내는데, HttpOnly 쿠키는 자바스크립트로 읽어 헤더에 넣을 수 없고 브라우저가 쿠키로 보냅니다. 요청이 오면 허락한 알고리즘인지, 서명과 만료 시간, 발급자(issuer)와 대상(audience)이 맞는지 검증한 뒤 권한을 확인하며, 리프레시 토큰을 쓴다면 새로 바꿔 주는 회전(rotation)과 재사용 탐지 규칙도 정합니다. 로그아웃할 때 클라이언트에서 토큰을 지워도 이미 발급된 토큰은 바로 무효가 되지 않으므로, 짧은 만료 시간과 폐기 목록, 리프레시 토큰 폐기를 함께 검토합니다.

그림 아래의 설명은 두 가지를 짚습니다. 쿠키로 보내면 CSRF 정책을, 자바스크립트가 읽을 수 있는 저장소와 헤더로 보내면 XSS와 토큰 탈취 위험을 검토해야 하며, HttpOnly도 XSS 스크립트가 사용자 대신 요청을 보내는 것까지 막지는 못합니다. 또 세션도 공유 저장소로 여러 서버가 쓸 수 있고, JWT도 리프레시 회전이나 즉시 폐기를 관리하려면 서버의 상태가 필요할 수 있습니다. 서명은 내용을 감추는 암호화가 아니며, 토큰을 쿠키에 담아 보낼 수도 있으므로 쿠키와 토큰은 서로 반대되는 개념이 아닙니다.

세션과 JWT는 앱의 종류만으로 고르지 말고, 검증과 폐기, 저장과 전송 방식, 운영에서 필요한 것을 함께 비교해 고릅니다.

권한 부여 방식

인가는 인증된 사용자가 특정 자원에 접근하거나 작업을 할 수 있는지 확인하는 과정입니다. 인증이 누구인지를 확인한다면, 인가는 그 사용자가 이 일을 해도 되는지를 정합니다. 그래서 권한 검사는 인증이 끝난 뒤, 요청이 자원에 닿기 전에 서버에서 해야 합니다. 아래에서는 역할로 권한을 묶는 방식과 여러 속성을 조합하는 방식을 봅니다.

역할 기반 접근 제어

역할 기반 접근 제어(role-based access control, RBAC)는 가장 흔한 인가 방식입니다. 사용자에게 역할(role)을 주고, 역할마다 권한(permission)을 연결해, 사용자가 할 수 있는 일을 역할로 정합니다. 예를 들어 Admin은 게시물 생성, 수정, 삭제, 사용자 관리를 모두 할 수 있고, User는 게시물 생성과 수정을, Guest는 게시물 조회만 할 수 있게 정합니다.

데이터베이스에는 users, roles, permissions 테이블과 이를 잇는 user_roles, role_permissions 같은 중간 테이블을 만들어 관계를 정의합니다. 백엔드에서는 API 엔드포인트에 요청이 오면 그 사용자의 역할이 요청한 작업의 권한을 가졌는지 검사하며, Express에서는 라우트 앞에 권한을 검사하는 미들웨어를 두어 구현합니다.

// app.js 또는 routes/auth.js

// 인증 미들웨어 (JWT 토큰 검증 후 req.user에 사용자 정보 추가)
const authenticateToken = (req, res, next) => {
    const authHeader = req.headers['authorization'];
    const token = authHeader && authHeader.split(' ')[1]; // Bearer token

    if (token == null) return res.set('WWW-Authenticate', 'Bearer').sendStatus(401); // 토큰 없음

    jwt.verify(token, process.env.ACCESS_TOKEN_SECRET, (err, user) => {
        if (err) return res.set('WWW-Authenticate', 'Bearer').sendStatus(401); // 유효하지 않은 토큰
        req.user = user; // req.user에 사용자 정보(id, role 등) 저장
        next();
    });
};

// 권한 부여 미들웨어 (특정 역할만 허용)
const authorizeRoles = (roles) => {
    return (req, res, next) => {
        if (!req.user || !roles.includes(req.user.role)) {
            return res.status(403).json({ message: 'Forbidden: You do not have the required role.' });
        }
        next();
    };
};

// 라우트에 미들웨어 적용
app.get('/api/admin-dashboard', authenticateToken, authorizeRoles(['admin']), (req, res) => {
    res.json({ message: 'Welcome to admin dashboard!', user: req.user });
});

app.post('/api/posts', authenticateToken, authorizeRoles(['admin', 'user']), (req, res) => {
    // 게시물 생성 로직
    res.status(201).json({ message: 'Post created.' });
});

검증 함수가 유효한 토큰에서 { id: 7, role: 'user' }를 꺼냈다고 가정해 봅니다. authenticateToken은 이 값을 req.user에 넣고 다음 미들웨어로 넘깁니다. 하지만 authorizeRoles(['admin'])의 목록에 user가 없으므로 관리자 화면 요청은 403으로 끝납니다. 같은 사용자가 게시물을 만들면 ['admin', 'user']를 통과해 핸들러가 201을 보냅니다. 로그인에 성공한 것과 모든 작업이 허락된 것은 서로 다른 판단입니다.

이 코드는 흐름을 보여 주는 간단한 예시라서 jwt와 app의 준비, 토큰 발급, 실제 검증 키와 비밀 관리, 만료와 허락할 알고리즘, 발급자와 대상 같은 검증 규칙을 생략했습니다. authHeader.split(' ')[1]은 앞부분이 Bearer인지나 헤더 전체의 형식을 검사하지 않으므로, 운영 코드로 그대로 옮기면 안 됩니다. 실제로는 JWT 검증 모범 사례(RFC 8725)에 따라 알고리즘과 발급자, 대상을 확인하고, 만료 클레임(exp)의 의미를 설정에 반영해야 합니다. 또 이 코드는 req.user.role만 비교하므로, 게시물을 쓴 사람만 고칠 수 있게 하는 소유자 검사는 따로 필요합니다.

속성 기반 접근 제어

속성 기반 접근 제어(attribute-based access control, ABAC)는 RBAC보다 더 유연하고 세밀한 방식으로, 사용자와 자원, 환경의 여러 속성을 조합해 접근을 결정합니다. “오전 9시부터 오후 5시 사이에만, A 부서의 팀장이 쓴 문서에 접근할 수 있다”거나 “IP 주소가 특정 범위 안일 때만 파일에 접근할 수 있다” 같은 규칙이 예입니다. 아주 세밀하게 제어할 수 있지만 구현하고 관리하기 복잡해서, 주로 규모가 큰 기업 환경에서 씁니다.

비밀번호 보안 다시 보기

인증의 가장 기본이 되는 비밀번호는 앞 글에서 본 원칙을 지켜 저장합니다. 데이터베이스에 저장하기 전에 솔트와 계산 비용을 갖춘 비밀번호 전용 해시를 쓰고, 새 시스템이라면 Argon2id를 먼저 검토하며, 쓸 수 없다면 scrypt 같은 대안을, 기존 시스템과의 호환이 필요하면 bcrypt를 고려합니다.

솔트(salt)는 비밀번호마다 다르게 붙이는 무작위 값으로, 같은 비밀번호라도 다른 해시가 나오게 해 미리 계산해 둔 해시 표로 거꾸로 찾는 레인보우 테이블(rainbow table) 공격을 막습니다. 계산 비용을 높이면 해시를 한 번 계산하는 데 시간이 더 걸려, 무차별 대입 공격으로 많은 비밀번호를 시험하기 어려워집니다.

비밀번호 규칙은 충분한 길이를 요구하고, 유출되었거나 흔한 비밀번호를 막으며, 비밀번호 관리자를 쓸 수 있게 합니다. 특수 문자를 억지로 섞게 하거나 주기적으로 바꾸게 하지 말고, 유출된 정황이 있을 때 바꾸게 하며 그 사용자의 세션도 함께 폐기합니다.

정리

• 인증은 누구인지 확인하는 일이고, 인가는 그 사용자가 무엇을 할 수 있는지 정하는 일입니다.
• 보호된 API는 자격 증명이 없거나 유효하지 않으면 401과 WWW-Authenticate로, 인증되었지만 권한이 없으면 403으로 응답합니다.
• 세션 방식은 서버가 세션 상태를 보관하고 만료와 폐기를 직접 제어하며, 로그인할 때 세션 ID를 새로 발급해 세션 고정을 막습니다.
• 서명된 JWT는 세션 기록 없이 검증할 수 있지만, 서명은 암호화가 아니고 로그아웃해도 바로 무효가 되지 않으므로 짧은 수명과 폐기를 설계합니다.
• 토큰을 쿠키로 보내면 CSRF를, 자바스크립트가 읽을 수 있게 두면 XSS와 탈취 위험을 검토해야 합니다.
• RBAC는 역할로, ABAC는 여러 속성으로 권한을 정하며, 역할 검사와 별개로 대상의 소유자 검사가 필요할 수 있습니다.

연습 문제

1. 미들웨어 순서 따라가기

예제 코드에서 ① 헤더가 없는 요청, ② 검증 함수가 오류를 돌려주는 토큰, ③ 유효한 user의 관리자 화면 요청, ④ 유효한 admin의 게시물 생성 요청이 각각 어디서 끝나고 어떤 상태 코드를 받는지 적어 보세요. ⑤ 헤더를 Basic good-user-token으로 바꿨는데, 검증 함수가 두 번째 값을 유효한 토큰으로 판정했다면 이 코드가 형식 오류를 스스로 잡을까요?

2. 페이로드에 담아도 될까

어떤 개발자가 JWT에 서명이 있으니 안전하다며, 페이로드에 사용자의 전화번호와 주소를 넣으려 합니다. 이 판단은 맞을까요?

3. 남의 게시물 수정

PUT /api/posts/5에 authenticateToken과 authorizeRoles(['admin', 'user'])를 붙였습니다. 5번 게시물은 사용자 3이 썼는데, 사용자 7(role: 'user')이 수정 요청을 보냈습니다. 이 요청은 어떻게 처리될까요? 어떻게 고쳐야 할까요?

다음 글 웹 성능 최적화 기본 원칙에서는 페이지를 빠르게 만드는 기본 원칙과, 측정을 바탕으로 개선할 곳을 찾는 방법을 살펴봅니다.