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

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

하지만 “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) 도입

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