JWT·OAuth2·세션 + 인증 SaaS 비교 — 백엔드 인증 방식 선택 기준

인증을 직접 짤지 SaaS에 맡길지 고민이라면, 그 결정이 프로젝트 후반의 운영 부담을 거의 다 결정합니다.

잘못 고르면 토큰 만료 처리·소셜 로그인 추가·보안 패치에 매주 시간이 새 나가고, 반대로 과한 SaaS를 붙이면 사용자 수가 늘 때 청구서가 부담스러워집니다.

 

현업에서 일해온 관점에서, 백엔드 인증을 직접 구현하다 운영 비용에 데어본 경험과 인증 SaaS 비교(가격·과금 단위 5종)를 같이 정리했습니다. 비교 끝나면 세션·JWT·OAuth2 중 무엇을 쓸지, 그리고 직접 짤지 SaaS를 붙일지 답이 보입니다.

먼저 결정 트리 — 자체 구현이냐 SaaS냐

인증은 "어떤 방식이 좋은가"보다 "내가 직접 운영할 수 있는가"가 먼저입니다. 소셜 로그인·MFA·SSO가 필요하면 자체 구현 비용이 급격히 오르니 인증 SaaS 비교부터 봅니다. 반대로 단순 ID/PW 한 종류만 필요하고 사용자 데이터를 외부에 두기 곤란한 규제 환경이면 자체 구현이 낫습니다. "지금은 단순한데 곧 소셜 로그인 붙일 것 같다"는 중간 지대가 가장 흔한데, 이때는 자체 구현에서 SaaS로 옮기는 마이그레이션 비용이 처음부터 SaaS로 가는 비용보다 거의 항상 크다는 점을 미리 계산해 둡니다.

인증 방식 4종 한눈에 — 세션·JWT·OAuth2·API Key

방식	상태 저장	주 용도	강점	약점
세션(Session)	서버 저장(Stateful)	전통 웹앱	즉시 무효화 쉬움	서버 확장 시 세션 공유 필요
JWT	무상태(Stateless)	API·MSA·모바일	서버 확장 자유로움	발급 후 강제 만료 어려움
OAuth2	위임 프로토콜	소셜 로그인·서드파티 권한 위임	비밀번호 공유 없이 권한 위임	흐름 복잡, 오설정 위험
API Key	키 기반	서버 간(B2B) 호출	단순·구현 빠름	사용자 인증엔 부적합

표만 보면 JWT가 만능 같지만, 실제로 가장 자주 사고 나는 지점이 "발급 후 강제 만료 어려움"입니다. 세션은 서버에서 레코드만 지우면 즉시 로그아웃되지만, JWT는 서명만 맞으면 서버가 받으므로 탈취된 토큰을 만료 전까지 막기 어렵습니다. 그래서 순수 JWT만 쓰지 않고 짧은 액세스 토큰 + 서버 측 리프레시 토큰을 섞습니다.

 

한 가지만 짚으면, OAuth2는 인증(Authentication)이 아니라 인가(Authorization·권한 위임) 프로토콜입니다. "구글로 로그인"이 되는 건 OAuth2 위에 OpenID Connect(OIDC) 인증 레이어가 얹혀서입니다. 이 구분 없이 OAuth2만으로 로그인을 짜면 보안 구멍이 납니다.

언제 뭘 쓰나 — 아키텍처별 시나리오

방식은 트렌드가 아니라 아키텍처가 결정합니다.

모놀리식 웹앱이면 세션이 가장 단순합니다. 서버가 하나거나 세션 스토어(Redis 등)를 공유하면 되고, 즉시 로그아웃이 잦은 관리자 시스템에서 세션의 장점이 그대로 살아납니다. MSA라면 세션 공유가 번거로우니 JWT가 자연스럽고, 게이트웨이에서 한 번 검증하면 각 서비스가 무상태로 처리합니다. 단 토큰 무효화 정책은 처음부터 설계해 둡니다. MSA의 인증·인가 분리는 마이크로서비스 설계 패턴 TOP 10과 함께 보면 그림이 잡힙니다.

 

모바일 앱은 쿠키 세션이 불편해 JWT(액세스 + 리프레시)가 사실상 표준입니다. 소셜 로그인이 핵심이면 OAuth2/OIDC를 직접 다루지 말고 인증 SaaS에 위임하는 게 낫고, 서버 간 B2B 호출만 있으면 API Key로 충분합니다.

자체 구현(Spring Security) vs 인증 SaaS — 비용·시간 트레이드오프

백엔드 본업이 Java/Spring이라 인증은 Spring Security 위에서 짜는 경우가 많았습니다. 결론부터 말하면, 단순 로그인은 Spring Security 직접 구현이 명백히 낫고, 소셜·MFA·SSO가 끼면 SaaS가 거의 항상 이깁니다.

 

