REST API를 어떻게 보안하는가(인증, 인가, 전송)?

Question

IT Interview Practice · Accepted Answer

REST API를 보안한다는 것은 모든 request마다 세 가지 질문에 답하는 것이다: **당신은 누구인가**(authentication), **무엇을 하도록 허용되는가**(authorization), **채널은 사적인가**(transport). REST는 **stateless**하므로 자격 증명은 server session에 사는 대신 각 request와 함께 이동해야 한다.

## 전송: 항상 HTTPS

아래의 모든 것은 **TLS/HTTPS**를 전제한다. 그것이 없으면 token과 API key는 평문으로 이동해 도청될 수 있다. 이는 타협 불가다 — HTTP 위의 bearer token은 유출된 token이다.

## 인증 옵션

**API key** — 헤더에 담긴 정적 비밀. 단순하다. server-to-server와 *애플리케이션*(user가 아님) 식별에 좋다. 그 자체로는 약하다(만료 없음, scope 없음) — 다른 것과 짝짓지 않는 한.
```http
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
```

**OAuth 2.0** — **위임된(delegated)** 접근("내 비밀번호 없이 App X가 내 데이터를 읽게 하기")을 위한 표준. 앱은 flow(예: Authorization Code)를 통해 **access token**을 얻어 bearer token으로 보낸다. "Sign in with Google"과 서드파티 통합이 이렇게 동작한다.

**JWT (JSON Web Token)** — token을 위한 흔한 *형식*: claim(user id, role, 만료)을 담은 서명되고 자기 완결적인 token. server가 서명을 검증한다 — 데이터베이스 조회가 필요 없어 stateless REST에 잘 맞는다.
```text
header.payload.signature   (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
```

## 인가: scope와 role

authentication은 신원을 증명하고, **authorization**은 접근을 결정한다. token은 **scope**(`orders:read`, `orders:write`)나 role을 담고, server는 엔드포인트마다 그것을 확인해 불충분하면 `403 Forbidden`(누락/무효 auth에 대한 `401`과 대비)을 반환한다.

```text
No/invalid token         → 401 Unauthorized
Valid token, no scope    → 403 Forbidden
```

## 그 밖의 필수 요소

```text
✓ Short-lived access tokens + refresh tokens (limit blast radius if leaked)
✓ Rate limiting (429) to blunt brute-force and abuse
✓ Validate/sanitize all input; never trust the client
✓ Principle of least privilege on scopes
```

## 왜 중요한가

보안은 작은 실수가 침해가 되는 지점이므로, 면접관은 이를 통해 당신이 buzzword를 읊는 대신 구조적으로 추론하는지 본다. 그들이 찾는 신호는 당신이 **세 계층을 분리**하는지다 — 전송(HTTPS, 항상), 인증(bearer token/JWT/OAuth를 통해 stateless하게 신원 증명), 인가(scope와 least privilege) — 그리고 그것들을 뒤섞지 않는지, 예컨대 "인증 안 됨"에 `401`을, "인증됐지만 허용 안 됨"에 `403`을 올바르게 쓰는지. 강한 답은 실무적 트레이드오프에 대한 인식을 보인다: JWT는 편리하고 stateless하지만 만료 전 취소가 어렵다(그래서 짧은 수명 + refresh token), API key는 user가 아니라 앱을 식별하고, OAuth는 정확히 user가 서드파티에 비밀번호를 넘기지 않도록 존재한다. 이를 REST의 statelessness — 모든 request의 자격 증명, server session 없음 — 와 엮는 것이, API 보안이 *왜* 지금의 모습인지 이해함을 보여 준다.

전송: 항상 HTTPS

인증 옵션

인가: scope와 role

그 밖의 필수 요소

왜 중요한가

관련 질문