인증과 인가 (Authentication & Authorization)

목차

인증과 인가를 왜 같이 묻는가

백엔드 면접에서 이 주제는
“JWT를 써봤는가”보다 누구인지 확인하고, 무엇을 할 수 있는지 어디서 판단할 것인가를 보는 질문에 가깝습니다.

보통 다음 질문으로 이어집니다.

  • session과 token 중 무엇을 왜 선택하는가
  • 로그인 상태를 여러 서비스에서 어떻게 공유하는가
  • 권한 판단을 gateway에서 할지, 서비스에서 할지
  • 토큰 탈취나 만료는 어떻게 다룰 것인가

즉, 이 문서의 핵심은
인증 수단 자체보다 신원 확인과 권한 판단의 경계를 설계할 수 있는가입니다.

보안의 큰 원칙은 보안 설계 (Security Design),
API 경계는 API 설계 (API Design),
클라우드 앞단 처리는 API Gateway와 Edge 패턴 (API Gateway and Edge Patterns) 과 같이 보면 좋습니다.

인증과 인가는 다른 문제다

둘은 항상 같이 나오지만 질문이 다릅니다.

구분 질문 예시
인증 (Authentication) 너는 누구인가 로그인 여부, 토큰 유효성, 세션 확인
인가 (Authorization) 무엇을 할 수 있는가 이 주문 수정 가능 여부, 관리자 기능 접근 여부

좋은 답변은 “토큰 검증으로 권한까지 확인한다”보다
인증은 신원 확인, 인가는 자원별 허용 판단으로 나누는 편이 좋습니다.

Session 기반 인증

session 기반 인증은 서버가 로그인 상태를 저장하고,
클라이언트는 session ID만 전달하는 방식입니다.

장점:

  • 서버가 강하게 제어 가능
  • 강제 로그아웃, 세션 회수가 쉬움
  • 권한 변경 반영이 비교적 직관적

주의점:

  • 서버 측 상태 저장 필요
  • 다중 인스턴스 환경에서는 공유 저장소 필요
  • 모바일 / 외부 API 연동에는 덜 자연스러울 수 있음

좋은 답변은 “옛날 방식”처럼 말하기보다
웹 중심 서비스나 강한 세션 제어가 필요한 환경에서는 여전히 유효하다고 설명하는 편이 안전합니다.

JWT 기반 인증

JWT(JSON Web Token)는
토큰 안에 클레임을 담아 서명 기반으로 검증하는 방식입니다.

장점:

  • 여러 서비스에서 독립적으로 검증하기 쉬움
  • 무상태 API와 잘 맞음
  • 모바일, 외부 클라이언트, gateway 앞단 처리와 궁합이 좋음

주의점:

  • 발급된 토큰을 즉시 회수하기 어려움
  • 클레임이 오래 남으면 권한 변경 반영이 늦어질 수 있음
  • 토큰 크기와 노출 범위 관리 필요

좋은 답변은 “JWT가 더 현대적이다”보다
분산 환경과 독립 검증에는 유리하지만, 회수와 실시간 권한 반영은 더 신중히 봐야 한다고 설명하는 편이 낫습니다.

OAuth 2.0과 OIDC 감각

면접에서는 JWT와 OAuth를 같은 것으로 말하면 흐려집니다.

  • JWT: 토큰 형식
  • OAuth 2.0: 권한 위임 프레임워크
  • OIDC: 인증 정보를 표준화해 OAuth 위에 얹은 계층

대표 상황은 다음과 같습니다.

  • 소셜 로그인
  • 외부 클라이언트가 API 접근 권한 위임
  • 사내 SSO

좋은 답변은 세부 grant type를 모두 외우는 것보다
OAuth는 권한 위임, OIDC는 인증 표준화, JWT는 토큰 표현 형식 중 하나라고 구분하는 편이 좋습니다.

토큰 수명과 갱신 전략

인증 설계에서 중요한 것은 발급보다 수명 관리입니다.

대표 선택지는 다음과 같습니다.

항목 짧은 Access Token 긴 Access Token
장점 탈취 피해 범위 축소 재로그인/재발급 부담 감소
주의점 refresh 설계 필요 권한 변경 반영과 회수 어려움

보통은 다음 감각으로 설명하면 좋습니다.

  • access token은 짧게
  • refresh token은 더 엄격하게 보호
  • refresh token rotation 검토
  • 고위험 동작은 추가 인증이나 재확인 고려

좋은 답변은 “토큰 만료 시간을 둡니다”보다
사용자 경험과 탈취 피해 범위를 같이 보고 수명을 설계한다는 식이 더 실무적입니다.

RBAC와 ABAC

인가 설계에서는 권한 모델을 어떤 기준으로 잡는지도 중요합니다.

모델 의미 잘 맞는 경우
RBAC 역할 기반 권한 제어 조직 구조, 관리자/운영자/일반 사용자 구분
ABAC 속성 기반 권한 제어 부서, 리소스 속성, 시간/위치 같은 조건이 많을 때

RBAC는 단순하고 운영이 쉬운 편입니다.

하지만 다음 상황에서는 한계가 있습니다.

  • 같은 역할 안에서도 리소스 소유자가 다름
  • 국가, 조직, 요금제, 데이터 등급 같은 속성이 섞임

좋은 답변은 “RBAC가 더 쉽습니다“에서 멈추지 않고,
기본은 RBAC로 두고 복잡한 자원 조건은 ABAC나 도메인 규칙으로 보완할 수 있다고 설명하는 편이 자연스럽습니다.

Edge와 서비스의 책임 분리

많이 나오는 질문은 “gateway에서 어디까지 판단할 것인가”입니다.

보통 다음처럼 나누면 설명이 깔끔합니다.

  • edge / gateway
    • 토큰 존재 여부
    • 서명 검증
    • 만료, issuer, audience 확인
  • 서비스
    • 이 사용자가 이 자원에 접근 가능한가
    • 이 역할이 이 도메인 행위를 수행 가능한가

즉, 좋은 답변은
앞단은 신원 확인과 공통 정책, 서비스는 자원별 세밀한 인가로 나누는 편이 좋습니다.

이 경계가 흐려지면 다음 문제가 생깁니다.

  • gateway가 비대해짐
  • 도메인 규칙이 앞단에 새어 나감
  • 권한 로직 변경이 더 어려워짐

트레이드오프

선택 장점 주의점
Session 기반 강한 제어, 회수 쉬움 상태 저장과 확장성 부담
JWT 기반 분산 검증과 API 친화적 회수와 권한 변경 반영 난이도
RBAC 중심 단순하고 운영 쉬움 세밀한 자원 조건 표현 한계
ABAC 확대 유연한 정책 표현 정책 복잡도와 디버깅 비용 증가

좋은 답변은 “JWT가 좋다” 혹은 “Session이 안전하다”보다
서비스 형태, 권한 변경 빈도, 운영 복잡도에 따라 선택이 달라진다고 설명하는 편이 더 강합니다.

면접 포인트

  • 인증과 인가는 다른 문제이며, 신원 확인과 자원 허용 판단을 나눠 설명하는 편이 좋다.
  • session과 JWT는 우열보다 제어 방식과 운영 제약이 다르다.
  • OAuth 2.0, OIDC, JWT는 각각 역할이 다르므로 섞어 말하지 않는 편이 좋다.
  • access token 수명, refresh token 관리, 회수 전략이 실제 운영 포인트다.
  • edge는 공통 인증, 서비스는 세밀한 인가라는 경계가 자연스럽다.

참고 자료