한 번은 "외부 의존성 줄이자"며 소셜 로그인까지 Spring Security OAuth2 Client로 직접 붙였습니다. 구글·카카오·네이버 세 프로바이더 연동 자체는 쉬웠는데, 문제는 운영에서 터졌습니다. 프로바이더가 콜백 스펙을 바꾸거나 토큰 회전 정책을 강화할 때마다 대응해야 했고, 비밀번호 재설정·이메일 인증·계정 잠금까지 직접 만들다 보니 정작 서비스 기능에 쓸 시간이 인증에 새 나갔습니다.

 

자체 구현의 진짜 비용은 개발이 아니라 운영입니다. 보안 패치는 내 책임이고 토큰 탈취·세션 고정 같은 공격 표면을 계속 점검해야 합니다. SaaS는 이 부담을 월 구독료로 치환하는 거래라, 무료 한도 안의 소규모 프로젝트면 비용·시간 둘 다 절약입니다.

단 SaaS도 만능은 아닙니다. 사용자 데이터가 외부 벤더에 저장되고, 벤더 종속으로 옮기기 어렵고, 사용자가 급증하면 비용 곡선이 가팔라집니다. 그래서 저는 사내 도구·관리자 페이지는 Spring Security 자체 구현, 외부 서비스로 소셜 로그인이 필요하면 SaaS로 갈라 씁니다. 기준선은 인증 요구사항의 복잡도입니다.

인증 SaaS 5종 가격 매트릭스

인증 SaaS 비교에서 가장 헷갈리는 무료 한도 · 시작가 · 과금 단위 세 가지만 확정 표기합니다.

SaaS	무료 MAU 한도	유료 시작가	과금 단위	메모
Auth0	25,000 MAU	B2C Essentials $35/월(500 MAU 포함)	MAU 종량	B2C·B2B 가격 상이
Supabase Auth	50,000 MAU	Pro $25/월(100,000 MAU 포함)	초과분 $0.00325/MAU	SSO는 $0.015/MAU
Firebase Auth	Blaze 50,000 MAU	Spark 무료(DAU 3,000)	초과분 종량	전화·MFA는 메시지당
Clerk	10,000 MAU(MRU)	Pro $20(연)·$25(월), 50,000 MRU 포함	초과분 $0.02/MRU	MRU=가입 24h 후 재방문자만 카운트
Amazon Cognito	신규 10,000 MAU	Essentials·Lite 종량	MAU 종량	SAML·OIDC는 50 초과분 $0.015

가격은 2026년 6월 각 사 공식 페이지 확인값. MAU 정의·리전이 벤더마다 달라 결제 직전 한 번 더 확인하세요.

이 표의 진짜 함정은 과금 단위가 벤더마다 다르다는 점입니다. 무료 한도 숫자만 보고 "Supabase·Firebase가 50,000으로 제일 후하다"고 보면 오판입니다. Clerk는 MRU(가입 24시간 후 재방문자) 기준이라 가입만 하고 안 오는 사용자는 빠져 실효 단가가 낮게 나옵니다. Cognito 무료 한도는 2024년 11월 21일 이후 신규 계정 기준 10,000 MAU, 그 이전 계정은 50,000 MAU로 시점에 따라 다릅니다.

 

소규모 시작이면 무료 50,000으로 넉넉한 Supabase·Firebase, 또는 MRU로 실효 단가가 낮은 Clerk가 유리합니다. 이미 AWS를 쓰면 Cognito가 자연스럽고, 엔터프라이즈 SSO가 필요하면 Auth0의 기능 폭이 넓습니다. 단 Auth0는 MAU가 늘수록 단가 체감이 큽니다.

차트는 무료 MAU 한도만 비교한 값입니다. 유료 단가는 과금 단위(MAU/MRU/DAU)가 달라 직접 비교하면 안 됩니다.

함정 — JWT 만료·리프레시 토큰·XSS/CSRF

인증 사고가 나는 지점은 정해져 있습니다. 자체 구현이든 SaaS든 아래는 직접 점검합니다.

함정 1 — JWT 강제 만료가 안 된다

증상: 강제 로그아웃시켰는데 기존 토큰이 만료 전까지 계속 통과됩니다.

원인: JWT는 무상태라 무효 목록이 없으면 서명만 맞으면 받습니다.

해결: 액세스 토큰을 짧게(15분 내외) 잡고, 무효화 대상은 블랙리스트(Redis)나 리프레시 토큰 회전으로 통제합니다.

함정 2 — 리프레시 토큰 저장 위치

증상: 토큰을 localStorage에 넣었다가 XSS 한 방에 전부 털립니다.

원인: localStorage는 자바스크립트로 읽히므로 XSS 공격에 그대로 노출됩니다.

