2025년 4월 19일·7분
현대 프레임워크가 인증과 인가를 다루는 방식
세션, 토큰, OAuth/OIDC, 미들웨어, 역할, 정책 등 현대 프레임워크가 인증과 인가를 구현하는 방법과 주요 보안 함정을 알아봅니다.
세션, 토큰, OAuth/OIDC, 미들웨어, 역할, 정책 등 현대 프레임워크가 인증과 인가를 구현하는 방법과 주요 보안 함정을 알아봅니다.
인증은 “당신은 누구인가?”에 답합니다. 인가는 “무엇을 할 수 있는가?”에 답합니다. 현대 프레임워크는 이들을 관련 있지만 별개의 관심사로 취급하며, 이 분리는 앱이 커질 때 보안 일관성을 유지하는 주된 이유 중 하나입니다.
인증은 사용자가(또는 서비스가) 주장하는 사람이 맞다는 것을 증명하는 것입니다. 프레임워크는 하나의 방법을 하드코딩하지 않고 대신 비밀번호 로그인, 소셜 로그인, SSO, API 키, 서비스 자격 증명 같은 일반적인 옵션을 위한 확장 지점을 제공합니다.
인증의 결과는 신원입니다: 사용자 ID, 계정 상태, 때로는 이메일 확인 여부와 같은 기본 속성들. 중요한 점은 인증이 어떤 액션이 허용되는지를 결정해서는 안 되며—오직 누가 요청을 하는지에만 집중해야 합니다.
인가는 확립된 신원과 요청 컨텍스트(라우트, 리소스 소유자, 테넌트, 스코프, 환경 등)를 사용해 특정 액션이 허용되는지를 판단합니다. 역할, 권한, 정책, 리소스 기반 규칙이 이곳에 위치합니다.
프레임워크는 인증 로직과 인가 규칙을 분리하여 다음을 가능하게 합니다:
대부분 프레임워크는 요청 생명주기에서 중앙화된 지점을 통해 규칙을 집행합니다:
이름은 달라도 구성 요소는 익숙합니다: 아이덴티티 스토어(사용자와 자격 증명), 요청 간 신원을 전달하는 세션 또는 토큰, 그리고 일관되게 인증/인가를 집행하는 미들웨어/가드.
이 글의 예시는 개념적 수준을 유지하므로 원하는 프레임워크에 매핑하기 쉽습니다.
프레임워크가 "누군가를 로그인시키기" 전에 필요한 두 가지는: 신원 데이터를 조회할 장소(아이덴티티 스토어)와 코드에서 그 신원을 일관되게 표현하는 방법(유저 모델)입니다. 현대 프레임워크의 많은 "인증 기능"은 이 두 부분에 대한 추상화입니다.
프레임워크는 보통 내장 또는 플러그인을 통해 여러 백엔드를 지원합니다:
users 테이블/컬렉션을 앱이 관리핵심 차이는 누가 진실의 출처인가 입니다. 데이터베이스 사용자는 앱이 자격증명과 프로필 데이터를 소유합니다. IdP나 디렉터리를 쓰면 앱은 종종 외부 신원에 연결된 “로컬 섀도우 유저”를 저장합니다.
프레임워크가 기본 유저 모델을 생성하더라도 대부분 팀은 몇 가지 필드를 표준화합니다:
is_verified, is_active, is_locked, deleted_at이 플래그들은 인증이 단지 “비밀번호가 맞는가?”뿐만 아니라 “이 계정이 지금 로그인할 수 있는 상태인가?”도 판단해야 하기 때문에 중요합니다.
실용적인 아이덴티티 스토어는 등록, 이메일/전화 확인, 비밀번호 재설정, 민감 변화 후 세션 무효화, 비활성화 혹은 소프트 삭제 같은 공통 수명주기 이벤트를 지원합니다. 프레임워크는 토큰, 타임스탬프, 훅 같은 원시 도구를 제공하지만, 만료 창, 속도 제한, 계정 비활성화 시 기존 세션 처리 방식은 여전히 설계해야 합니다.
대부분의 현대 프레임워크는 유저 프로바이더, 어댑터, 또는 레포지토리 같은 확장 지점을 제공합니다. 이 구성요소들은 “주어진 로그인 식별자로 사용자 조회” 및 “주어진 사용자 ID로 현재 사용자 로드”를 SQL 쿼리, IdP 호출, 또는 엔터프라이즈 디렉터리 조회 등 선택한 스토어에 맞게 번역합니다.
세션 기반 인증은 많은 웹 프레임워크가 여전히 기본값으로 사용하는 “고전적인” 접근법으로, 특히 서버 렌더링 앱에서 그렇습니다. 아이디어는 단순합니다: 서버가 누가 누구인지 기억하고 브라우저는 그 기억을 가리키는 작은 포인터를 가집니다.
성공적인 로그인 후 프레임워크는 서버 측 세션 레코드(대개 무작위 세션 ID와 사용자 매핑)를 생성합니다. 브라우저는 세션 ID를 담은 쿠키를 받고, 매 요청마다 브라우저가 자동으로 쿠키를 보내면 서버는 이를 사용해 로그인된 사용자를 조회합니다.
쿠키는 식별자일 뿐(사용자 데이터를 담지 않음)이므로 민감 정보는 서버에 남아 있습니다.
현대 프레임워크는 세션 쿠키가 탈취되거나 오용되지 않게 기본값을 강화합니다:
이 설정은 보통 "세션 쿠키 설정"이나 "보안 헤더" 항목에서 구성됩니다.
프레임워크는 보통 세션 저장소를 선택할 수 있게 합니다:
대략적인 트레이드오프는 속도 vs 내구성 vs 운영 복잡성입니다.
로그아웃은 두 가지 의미일 수 있습니다:
프레임워크는 종종 사용자 “세션 버전”을 추적하거나 사용자당 여러 세션 ID를 저장해 이를 구현합니다. 즉각적인 폐기가 필요하면 서버가 세션을 바로 잊을 수 있으므로 세션 기반 인증은 토큰보다 단순한 경우가 많습니다.
토큰 기반 인증은 서버 측 세션 조회를 무작위 문자열(토큰)이 각 요청에 포함되어 인증하는 방식으로 대체합니다. 프레임워크는 보통 토큰 발급 엔드포인트, 토큰을 검증하는 인증 미들웨어, 신원이 확립된 뒤 실행되는 가드/정책을 1급 패턴으로 권장합니다. 토큰은 API가 주된 서버, 모바일 앱, SPA가 분리된 백엔드와 통신할 때, 또는 서비스 간 호출이 필요할 때 적합합니다.
토큰은 로그인(또는 OAuth 흐름 후)에 발급되는 접근 자격 증명입니다. 클라이언트는 이후 요청에 이를 포함해 호출자를 인증하고 인가를 수행합니다.
Opaque 토큰은 클라이언트에 의미가 없는 무작위 문자열(예: tX9...)입니다. 서버는 데이터베이스나 캐시 조회로 이를 검증합니다. 폐기가 쉽고 토큰 내용이 공개되지 않습니다.
**JWT( JSON Web Token )**은 구조화되어 서명된 토큰입니다. 일반적으로 sub(사용자 식별자), iss(발행자), aud(대상), iat, exp 같은 클레임과 때로는 역할/스코프를 포함합니다. 중요: JWT는 기본적으로 인코딩된 것이지 암호화된 것은 아니므로 토큰을 가진 사람은 클레임을 읽을 수 있지만 서명을 위조하지 못합니다.
프레임워크 권고는 보통 두 가지 안전한 기본값으로 수렴합니다:
Authorization: Bearer <token> 헤더로 액세스 토큰을 전송 — 자동으로 전송되는 쿠키로 인한 CSRF 위험을 피할 수 있지만, 자바스크립트가 토큰을 읽고 첨부할 수 있기 때문에 XSS 방어가 더 중요해집니다.HttpOnly, Secure, SameSite로 설정할 수 있을 때만 사용하고 CSRF를 적절히 처리할 준비가 되어 있어야 합니다(종종 별도의 CSRF 토큰과 함께 사용).액세스 토큰은 짧게 유지합니다. 잦은 로그인을 피하기 위해 많은 프레임워크가 리프레시 토큰을 지원합니다: 장기 자격 증명으로만 새 액세스 토큰을 발급합니다.
일반 구조:
POST /auth/login → access token (및 refresh token) 반환POST /auth/refresh → 리프레시 토큰 회전 및 새 access token 반환POST /auth/logout → 서버 측에서 리프레시 토큰 무효화회전(매번 새 리프레시 토큰 발급)은 리프레시 토큰 도난 시 피해를 제한하며, 많은 프레임워크가 토큰 식별자 저장, 재사용 감지, 신속한 세션 폐기 훅을 제공합니다.
OAuth 2.0과 OpenID Connect(OIDC)는 함께 언급되지만 프레임워크는 둘을 다르게 취급합니다. 그 이유는 해결하는 문제가 다르기 때문입니다.
OAuth 2.0은 위임 접근이 필요할 때 사용합니다: 앱이 사용자의 비밀번호를 다루지 않고 API를 대신 호출할 권한을 얻을 때(예: 캘린더 읽기).
OpenID Connect는 로그인/신원이 필요할 때 사용합니다: 앱이 사용자가 누구인지 알고 ID 토큰으로 신원 클레임을 받을 때. 실무에서는 “X로 로그인”이 보통 OAuth 2.0 위의 OIDC입니다.
대부분의 현대 프레임워크와 인증 라이브러리는 두 가지 플로우에 중점을 둡니다:
프레임워크 통합은 보통 콜백 라우트와 헬퍼 미들웨어를 제공하지만, 올바르게 구성해야 할 핵심 항목들이 있습니다:
프레임워크는 보통 제공자 데이터를 로컬 유저 모델로 정규화합니다. 핵심 설계 결정은 무엇이 실제로 인가를 구동하는가입니다:
일반 패턴은: 안정적인 식별자(예: sub)를 로컬 유저에 매핑하고, 제공자 역할/그룹/클레임을 앱이 제어하는 로컬 역할이나 정책으로 변환하는 것입니다.
비밀번호는 여전히 많은 앱의 기본 로그인 방법이므로 프레임워크는 안전한 저장 패턴과 공통 가드레일을 보통 제공합니다. 핵심 규칙은 변경되지 않았습니다: 절대 비밀번호나 단순 해시를 데이터베이스에 저장하지 마십시오.
현대 프레임워크와 인증 라이브러리는 보통 bcrypt, Argon2, scrypt 같은 목적에 맞는 비밀번호 해시 알고리즘을 기본값으로 제공합니다. 이 알고리즘들은 의도적으로 느리고 **솔팅(salting)**을 포함하여 사전 계산 공격을 어렵게 만듭니다.
SHA-256 같은 빠른 일반 해시는 비밀번호에 안전하지 않습니다. 데이터베이스가 유출되면 빠른 해시는 공격자가 수십억 개의 비밀번호를 빠르게 추측할 수 있게 합니다. 비밀번호 해셔는 작업 인자(cost parameter)를 추가해 하드웨어 향상에 맞춰 보안을 조정할 수 있게 합니다.
프레임워크는 보통 엔드포인트마다 하드코딩하지 않고 후크(또는 미들웨어/플러그인)로 합리적 규칙을 강제할 수 있게 합니다:
대부분 생태계는 비밀번호 확인 후 추가 단계로 MFA를 추가하는 것을 지원합니다:
비밀번호 재설정은 흔한 공격 경로이므로 프레임워크는 보통 다음과 같은 패턴을 권장합니다:
좋은 규칙: 합법적 사용자는 복구가 쉬워야 하지만 공격자가 자동화로 해내기 어렵게 만들 것.
대부분 현대 프레임워크는 보안을 요청 파이프라인 일부로 취급합니다: 컨트롤러/핸들러 이전(때로는 이후)에 실행되는 일련의 단계들. 이름은 미들웨어, 필터, 가드, 인터셉터 등으로 달라도 아이디어는 같습니다: 각 단계는 요청을 읽고 컨텍스트를 추가하거나 처리를 중단할 수 있습니다.
전형적인 흐름은 다음과 같습니다:
/account/settings 등)프레임워크는 보안 검사를 비즈니스 로직 밖에 두도록 권장하여 컨트롤러는 “무엇을 할지”에 집중하게 합니다.
인증 단계에서 프레임워크는 쿠키, 세션 ID, API 키, 베어러 토큰 등으로부터 유저 컨텍스트를 확립합니다. 성공하면 요청 범위(request-scoped)의 신원 객체가 생성되어 user, principal, 또는 context.auth 같은 이름으로 노출됩니다.
이 부착은 중요합니다. 이후 단계나 애플리케이션 코드는 헤더를 다시 파싱하거나 토큰을 다시 검증하지 않아야 하며, 이미 채워진 사용자 객체를 읽어야 합니다. 이 객체에는 보통:
인가 구현 방식은 보통 다음과 같습니다:
후자는 라우트와 서비스 근처에 인가 훅이 위치하는 이유를 설명합니다: 라우트 파라미터나 DB에서 로드한 객체가 있어야 정확히 결정할 수 있기 때문입니다.
프레임워크는 두 가지 실패 모드를 구분합니다:
잘 설계된 시스템은 403 응답에서 어떤 규칙이 실패했는지 세부를 누설하지 않도록 합니다. 단순히 접근을 거부합니다.
인가 질문은 로그인보다 좁습니다: "이 로그인된 사용자가 지금 이 특정 작업을 할 수 있는가?" 현대 프레임워크는 보통 여러 모델을 지원하며 많은 팀이 조합해서 사용합니다.
RBAC는 사용자를 하나 이상의 역할(예: admin, support, member)에 할당하고 그 역할에 따라 기능을 차단합니다.
구현이 쉽고 requireRole('admin') 같은 헬퍼가 제공되면 빠르게 적용할 수 있습니다. 역할 계층구조(“admin은 manager를 포함한다”)는 중복을 줄이지만, 상위 역할의 작은 변경이 앱 전체에 권한을 은밀히 부여할 수 있어 주의가 필요합니다.
RBAC는 넓고 안정적인 구분에 가장 적합합니다.
권한 기반 모델은 보통 다음과 같이 표현합니다:
read, create, update, delete, inviteinvoice, project, user (때로는 ID나 소유권 포함)이 모델은 RBAC보다 정밀합니다. 예: “프로젝트를 업데이트할 수 있음”은 “자신이 소유한 프로젝트만 업데이트 가능”과 다르며, 후자는 권한과 데이터 조건을 모두 검사해야 합니다.
프레임워크는 종종 컨트롤러, 리졸버, 워커, 템플릿에서 호출되는 중앙 can? 함수(또는 서비스)로 이를 구현합니다.
정책은 재사용 가능한 평가기로 인가 로직을 패키지화합니다: "사용자는 댓글을 작성했다면 삭제할 수 있고, 또는 모더레이터라면 삭제할 수 있다" 같은 규칙. 정책은 컨텍스트(사용자, 리소스, 요청)를 받아 소유권 검사, 구독 등급 규칙, 시간/조직 기반 제약 등에 적합합니다.
프레임워크가 정책을 라우팅/미들웨어에 통합하면 엔드포인트 전반에 걸쳐 일관되게 규칙을 적용할 수 있습니다.
@RequireRole('admin') 같은 어노테이션은 의도를 핸들러에 가깝게 유지하지만 규칙이 복잡해지면 분산되는 단점이 있습니다.
명시적 코드 기반 검사는 더 장황하지만 테스트와 리팩터링에 보통 더 용이합니다. 일반 타협은 거친 게이트는 어노테이션으로 처리하고 세부 로직은 정책으로 구현하는 것입니다.
현대 프레임워크는 단순히 사용자를 로그인시키는 것뿐 아니라 인증 주변에서 발생하는 일반적 "웹 접착" 공격에 대한 방어도 제공합니다.
앱이 세션 쿠키를 사용할 경우 브라우저는 요청에 쿠키를 자동으로 첨부합니다—때로는 다른 사이트에서 트리거된 요청에도. 프레임워크의 CSRF 보호는 보통 세션 기반(또는 요청 기반) CSRF 토큰을 추가하여 상태 변경 요청과 함께 전송되도록 요구합니다.
일반 패턴:
CSRF 토큰을 SameSite 쿠키(보통 기본값은 Lax)와 함께 사용하고, 세션 쿠키는 적절히 HttpOnly 및 Secure로 설정하세요.
CORS는 인증 메커니즘이 아니라 브라우저 권한 시스템입니다. 프레임워크는 보통 신뢰할 수 있는 출처가 API를 호출할 수 있게 하는 미들웨어/구성 옵션을 제공합니다.
피해야 할 잘못된 구성:
Access-Control-Allow-Origin: * 와 Access-Control-Allow-Credentials: true를 동시에 사용하는 것(브라우저가 거부하거나 혼동 신호)Origin 헤더든 반사하는 것Authorization)나 메서드를 허용하지 않아 curl에서는 동작하지만 브라우저에서는 실패하는 경우대부분 프레임워크는 다음과 같은 헤더를 안전 기본값으로 설정하거나 추가하기 쉽게 합니다:
X-Frame-Options 또는 Content-Security-Policy: frame-ancestors로 클릭재킹 방지Content-Security-PolicyReferrer-Policy 및 X-Content-Type-Options: nosniff 등 브라우저 동작 강화검증은 데이터가 잘 형성되었는지를 보장하고, 인가는 사용자가 그 작업을 수행할 권한이 있는지 확인합니다. 유효한 요청도 여전히 금지될 수 있으므로, 프레임워크는 입력을 일찍 검증한 뒤 특정 리소스 접근에 대한 권한을 강제하는 방식이 최선입니다.
"올바른" 인증 패턴은 코드가 어디에서 실행되고 요청이 백엔드에 어떻게 도달하는지에 크게 좌우됩니다. 프레임워크는 여러 옵션을 지원할 수 있지만 한 앱 유형에서 자연스러운 기본값이 다른 유형에서는 어색하거나 위험할 수 있습니다.
SSR 프레임워크는 보통 쿠키 기반 세션과 잘 어울립니다. 브라우저가 쿠키를 자동 전송하고 서버가 세션을 조회하면 페이지는 추가 클라이언트 코드 없이 사용자 컨텍스트로 렌더링할 수 있습니다.
실용적 규칙: 세션 쿠키를 HttpOnly, Secure, 합리적인 SameSite 설정으로 유지하고, 개인 데이터 렌더링 시 서버 측 인가 검사를 수행하세요.
SPA는 자바스크립트에서 API를 호출하므로 토큰 선택이 더 중요해집니다. 많은 팀은 짧은 수명의 액세스 토큰을 발급받는 OAuth/OIDC 흐름을 선호합니다.
장기 토큰을 localStorage에 저장하는 것은 XSS 시 폭발 범위를 키우므로 피하세요. 대안으로는 BFF(backend-for-frontend) 패턴: SPA는 세션 쿠키로 자체 서버에 요청하고, 서버가 업스트림 API용 토큰을 교환/보관합니다.
모바일 앱은 브라우저 쿠키 규칙을 동일하게 신뢰할 수 없어 보통 PKCE가 포함된 OAuth/OIDC를 사용하고 리프레시 토큰을 플랫폼의 안전한 저장소(Keychain/Keystore)에 보관합니다.
“분실된 디바이스” 복구를 계획하세요: 리프레시 토큰을 폐기하고 자격 증명을 회전하며 MFA가 활성화된 경우 재인증 흐름을 원활하게 해야 합니다.
여러 서비스가 있을 때 중앙 신원 관리와 서비스 수준 집행 중 선택해야 합니다:
서비스 간 인증에는 프레임워크가 mTLS(강한 채널 신원) 또는 OAuth 클라이언트 자격(서비스 계정)을 통합하는 경우가 많습니다. 핵심은 호출자를 인증하고 그가 무엇을 할 수 있는지도 인가하는 것입니다.
관리자 ‘사용자 가장’ 기능은 강력하지만 위험합니다. 명시적 가장 세션을 선호하고, 관리자에게는 재인증/MFA를 요구하며, 항상 감사 로그(누가 누구를 가장했는지, 언제, 어떤 작업을 했는지)를 기록하세요.
보안 기능은 코드가 바뀔 때에도 계속 작동해야 의미가 있습니다. 현대 프레임워크는 인증·인가 테스트를 쉽게 만들지만, 실제 사용자 행동과 실제 공격자 행동을 반영한 테스트가 필요합니다.
다음처럼 검사 대상을 분리하세요:
대부분 프레임워크는 매번 세션이나 토큰을 직접 생성하지 않아도 되도록 테스트 헬퍼를 제공합니다. 일반 패턴:
실용적 규칙: 모든 “해피 패스” 테스트마다 인가 검사가 실제로 실행되는지 증명하는 “거부되어야 함” 테스트를 추가하세요.
Koder.ai 같은 도구는 빠른 프로토타이핑과 안전한 롤백을 지원해 세션 vs 토큰 접근을 실험하고 미들웨어/가드와 정책 검사를 다듬을 때 유용합니다.
문제가 생겼을 때 빠르고 확신 있게 답을 얻고 싶습니다.
주요 이벤트를 로깅/감사하세요:
가벼운 메트릭도 추가하세요: 401/403 응답 비율, 로그인 실패 급증, 비정상적인 토큰 갱신 패턴 등.
인증·인가 버그는 테스트 가능한 동작으로 다루세요: 리그레션이 가능하다면 테스트를 추가해야 합니다.
인증은 신원(요청을 하는 사람이 누구인지)을 증명합니다. 인가는 그 신원이 특정 상황에서 무엇을 할 수 있는지를 결정합니다(라우트, 리소스 소유권, 테넌트, 스코프 등 컨텍스트를 사용).
프레임워크는 인증과 인가를 분리하여 로그인 방식을 바꾸더라도 권한 로직을 다시 작성할 필요가 없게 합니다.
대부분의 프레임워크는 요청 파이프라인에서 인증/인가를 적용합니다. 일반적인 지점은:
user/principal을 붙이는 미들웨어/필터/인터셉터아이덴티티 스토어는 사용자와 자격 증명의 진실 소스(또는 외부 신원에 대한 링크)입니다. 유저 모델은 코드에서 그 신원을 어떻게 표현하는지에 대한 것입니다.
실무에서는 프레임워크가 “이 식별자/토큰이 주어졌을 때 현재 사용자가 누구인지?”에 답할 수 있어야 하므로 둘 다 필요합니다.
일반적인 통합 대상:
IdP/디렉터리를 사용할 때는 종종 OIDC sub 같은 외부 고유 ID를 로컬의 “섀도우 유저”에 매핑해 앱 전용 역할과 데이터를 연결합니다.
세션은 서버 측에 신원을 저장하고 쿠키로 포인터(session ID)를 전달합니다. 서버 렌더링(SSR)에 적합하고 즉각적인 세션 폐기가 쉬운 장점이 있습니다.
토큰(JWT/opaque)은 각 요청에 포함되어 전송되며 API, SPA, 모바일, 서비스 간 호출에 적합합니다.
세션 쿠키를 강화할 때 프레임워크가 주로 설정하는 플래그:
HttpOnly (XSS로부터 쿠키 읽기 차단)Secure (HTTPS에서만 전송)SameSite (교차 사이트 전송을 제한; CSRF/타사 로그인 흐름에 영향)앱에 맞게 Lax vs None 등 값을 선택해야 합니다.
Opaque 토큰은 서버 조회로 검증되는 무작위 문자열(내부 내용을 클라이언트가 모름)으로 폐기가 쉽습니다.
JWT는 서명된 자체 포함 토큰으로 sub, exp, 역할/스코프 같은 클레임을 포함합니다. 읽을 수는 있지만 기본적으로 암호화되어 있지는 않으며, 위조를 막기 위해 서명되어 있습니다. 분산 환경에서는 편리하지만 폐기가 어렵기 때문에 짧은 만료와 서버 제어(블랙리스트/버전 관리 등)가 필요합니다.
액세스 토큰은 짧게 유지하고, 리프레시 토큰은 새 액세스 토큰을 발급하는 데 사용합니다.
일반적인 엔드포인트 구조:
POST /auth/login → access + refreshPOST /auth/refresh → 리프레시 토큰 회전 + 새 access 발급POST /auth/logout → 리프레시 토큰 무효화회전(rotation)과 재사용 감지로 리프레시 토큰 유출의 피해를 줄일 수 있습니다.
OAuth 2.0은 권한 위임(앱이 사용자 대신 API를 호출할 권한을 얻는 경우)에 사용합니다.
OIDC는 로그인/신원(사용자가 누구인지 알기 위해 ID 토큰과 표준화된 클레임을 제공)에 사용합니다.
실무에서 “X로 로그인”은 보통 OAuth 2.0 위에 구축된 OIDC입니다.
RBAC(역할)는 admin, support, member 같은 넓은 구분에 적합합니다. 퍼미션/정책은 더 세밀한 규칙(예: 자신이 소유한 항목만 수정 가능)을 표현합니다.
일반 패턴: