인증과 권한 관리 기초

이번 절에서는 인증(Authentication)과 권한 부여(Authorization)를 다룹니다.

대부분의 웹 애플리케이션은 로그인 기반 개인화와 역할별 기능 제한이 필요하며, 이 과정에서 인증/권한 관리는 웹 보안의 핵심이 됩니다.

이번 장에서는 인증과 권한 부여 개념을 구분하고, 세션 기반/토큰 기반 인증 방식과 권한 관리 기본 원칙을 정리합니다.

인증 vs 권한 부여

이 두 용어는 자주 혼용되지만, 웹 보안에서는 명확히 다른 의미를 가집니다.

• 인증 (Authentication)
  • 누구인지 확인하는 과정입니다. 사용자에게 너는 누구냐?라고 물었을 때, 사용자가 본인임을 증명하는 과정입니다.
  • 사용자가 주장하는 신원(ID)이 실제와 일치하는지 확인하는 프로세스입니다.
  • 예시: 사용자 ID와 비밀번호를 입력하여 로그인하는 것, 지문 인식, OTP(일회용 비밀번호) 입력 등.
• 권한 부여 (Authorization)
  • 무엇을 할 수 있는지 결정하는 과정입니다. 너는 무엇을 할 수 있느냐?라는 질문에 대해, 사용자에게 허용된 작업이 무엇인지 확인하는 과정입니다.
  • 인증된 사용자에게 특정 자원(데이터, 기능)에 대한 접근 권한을 부여하거나 거부하는 프로세스입니다.
  • 예시: 로그인한 사용자가 자신의 프로필을 수정할 수 있는지, 관리자만 특정 게시물을 삭제할 수 있는지, 유료 구독자만 프리미엄 콘텐츠를 볼 수 있는지 등.

요약: 인증은 신원 확인이고, 권한 부여는 허가된 작업의 범위 결정입니다.

이 절의 보호 API는 인증으로 신원을 확인한 뒤 권한을 검사합니다.

공개 자원처럼 익명 사용자에게 허용된 접근도 있으므로, 모든 인가 정책에 로그인이 필요한 것은 아닙니다.

사용자 인증 구현 방식

웹 애플리케이션에서 사용자를 인증하는 대표적인 두 가지 방식이 있습니다.

세션 기반 인증

세션 기반 인증 (Session-based Authentication)은 전통적인 웹 애플리케이션에서 널리 사용되던 방식입니다.

• 동작 방식

  사용자가 ID와 비밀번호로 로그인 요청을 보냅니다.

  서버는 사용자의 신원을 확인한 후, 고유한 세션 ID(Session ID)를 생성합니다.

  이 세션 ID는 서버의 메모리나 데이터베이스에 저장되고, 사용자에게는 이 세션 ID를 포함하는 쿠키(Cookie)를 응답으로 보냅니다.

  클라이언트(브라우저)는 이 쿠키를 저장하고, 도메인·경로·Secure·SameSite와 요청의 credentials 조건을 충족하는 요청에 쿠키를 보냅니다.

  서버는 요청에 포함된 세션 ID를 확인하여, 서버에 저장된 세션 정보와 일치하는지 검증합니다.

  일치하면 해당 사용자가 로그인된 것으로 간주하고 요청을 처리합니다.

  로그아웃 시 서버에서 세션 정보를 삭제합니다.

• 장점
  • 보안성: 사용자 정보는 서버에 보관하지만, 유효한 세션 ID는 로그인 권한에 연결되는 비밀입니다. ID가 탈취되면 세션을 악용할 수 있으므로 보호와 만료·폐기 관리가 필요합니다.
  • 세션 관리의 용이성 (서버에서 세션 만료, 강제 로그아웃 등 제어).
• 단점
  • 확장성 (Scalability): 서버에서 세션 상태를 유지해야 하므로, 여러 대의 서버(로드 밸런싱)를 사용하는 경우 모든 서버가 세션 정보를 공유해야 하는 복잡성이 발생합니다 (Sticky Session 또는 Redis와 같은 외부 세션 저장소 필요).
  • CORS (Cross-Origin Resource Sharing) 문제: 다른 도메인 간의 요청 시 쿠키가 전송되지 않거나 보안 제약이 있어 복잡해질 수 있습니다.
  • 모바일 앱 대응 어려움: 모바일 앱에서는 웹 쿠키를 직접 관리하기 어렵습니다.

토큰 기반 인증

토큰 기반 인증 (Token-based Authentication)은 SPA, 모바일 앱, 마이크로서비스 등에서 사용하는 선택지입니다. 앱의 종류만으로 사용 비율이나 적합성을 단정하지 않고 수명·폐기·검증 정책을 비교합니다.

특히 JWT (JSON Web Token)가 대표적입니다.

