로그인, 이렇게도 만든다고?

1. 인증 vs 인가

• 인증(Authentication) : 내가 누구 인지 확인하는 과정
• 인가(Authorization) : 내가 무슨 권한 을 갖고 있는지 결정하는 과정

예시: 쇼핑몰 관리자 페이지

• 인증: 이메일/비밀번호로 사원 확인
• 인가: 관리자만 상품 등록 권한 부여

---

2. 세션 기반 인증

서버에 세션 정보를 저장하고, 클라이언트에는 세션ID를 쿠키로 전송하는 전통적인 방식

작동 원리

1. 로그인 요청 → 서버에서 세션ID 생성
2. 클라이언트에 Set-Cookie: sessionId=abc123 응답
3. 이후 요청 시 쿠키에 담긴 sessionId로 사용자 확인

장점

• 구현이 간단하고, 로그아웃 처리도 쉬움
• 서버에서 유저 상태를 자유롭게 관리 가능

단점

• 서버에 세션 데이터 저장 필요 → 메모리 부담
• 서버가 분산되면 세션 공유가 어려움 (ex Redis 필요)

---

3. JWT(JSON Web Token) 인증

토큰 자체에 사용자 정보를 담아 서버가 별도로 기억할 필요 없는 방식

작동 원리

1. 로그인 → 서버에서 JWT 생성 (유저정보 + 서명)
2. 클라이언트가 로컬 스토리지나 쿠키에 저장
3. 이후 요청 시 Authorization: Bearer <token> 헤더로 전달

장점

• 서버 상태를 기억할 필요 없음 (stateless)
• 수평 확장에 유리
• 유효기간 설정 가능

단점

• 토큰 탈취 시 위험 → HTTPS 필수
• 로그아웃 처리가 복잡 (토큰 블랙리스트 필요)
• 토큰 크기가 커질 수 있음

---

4. OAuth2·소셜 로그인

구글, 카카오 등 외부 인증 시스템을 이용한 로그인 방식

작동 원리

1. “소셜 로그인” 클릭 → 인증 서버 페이지로 이동
2. 사용자 동의 → 인증 코드 발급
3. 서버에서 해당 코드로 사용자 정보 조회 및 처리

장점

• 사용자 가입 허들이 낮아짐
• 별도 비밀번호 관리 불필요
• 프로필 사진, 이메일 등 자동 연동

단점

• 외부 서비스 장애 시 로그인 불가
• 구현이 상대적으로 복잡 (콜백, 리다이렉트 처리 등)
• 데이터 수집 동의 이슈 발생 가능

---

5. 우리 서비스에 맞는 방식은?

상황	추천 방식
MVP 단계 / 빠르게 기능 완성	세션 기반 인증
트래픽 증가 / 서버 확장 필요	JWT 기반 인증
빠른 사용자 유입 / UX 중요	OAuth2 소셜 로그인

💡 Tip: 초기에는 세션 기반으로 시작하고, 서비스 성장에 따라 JWT 또는 소셜 로그인을 확장 도입하는 것도 좋은 전략입니다.