# 인증 방식 완전 정복: Basic, Bearer, OAuth2, JWT, SSO는 언제 쓰나요?

# # 서론 – “왜 이렇게 많은 인증 방식이 있을까?”

웹 서비스와 모바일 앱을 개발하면 **‘인증’**은 가장 먼저 마주하는 과제입니다.

하지만 “Basic 인증이 좋은가?”, “Bearer 토큰과 JWT는 무슨 차이가 있지?” 같은 질문에 답을 찾기 어려운 경우가 많죠.

이 글에서는 초보자도 쉽게 이해할 수 있도록 **Basic, Bearer, OAuth2, JWT, SSO** 다섯 가지 주요 인증 방식을 각각 언제, 어떻게 쓰는지 비교합니다.

> **핵심 키워드**: 인증 방식, OAuth2, JWT

---

# # 1️⃣ Basic 인증 – 가장 단순하지만 보안에 취약

## # 1‑1. 동작 원리

- 클라이언트가 `Authorization: Basic <Base64(username:password)>` 헤더를 서버에 전송합니다.

- 서버는 Base64 문자열을 디코딩해 사용자 이름과 비밀번호를 확인하고, 성공하면 요청을 허용합니다.

## # 1‑2. 언제 사용하나요?

- **내부 서비스** 혹은 **테스트 환경**처럼 네트워크가 안전하게 보호된 경우.

- 복잡한 토큰 관리가 필요 없는 **간단한 API**.

## # 1‑3. 주의점

- 비밀번호가 평문으로 전송되지는 않지만, Base64는 **인코딩**에 불과해 쉽게 복호화됩니다.

- 반드시 **HTTPS**와 함께 사용해야 하며, 장기적인 서비스에는 적합하지 않습니다.

---

# # 2️⃣ Bearer 토큰 – 토큰 기반 인증의 기본 형태

## # 2‑1. 동작 원리

- 클라이언트가 `Authorization: Bearer <access_token>` 헤더에 토큰을 담아 요청합니다.

- 서버는 토큰을 검증하고, 유효하면 요청을 처리합니다.

## # 2‑2. 언제 사용하나요?

- **REST API**에서 세션을 유지하지 않고 **Stateless**하게 인증하고 싶을 때.

- 토큰이 **짧은 수명**(예: 1시간)이라면 보안 위험을 최소화할 수 있습니다.

## # 2‑3. 장점 & 단점

| 장점 | 단점 |

|------|------|

| 서버에 세션 저장이 필요 없어 확장성이 좋음 | 토큰 자체가 탈취되면 바로 인증이 가능 |

| 다양한 인증 서버와 연동이 쉬움 | 토큰 폐기(Revocation) 구현이 복잡할 수 있음 |

---

# # 3️⃣ OAuth2 – 제3자에게 권한을 위임하는 표준 프로토콜

## # 3‑1. 핵심 개념

- **Resource Owner(사용자)** → **Client(앱)** → **Authorization Server(인증 서버)** → **Resource Server(리소스 서버)** 순으로 흐릅니다.

- `Authorization Code`, `Implicit`, `Client Credentials`, `Refresh Token` 등 4가지 **Grant Type**이 있습니다.

## # 3‑2. 언제 사용하나요?

- **소셜 로그인**(Google, Facebook 등)이나 **기업 연동**(Microsoft, Salesforce)처럼 외부 서비스에 **접근 권한을 위임**해야 할 때.

- 여러 서비스가 **공통 인증 서버**를 사용해 **싱글 사인온(SSO)**을 구현하고 싶을 때.

## # 3‑3. 장점

- 사용자는 비밀번호를 직접 제공하지 않아 **보안 위험이 감소**합니다.

- 토큰(액세스 토큰, 리프레시 토큰)으로 **세분화된 권한 제어**가 가능합니다.

---

# # 4️⃣ JWT (JSON Web Token) – 자체 검증 가능한 토큰

## # 4‑1. 구조

```

Header . Payload . Signature

```

- **Header**: 토큰 타입, 서명 알고리즘

- **Payload**: 클레임(사용자 ID, 권한, 만료시간 등)

- **Signature**: 비밀키로 생성, 변조 방지

## # 4‑2. 언제 사용하나요?

- **마이크로서비스** 환경처럼 여러 서비스가 **공통된 인증 정보를** 별도 조회 없이 검증해야 할 때.

- **클라이언트 측에서** 토큰 정보를 확인하거나 디코딩해 UI를 제어하고 싶을 때.

## # 4‑3. 장점

- **Self‑contained**라 서버가 토큰을 저장할 필요가 없어 확장성이 뛰어남.

- 토큰에 필요한 정보를 모두 담을 수 있어 **추가 DB 조회가 불필요**.

## # 4‑4. 주의점

- 토큰이 **큰 용량**(몇 백 바이트)이라 HTTP 헤더에 부담이 될 수 있음.

- 토큰 자체에 중요한 정보를 넣으면 **노출 위험**이 있으니 최소한의 클레임만 포함시킵니다.

---

# # 5️⃣ SSO (Single Sign‑On) – 한 번 로그인으로 모든 서비스 이용

## # 5‑1. 원리

- 사용자는 **하나의 인증 서버**에 로그인하고, **인증 토큰**을 여러 애플리케이션에 전달합니다.

- 대표적인 구현 방식: **SAML**, **OpenID Connect(OIDC)**, **OAuth2**와 결합된 형태.

## # 5‑2. 언제 사용하나요?

- 기업 내부 **포털, ERP, CRM** 등 여러 시스템을 **통합**해서 운영할 때.

- 사용자 경험(UX)을 향상시키고 **비밀번호 관리 비용**을 줄이고 싶을 때.

## # 5‑3. 장점

- 로그인 횟수가 줄어들어 **생산성 향상**.

- 중앙 집중식 **보안 정책** 적용이 가능.

---

# # 결론 – 상황에 맞는 인증 방식을 선택하자

| 상황 | 추천 인증 방식 |

|------|----------------|

| 내부 테스트, 간단 API | Basic 인증 (HTTPS 필수) |

| Stateless REST API | Bearer 토큰 |

| 외부 서비스 연동·소셜 로그인 | OAuth2 + OpenID Connect |

| 마이크로서비스, 토큰 자체 검증 | JWT |

| 기업 포털·다중 시스템 연동 | SSO (SAML / OIDC) |

**당신의 프로젝트에 가장 적합한 인증 방식을 선택하고, HTTPS와 토큰 관리 정책을 철저히 적용한다면 보안은 물론 사용자 경험까지 크게 향상됩니다.**

> **다음 단계**

> 1️⃣ 현재 시스템에 적용 가능한 인증 방식을 리스트업

> 2️⃣ 보안 요구사항(만료시간, 암호화 등) 정의

> 3️⃣ 선택한 방식에 맞는 라이브러리(예: Spring Security, Passport.js) 도입

궁금한 점이 있으면 댓글로 남겨 주세요! 여러분의 인증 설계가 성공적으로 진행되길 응원합니다. 🚀