2026-01-27

웹 로그인 구현 방법

  1. 세션 기반 로그인
  2. 토큰 기반 로그인 (JWT)
  3. 외부 인증(OAuth / SSO)

세션(Session) 기반 로그인 (전통적인 방식)

  • 로그인 성공 시 서버가 세션 생성
  • 클라이언트는 세션 ID를 쿠키로 저장
  • 이후 요청마다 쿠키 자동 전송 → 서버가 세션 조회
브라우저 ──(세션ID 쿠키)──▶ 서버
서버 ── 세션 저장소에서 사용자 확인

특징

  • 상태(stateful) 기반
  • 서버가 로그인 상태를 직접 관리

장점

  • 구현 단순
  • 서버 통제력 높음
  • CSRF 방어 전략이 명확

단점

  • 서버 확장성 낮음 (세션 공유 필요)
  • 모바일/SPA/마이크로서비스에 불리

주 사용처

  • 전통적인 웹 (Spring MVC, JSP)
  • 내부 관리자 페이지

토큰(Token, JWT) 기반 로그인 (요즘 표준)

  • 로그인 시 서버가 JWT 발급
  • 클라이언트가 토큰을 들고 다니며 인증
  • 서버는 토큰 검증만 함 (stateless)
브라우저 ──(JWT)──▶ 서버
서버 ── 서명 검증 후 통과

  1. Access Token 단독 방식 (단순형)

    구조

    • 로그인 → accessToken 발급
    • accessToken 만료 시 다시 로그인

    장점

    • 구조 단순

    단점

    • UX 나쁨 (자주 로그아웃)
    • 실무 거의 안 씀

  2. Access Token + Refresh Token (실무 표준)

    구조

    • Access Token (짧은 수명)
    • Refresh Token (긴 수명)
    • Access 만료 시 Refresh로 재발급
    Access → Authorization 헤더
Refresh → HttpOnly 쿠키

    장점

    • 보안 + UX 균형
    • 서버 확장성 좋음
    • SPA / 모바일 최적

    단점

    • 구현 복잡도 ↑

    주 사용처

    • 대부분의 현대 웹 서비스
    • React / Vue / Next.js
    • 모바일 앱

OAuth / 소셜 로그인 (외부 인증 위임)

  • 인증을 외부 서비스에 위임
  • Google / Kakao / Naver 등
우리 서비스 → OAuth 제공자 → 인증 → 토큰

내부 구조

  • OAuth 인증 성공
  • 우리 서버가 자체 JWT 발급
  • 이후는 일반 JWT 로그인과 동일

장점

  • 회원가입 진입장벽 낮음
  • 비밀번호 관리 부담 감소

단점

  • 외부 서비스 의존
  • 초기 설정 복잡

주 사용처

  • 대부분의 서비스에서 기본 옵션

쿠키 기반 JWT 로그인 (덜 권장)

  • JWT를 쿠키에 저장
  • Authorization 헤더 대신 쿠키 사용

문제점

  • CSRF 위험
  • SameSite 설정 복잡

⇒ 그래서 보통:

  • Access는 헤더
  • Refresh만 쿠키

기타 방식

  • Basic Auth
    • ID/PW를 Base64로 전송
    • 테스트/사내 API용
  • API Key
    • 서버 간 통신
    • 사용자 로그인 X
  • SSO (사내 통합 로그인)
    • 회사 내부 시스템
    • OAuth/SAML 기반

results matching ""

    No results matching ""