✅ 압박면접 대응 시리즈 23편: API 인증 방식 비교 — API Key, OAuth 2.0, JWT 선택 기준

✅ 압박면접 대응 시리즈 23편: API 인증 방식 비교 — API Key, OAuth 2.0, JWT 선택 기준

압박면접에서 “API 인증은 어떤 방식으로 하셨나요?”라는 질문이 나오면,
단순히 “JWT 썼습니다”로 끝내면 바로 추가 질문이 들어옵니다.

“그럼 JWT와 OAuth의 차이는요?”
“API Key는 왜 보안상 위험하다고 하나요?”
“Refresh Token을 OAuth 플로우에서 어떻게 쓰나요?”

이 질문은 API 보안, 토큰 기반 인증 흐름, 실무 설계 기준까지 이해했는지를 평가합니다.

---

📌 1. 주요 API 인증 방식 개요

방식 핵심 개념 주요 특징

API Key	단일 키 기반 인증	간단하지만 보안 취약
OAuth 2.0	외부 서비스 위임 인증	토큰 기반, 권한 범위 지정 가능
JWT	서버리스 토큰 인증	경량, 분산환경에 적합

---

📌 2. API Key 방식

반응형

✅ 개념

• 서버가 발급한 고유 키(API Key)를 요청 헤더에 포함해 인증

GET /api/data  
Authorization: Api-Key 1234-ABCD

✅ 장점

• 구현 간단
• 서버 부하 적음

✅ 단점

• 노출 시 즉시 악용 가능 (고정 키, 회수 어려움)
• 사용자 구분 어려움 → 세밀한 권한 제어 불가능

📌 면접 포인트:

“API Key는 내부 시스템 간 통신에는 적합하지만,
사용자 인증이 필요한 서비스에는 부적절합니다.”

---

📌 3. OAuth 2.0 방식

✅ 개념

사용자가 제3자 애플리케이션에 자신의 데이터 접근 권한을 위임하는 표준 인증 프로토콜

대표 사례:

• 구글/네이버 로그인
• “이 앱이 당신의 프로필 접근을 허용하시겠습니까?”

✅ 동작 플로우 (Authorization Code Grant)

sequenceDiagram
User->>App: 로그인 시도
App->>OAuth Server: 인증 요청 (client_id, redirect_uri)
OAuth Server-->>User: 로그인 + 동의
User-->>OAuth Server: 승인 코드 발급
OAuth Server-->>App: Authorization Code 전달
App->>OAuth Server: Access Token 요청
OAuth Server-->>App: Access Token 반환
App->>API: Token으로 데이터 접근

✅ 장점

• 권한 범위(Scope) 제한 가능
• Refresh Token 기반 자동 갱신
• OAuth 서버로 중앙 관리

✅ 단점

• 구현 복잡
• Redirect URI 관리 필요

📌 면접 포인트:

“OAuth 2.0은 사용자 인증이 아닌 ‘권한 위임’을 위한 프로토콜입니다.”

---

📌 4. JWT(JSON Web Token) 방식

✅ 개념

사용자의 인증 상태를 자체적으로 포함하는 자급형 토큰(Self-contained Token)

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6...

✅ 장점

• 서버 세션 불필요 (Stateless)
• Microservice / 분산 환경에서 유리
• Payload 내 권한 정보 포함 가능

✅ 단점

• 토큰 탈취 시 만료 전까지 위험
• 만료 전 강제 무효화 어려움

---

📌 5. 인증 방식 선택 기준

상황 추천 방식 이유

내부 시스템 간 통신	API Key	단순, 고정 키로 충분
외부 서비스 연동	OAuth 2.0	권한 위임, 보안성
단일 서비스 로그인	JWT	서버리스, 빠른 인증
모바일 / SPA 앱	JWT + Refresh Token	토큰 기반 지속 인증

📌 면접 포인트:

“저는 내부 API에는 API Key, 사용자 인증에는 JWT, 외부 OAuth 연동에는 OAuth 2.0을 사용했습니다.”

---

📌 6. 실무 적용 사례 (React + NestJS + Google OAuth)

상황:
사용자 로그인 방식을 자체 JWT에서 Google OAuth 2.0으로 전환

해결 과정:

1. Google OAuth 로그인 플로우 구현 (Authorization Code Grant)
2. Access Token → 서버 검증 후 내부 JWT 발급
3. Refresh Token은 HttpOnly 쿠키로 저장
4. 토큰 재발급 API 구성

📈 결과:

• 로그인 속도 향상 (2.1s → 1.4s)
• 보안 감사 통과 (토큰 탈취 취약점 0건)

---

📌 7. 압박면접 예상 질문 & 답변 포인트

• ❓ Q. OAuth와 JWT는 같은 건가요?
  → “JWT는 토큰 형식, OAuth는 인증 프로토콜입니다.
  OAuth Access Token의 포맷으로 JWT를 사용하는 경우가 많습니다.”
• ❓ Q. Refresh Token을 어디에 저장해야 하나요?
  → “HttpOnly + Secure 쿠키에 저장해야 합니다.
  LocalStorage는 XSS 공격에 취약합니다.”
• ❓ Q. OAuth를 구현할 때 가장 까다로웠던 점은?
  → “Redirect URI 관리와 Scope 제어가 가장 복잡했습니다.
  이를 위해 환경별로 별도 Redirect 관리 로직을 작성했습니다.”

---

📌 8. 면접에서 활용할 한 줄 정리

“API 인증 방식은 보안성과 운영 효율에 따라 선택해야 합니다.
내부는 API Key, 사용자 인증은 JWT, 외부 연동은 OAuth 2.0으로 설계해
보안성과 확장성을 모두 확보했습니다.”

---

압박면접,API인증,JWT,OAuth,APIKey,AccessToken,RefreshToken,보안설계,인증플로우,프론트엔드보안

---