인증·인가와 API 보안

보안의 첫 단추는 두 단어를 구분하는 것이다. 인증(Authentication)은 ‘당신이 누구인지’ 확인하는 일이고, 인가(Authorization)는 ‘그래서 무엇을 할 수 있는지’ 결정하는 일이다. 둘은 순서가 있고 책임이 다르다.

인증에 성공한 뒤 ‘이 요청이 로그인한 그 사용자’임을 매번 어떻게 확인할까? 전통적인 세션 방식과 토큰(JWT) 방식이 대표적이며, 무상태 확장과 직접 맞닿아 있다.

JWT는 헤더.페이로드.서명 세 부분을 점으로 이은 문자열이다. 앞 두 부분은 단순 Base64URL 인코딩이라 누구나 디코드해 읽을 수 있고, 마지막 서명이 위변조를 막는다. 이 구조를 오해하면 보안 사고로 이어진다.

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI0MiIsInJvbGUiOiJ1c2VyIn0.3Vd...서명

# 점(.)으로 나뉜 세 조각
header  = { "alg": "HS256" }                  # 서명 알고리즘
payload = { "sub": "42", "role": "user" }     # 클레임(누구·권한·만료)
signature = HMAC(header + payload, secret)     # 비밀키로 만든 서명

# 주의: payload는 '암호화'가 아니라 '인코딩'이다 → 비밀번호 같은 민감정보 금지

• 만료(exp)는 짧게: 액세스 토큰 수명을 짧게 두고 리프레시로 갱신해 탈취 피해 창을 줄인다.
• 민감정보 금지: 페이로드는 누구나 읽으므로 식별자·권한 정도만 담는다.
• 강제 로그아웃이 필요하면: 블랙리스트나 토큰 버전을 서버에 둬야 하며, 그 순간 완전한 무상태는 아니게 된다. 트레이드오프를 인지하고 선택한다.

인가를 코드 곳곳에 흩뿌리면 곧 엉킨다. 가장 널리 쓰이는 정리법이 역할 기반 접근 제어(RBAC)다. 사용자에게 직접 권한을 주는 대신, ‘역할’에 권한을 묶고 사용자에게 역할을 부여한다.

// 사용자 → 역할 → 권한
user(42).roles = ["editor"]
role("editor").permissions = ["article:read", "article:write"]

// 엔드포인트에서 '권한'으로 검사 (역할 이름이 아니라 권한으로)
@RequirePermission("article:write")
PUT /articles/{id}

// + 소유권 검사: 권한이 있어도 '내 글'인지 따로 확인
if (article.authorId != currentUser.id) throw Forbidden()

OWASP가 정리한 흔한 위험들은 대부분 ‘입력을 믿었거나, 검사를 빠뜨렸거나, 정보를 흘린’ 데서 온다. 화려한 공격보다 기본 방어를 빠짐없이 하는 것이 실무 보안의 90%다.

• 인가 누락(IDOR): /orders/123에서 123이 내 것인지 항상 검사한다. ID를 추측해 남의 자원에 접근하지 못하게.
• 전송 구간 암호화: 모든 통신은 HTTPS(TLS)로. 토큰·쿠키는 Secure 속성으로 평문 전송을 막는다.
• 레이트 리밋: 로그인·인증 엔드포인트에 시도 횟수 제한을 둬 무차별 대입과 남용을 막는다.
• CORS는 보안이 아니라 완화: 출처 제어일 뿐 인증을 대체하지 않는다. 허용 출처를 좁게 두되, 인가는 별도로 한다.