해결: 리프레시 토큰은 HttpOnly + Secure + SameSite 쿠키에 넣어 JS 접근을 차단하고, 짧은 액세스 토큰만 메모리에 둡니다.

함정 3 — XSS vs CSRF는 막는 방법이 다르다

증상: 쿠키로 옮겼더니 이번엔 CSRF가 걱정됩니다.

원인: 쿠키는 자동 전송돼 요청 위조(CSRF)가 가능합니다. localStorage는 CSRF엔 안전하지만 XSS에 약해 트레이드오프가 반대입니다.

해결: 쿠키 방식이면 SameSite=Strict/Lax + CSRF 토큰을 함께 씁니다. XSS 방지(입력값 이스케이프)와 CSRF 토큰은 별개의 방어선이라 둘 다 필요합니다.

SaaS를 쓰면 이 셋은 대부분 벤더가 처리합니다. 자체 구현이면 "코드는 다 짰는데 이 세 함정은 점검 안 했다"가 가장 흔한 사고입니다. 인증 구현이 끝났다 ≠ 보안 점검이 끝났다입니다.

결정 전 자주 보는 질문

Q. JWT와 세션 인증 중 뭐가 더 안전한가요?
A. 더 안전한 쪽은 없고 트레이드오프만 있습니다. 세션은 즉시 무효화가 쉬워 강제 로그아웃이 잦은 시스템에 강하고, JWT는 무상태라 확장에 유리하지만 강제 만료가 까다롭습니다. 방식보다 저장 위치(쿠키 vs localStorage)와 XSS/CSRF 방어 같은 구현 디테일이 안전도를 좌우합니다.

Q. 소규모 프로젝트인데 Auth0랑 Supabase Auth 중 뭐가 나을까요?
A. 비용만 보면 Supabase Auth의 무료 50,000 MAU가 Auth0의 25,000보다 넉넉합니다. 이미 DB·스토리지로 Supabase를 쓰면 인증까지 묶이는 통합 이점이 큽니다. 엔터프라이즈 SSO·세밀한 룰 엔진이 필요하면 Auth0가 낫습니다. 소규모 단순 로그인이면 Supabase Auth로 시작합니다.

Q. 인증을 직접 구현하면 비용이 절약되나요?
A. 초기엔 절약 같지만 운영에서 역전됩니다. 비밀번호 재설정·이메일 인증·MFA·소셜 대응·보안 패치까지 합치면 인증에 쓰는 시간이 기능 개발 시간을 깎습니다. 단순 ID/PW 한 종류면 자체 구현이 맞지만, 소셜·SSO가 끼면 SaaS 구독료가 시간 비용보다 쌉니다.

Q. 리프레시 토큰은 어디에 저장하는 게 안전한가요?
A. HttpOnly + Secure + SameSite 쿠키가 정답입니다. localStorage는 자바스크립트로 읽혀 XSS가 한 번 뚫리면 토큰이 그대로 탈취됩니다. 액세스 토큰은 짧게(메모리), 리프레시 토큰은 쿠키로 두고 회전시킵니다. 쿠키를 쓰면 CSRF 방어(SameSite + CSRF 토큰)를 추가로 챙깁니다.

Q. 인증 SaaS는 MAU가 늘면 비용이 갑자기 튀나요?
A. 무료 한도를 넘는 순간부터 과금 단위(MAU/MRU/DAU)에 따라 올라가는데, 단위 정의가 벤더마다 달라 체감이 다릅니다. Clerk는 MRU(가입 24시간 후 재방문자) 기준이라 가입만 하고 안 오는 사용자는 빠져 실효 단가가 낮습니다. 결제 직전에 자기 서비스의 활성 사용자 패턴으로 각 사 공식 가격 페이지에서 시뮬레이션하는 게 안전합니다.

---

인증 방식은 트렌드가 아니라 아키텍처와 운영 여력으로 고릅니다. 모놀리식이면 세션, MSA·모바일이면 JWT, 소셜·서드파티면 OAuth2를 SaaS에 위임 — 이 줄기를 잡고, 인증 SaaS 비교는 무료 한도와 과금 단위 함정을 자기 사용자 패턴에 대입하면 됩니다. 자기 환경에 맞는 쪽을 위 매트릭스에서 고르면 됩니다.

📎 이 카테고리의 다른 글

• 개발팀 SaaS 도구 12가지 — 5인 팀 실비용 매트릭스 (무료 조합) — 2026-06-28
• 토스페이먼츠 vs 포트원 vs Stripe — 한국 결제 통합 풀스택 비교 2026 — 2026-06-12
• Spring Boot에서 API 응답을 구조화하는 가장 좋은 방법 — 2024-11-23

같은 개발 정보 & 최신 동향 카테고리에서 이어서 읽기