인증 및 권한 부여

인증은 신원을 확립합니다. 시스템은 사용자가 자신이 주장하는 사람인지 확인합니다. 보통 비밀번호, 토큰, 또는 외부 ID 제공자와 같은 자격 증명을 통해 이루어집니다.

권한 부여는 신원이 확인된 후에 발생합니다. 시스템은 해당 신원이 특정 작업을 수행하거나 특정 리소스에 접근할 권한이 있는지 평가합니다.

이 두 개념은 반드시 분리되어 있어야 합니다. 신원 확인이 자동으로 접근 권한을 의미하지는 않습니다. 로그인한 사용자라도 특정 데이터를 보거나 관리 작업을 수행할 권한이 없을 수 있습니다.

개념적으로: 사용자 → 로그인 → 신원 확인됨 → 권한 검사 → 리소스 접근.

인증이 먼저 발생합니다. 권한 부여는 그 다음에 발생하며, 보통 모든 요청마다 수행됩니다.

인증은 사용자나 시스템이 신원을 주장하고, 그 증거로 자격 증명을 제시할 때 시작됩니다.

Username + Password는 전통적인 방식입니다. 서버는 제출된 자격 증명을 저장된 계정 데이터와 비교합니다.

OAuth Login은 인증을 신뢰할 수 있는 외부 제공자(예: Google 또는 GitHub)에 위임하며, 해당 제공자는 애플리케이션에 검증된 신원을 반환합니다.

API Keys는 주로 서버 간 인증에 사용되며, 사람 사용자가 아니라 애플리케이션을 식별합니다.

**Multi-Factor Authentication (MFA)**은 두 번째 증명(예: 일회용 코드 또는 하드웨어 토큰)을 요구하여 신원 검증을 강화합니다.

개념적 흐름: Login → Credentials Submitted → Server Verifies → Identity Confirmed.

유효한 신원이 없으면 요청은 여기서 중단됩니다.

전통적인 웹 애플리케이션에서는 서버 측 세션을 사용해 인증을 처리합니다.

사용자가 성공적으로 로그인하면 서버는 신원 정보를 포함한 세션 객체를 생성합니다. 이 세션은 서버에 저장되며, 일반적으로 메모리, 데이터베이스 또는 분산 캐시에 보관됩니다.

서버는 세션 ID를 클라이언트에 다시 보내며, 보통 쿠키에 저장됩니다. 이후 요청에서는 브라우저가 자동으로 그 쿠키를 포함합니다.

서버는 세션 ID를 읽고, 해당 세션 데이터를 가져와 사용자의 신원을 확인합니다.

핵심은 간단합니다: 서버가 세션 상태를 저장하고, 클라이언트는 그에 대한 참조만 저장합니다.

현대적인 API와 분산 시스템에서는 인증이 종종 상태 비저장(stateless) 방식으로 동작합니다.

로그인에 성공하면 서버는 신원 정보를 담은 서명된 토큰을 생성합니다. 이 토큰은 클라이언트에 반환됩니다.

이후의 모든 요청에서 클라이언트는 이 토큰을 포함합니다 — 일반적으로 Authorization 헤더에 Bearer 토큰으로 보냅니다.

서버는 서버 측 저장소에서 세션 데이터를 조회하는 대신, 토큰의 서명을 검증하고 그 안에서 사용자 신원을 직접 추출합니다.

세션 기반 인증과의 핵심 차이점은 서버가 각 사용자에 대한 세션 상태를 유지하지 않는다는 점입니다. 신원 검증은 토큰 자체를 검증함으로써 이루어집니다.

이 모델은 공유 세션 저장소 없이도 어떤 서버 인스턴스든 토큰을 검증할 수 있기 때문에 수평 확장을 단순하게 만듭니다.

JWT는 점으로 구분된 3개의 Base64 인코딩 섹션으로 이루어진 구조화된 문자열입니다:

Header → 토큰과 서명 알고리즘에 대한 메타데이터
Payload → 클레임(예: 사용자 ID 또는 역할)
Signature → 토큰이 변경되지 않았다는 암호학적 증명

서버가 JWT를 발급할 때는 비밀 키 또는 개인 키를 사용해 토큰에 서명합니다. 나중에 토큰이 전달되면, 서버는 서명을 검증하여 payload가 수정되지 않았는지 확인합니다.

중요한 점: JWT는 기본적으로 암호화되지 않습니다. payload는 토큰을 가진 누구나 디코딩할 수 있습니다. 서명은 무결성만 보장하며, 기밀성은 보장하지 않습니다.

JWT는 서버 측 세션 저장소가 필요 없이, 검증 가능한 방식으로 신원 정보를 요청과 함께 전달할 수 있게 해주기 때문에 유용합니다.

사용자의 신원이 확인되면, 시스템은 그 사용자가 어떤 작업을 수행할 수 있는지 결정해야 합니다.

권한 부여는 접근 제어 규칙을 강제합니다. 사용자가 인증되었더라도 특정 리소스에 접근하거나 특정 작업을 수행할 권한이 없을 수 있습니다.

대표적인 모델 중 하나는 **Role-Based Access Control (RBAC)**로, 사용자에게 “admin,” “editor,” “viewer”와 같은 역할을 할당하고 각 역할에 미리 정의된 권한을 부여합니다.

또 다른 모델은 **Attribute-Based Access Control (ABAC)**로, 사용자 속성, 리소스 속성, 요청 컨텍스트와 같은 속성을 기반으로 결정을 내립니다.

인증은 일반적으로 세션당 한 번 또는 토큰 발급 시 한 번 발생합니다. 반면 권한 부여는 보호된 모든 요청에서 평가되어 접근 규칙이 일관되게 적용되도록 합니다.

요청이 서버에 도착하면 즉시 애플리케이션 로직이 실행되지 않습니다. 먼저 인증 계층을 통과하며, 이는 보통 Express, Django, FastAPI 같은 프레임워크에서 미들웨어로 구현됩니다.

이 미들웨어는 세션 쿠키나 authorization token 같은 자격 증명을 확인합니다. 자격 증명이 없거나 유효하지 않으면 서버는 401 Unauthorized 응답으로 요청을 거부합니다.

신원이 성공적으로 확인되면, 시스템은 그다음 권한을 평가합니다. 사용자가 요청한 리소스에 접근할 수 없으면 서버는 403 Forbidden을 반환합니다.

인증과 권한 부여 검사를 모두 통과한 후에야 요청이 핸들러에 도달하여 비즈니스 로직을 실행하며, 이를 통해 민감한 작업이 무단 접근으로부터 보호됩니다.

핵심 보호 장치가 빠져 있다면, 올바르게 구현된 인증 흐름도 안전하지 않을 수 있습니다.

비밀번호는 데이터베이스에 저장하기 전에 해시해야 합니다. 해싱은 데이터베이스가 침해되더라도 원본 비밀번호가 노출되지 않도록 보장합니다.

모든 인증 트래픽은 HTTPS를 통해 전송되어야 합니다. 전송 중 암호화가 없으면 자격 증명과 토큰이 공격자에게 가로채질 수 있습니다.

액세스 토큰에는 만료 시간이 있어야 합니다. 수명이 짧은 토큰은 토큰이 탈취되었을 때의 피해를 줄여 줍니다. 많은 시스템은 사용자가 반복해서 로그인하지 않아도 새 액세스 토큰을 얻기 위해 리프레시 토큰을 사용합니다.

보안은 단순히 신원을 확인하는 것만이 아니라, 신원을 확인하는 메커니즘을 보호하는 것입니다.