• 동작 방식

  사용자가 ID와 비밀번호로 로그인 요청을 보냅니다.

  서버는 사용자의 신원을 확인한 후, 사용자 정보(payload)를 담고 서버의 비밀 키로 서명(signature)한 토큰(Token)을 생성합니다.

  (예: JWT)

  이 토큰을 클라이언트에게 응답으로 보냅니다.

  자체 포함 토큰은 매번 세션 레코드를 조회하지 않고 검증할 수 있습니다. refresh 회전이나 폐기 목록에는 서버 상태가 필요할 수 있습니다.

  클라이언트(브라우저/앱)는 이 토큰을 로컬 스토리지, 세션 스토리지 또는 쿠키(보안을 위해 HttpOnly 쿠키 권장)에 저장합니다.

  헤더 방식은 JavaScript가 읽을 수 있는 토큰을 필요한 요청의 Authorization에 넣습니다. HttpOnly 쿠키 방식은 JavaScript로 읽지 않고 브라우저가 쿠키로 전송하므로 별도의 CSRF·쿠키 정책이 필요합니다.

  (예: Authorization: Bearer <token>)

  서버는 요청에 포함된 토큰의 유효성(서명 검증, 만료 시간 확인 등)을 검증합니다.

  토큰이 유효하면 해당 사용자의 권한을 확인하고 요청을 처리합니다.

• JWT (JSON Web Token): 토큰 기반 인증의 표준 중 하나.

  • 이 절에서 비교하는 서명된 JWS 방식은 세 부분으로 구성: Header.Payload.Signature. 암호화한 JWE 표현까지 모두 세 부분이라고 일반화하지 않습니다.
  • Header: 토큰 타입(JWT), 서명 알고리즘(HMAC SHA256 등)
  • Payload: 사용자 ID, 만료 시간 등 실제 정보(클레임)
  • Signature: JWS 방식 JWT는 인코딩한 Header와 Payload에 MAC 또는 디지털 서명을 적용해 무결성을 검증합니다. 서명만으로 Payload가 암호화되지는 않습니다.
• 장점
  • 확장성 (Scalability): 자체 포함 토큰은 매번 세션 레코드를 조회하지 않고 검증할 수 있어 여러 서버에서 사용할 수 있습니다. 검증 키·수명·정책을 공유해야 하며 refresh·폐기에는 서버 상태가 필요할 수 있습니다.
  • 교차 출처 요청: Authorization 헤더를 사용해도 브라우저의 CORS 검사를 받습니다. 서버의 Origin·헤더 허용과 preflight 처리가 필요합니다.
  • 모바일 앱 친화적: 모바일 앱에서도 쉽게 토큰을 저장하고 전송할 수 있습니다.
  • 분리된 프론트엔드/백엔드: 프론트엔드와 백엔드가 완전히 분리되어 개발될 때 이상적입니다.
• 단점
  • 토큰 탈취 위험: 토큰이 클라이언트 측에 저장되므로 XSS 공격 등으로 토큰이 탈취될 경우 보안에 취약해질 수 있습니다. (Local Storage보다는 HttpOnly 쿠키에 저장하는 것이 더 안전함)
  • 토큰 무효화 어려움: 서명만 독립적으로 검증하는 토큰은 별도 폐기 검사 없이 발급 때의 수명까지 받아들일 수 있으므로, 즉시 무효화가 필요하면 추가 정책을 설계합니다 (블랙리스트 관리 또는 짧은 만료 시간 + Refresh Token 사용).
  • 페이로드 크기: 페이로드에 많은 정보를 담으면 토큰의 크기가 커져 네트워크 트래픽에 영향을 줄 수 있습니다.

세션 vs. 토큰 요약

세션과 JWT는 앱 종류만으로 결정하지 않고 검증, 폐기, 저장·전송 방식과 운영 요구를 함께 비교합니다.

권한 부여 구현 방식

인증된 사용자가 특정 자원에 접근하거나 특정 작업을 수행할 수 있는지 확인하는 과정입니다.

역할 기반 접근 제어

역할 기반 접근 제어 (RBAC: Role-Based Access Control)은 가장 흔하게 사용되는 권한 부여 방식입니다.

• 개념: 사용자에게 역할(Role)을 부여하고, 각 역할에 특정 권한(Permission)을 할당합니다. 사용자가 접근할 수 있는 자원이나 수행할 수 있는 작업은 그 사용자의 역할에 따라 결정됩니다.
• 예시
  • 역할: 관리자(Admin), 일반 사용자(User), 게스트(Guest)
  • 권한: 게시물 생성, 게시물 수정, 게시물 삭제, 사용자 관리
  • Admin 역할은 모든 권한을 가짐.
  • User 역할은 게시물 생성, 게시물 수정 권한을 가짐.
  • Guest 역할은 게시물 조회 권한만 가짐.
• 구현 방법
  • 데이터베이스: users 테이블, roles 테이블, permissions 테이블, 그리고 이들을 연결하는 중간 테이블(예: user_roles, role_permissions)을 생성하여 관계를 정의합니다.
  • 백엔드 로직: API 엔드포인트에 접근할 때, 요청을 보낸 사용자의 역할을 확인하고, 해당 역할이 요청된 작업에 대한 권한을 가지고 있는지 검사합니다.
    • 예: DELETE /api/posts/:id 엔드포인트에 접근하는 사용자가 Admin 역할인지 확인.
    • Express.js에서는 미들웨어(Middleware)를 사용하여 특정 라우트에 접근하기 전에 권한을 검사하는 로직을 구현할 수 있습니다.

// 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 검증의 알고리즘·발급자·대상 원칙과 만료 클레임의 의미를 설정에 연결해야 합니다. 또한 여기서는 req.user.role만 비교하므로 게시물의 소유자를 검사하는 인가 정책은 추가로 필요합니다.

① 헤더가 없는 요청, ② 검증 콜백이 오류를 반환하는 토큰, ③ 유효한 user의 관리자 화면 요청, ④ 유효한 admin의 게시물 생성 요청이 어디서 끝나는지와 상태를 써 보세요. ⑤ 헤더를 Basic good-user-token으로 바꿨는데 이 간략 코드의 검증 함수가 두 번째 값을 유효한 토큰으로 판정했다면, 스킴 오류를 이 코드가 스스로 잡을까요?

속성 기반 접근 제어

속성 기반 접근 제어 (ABAC: Attribute-Based Access Control)은 RBAC보다 더 유연하고 세밀한 권한 부여 방식입니다.

• 개념: 사용자, 자원, 환경 등 다양한 속성(Attribute)을 조합하여 접근 결정을 내립니다.
• 예시: 오전 9시부터 오후 5시 사이에만 접근 가능한 A 부서의 팀장이 작성한 문서, IP 주소가 특정 범위 내에 있을 경우만 접근 가능한 파일 등.
• 장점: 매우 유연하고 세밀한 제어 가능.
• 단점: 구현 및 관리가 복잡하여 대규모 엔터프라이즈 환경에서 주로 사용됩니다.

비밀번호 보안 (다시 강조)

인증의 가장 기본적인 요소인 비밀번호 보안은 아무리 강조해도 지나치지 않습니다.

• 해싱(Hashing): 비밀번호를 데이터베이스에 저장하기 전에 솔트와 계산 비용을 갖춘 비밀번호 전용 해시(예: bcrypt, scrypt)를 사용합니다. 신규 시스템의 Argon2id 우선 검토, scrypt 대안, 기존 bcrypt 호환 요구를 앞 절의 선택 원칙과 함께 확인합니다.
  • 솔트(Salt): 각 비밀번호마다 고유한 랜덤 값인 솔트를 추가하여 해싱합니다. 이를 통해 동일한 비밀번호라도 다른 해시 값을 가지게 하여 레인보우 테이블 공격 등을 방어할 수 있습니다.
  • 반복 횟수 증가: 해시 함수를 여러 번 반복하여 계산 시간을 늘려 무작위 대입 공격(Brute-force attack)을 어렵게 만듭니다.
• 비밀번호 정책: 충분한 길이, 유출·흔한 비밀번호 차단 목록과 비밀번호 관리자 지원을 적용합니다. 임의의 문자 조합은 강제하지 않습니다.
• 재사용 금지: 이전에 사용했던 비밀번호 재사용 금지.
• 유출 시 변경: 정기 변경을 강제하지 않고 유출 근거가 있을 때 변경과 세션 폐기를 요구합니다.

인증·권한 부여 정리

정리 구간에서는 인증(신원 확인)과 권한 부여(행위 허용)를 분리해 설계하는 기준을 다시 확인합니다.

실제 API 요청에서는 인증 실패와 권한 부족을 다른 단계로 처리해야 응답 코드와 보안 로그가 선명해집니다.

이번 장에서는 웹 애플리케이션의 사용자 관리에서 가장 중요한 두 가지 개념인 인증(Authentication)과 권한 부여(Authorization)의 기초를 학습했습니다.

이번 절에서는 인증과 권한 부여의 차이, 세션 기반 인증과 토큰 기반 인증의 동작 방식, RBAC의 기본 구조를 정리했습니다.

Express.js 미들웨어 예시를 통해 접근 권한을 요청 처리 흐름에 연결하는 방식도 확인했습니다.

안전한 웹 서비스에서는 인증 방식, 권한 정책, 비밀번호 저장 방식, 세션 또는 토큰 수명 정책을 함께 관리해야 합니다.