1. 인증(Authentication)이란?

"너 누구야?"를 확인하는 과정
사용자 신원을 확인하고, 로그인 상태를 유지하는 방법

2. 주요 인증 방식 3가지

방식	대표 예시	특징 요약
세션 기반 인증	전통적인 로그인 (JSESSIONID 쿠키)	서버가 로그인 상태 저장
JWT (토큰 기반 인증)	REST API, 모바일	서버가 상태 저장 안 함 (stateless)
OAuth2	카카오/구글 로그인	외부 인증 서비스 위임

---

✅ 1. 세션(Session) 기반 인증

🔹 흐름 요약

1. 로그인 시 서버가 세션 생성
2. 세션 ID (JSESSIONID)를 쿠키로 클라이언트에게 전달
3. 이후 요청 시 해당 세션 ID로 로그인 상태 확인

🔹 장점

• Spring Security 기본 방식
• 서버에서 세션 정보 관리 → 구현 쉬움

🔹 단점

• 서버에 상태 저장 필요 → 확장성 낮음
• 서버 메모리/세션 스토리지 필요

🔹 언제 사용?

• 일반 웹 어플리케이션 (thymeleaf, jsp)
• 로그인 상태 유지가 중요한 환경

---

✅ 2. JWT (JSON Web Token)

🔹 흐름 요약

1. 로그인 시 JWT 발급 (Header.Payload.Signature)
2. 클라이언트는 Authorization 헤더에 JWT를 담아 보냄
3. 서버는 JWT를 검증만 하고 상태 저장 안 함

🔹 장점

• **Stateless (서버 세션 필요 없음)
• 마이크로서비스/모바일에 적합
• 다양한 클레임(사용자 정보 등)을 담을 수 있음

🔹 단점

• 한 번 탈취되면 끝 → 보안 주의
  • JWT는 서버가 상태를 기억하지 않기 때문에, 한 번 발급되면 서버에서 "사용 중지"가 어려움
  • 탈취 방지를 위한 대책
    • HTTPS 강제: 가장 기본이자 필수. 토큰 전송 중 노출 방지
    • XSS 방지: 토큰을 localStorage에 저장할 경우, 스크립트로 읽힐 위험 → HttpOnly 쿠키 권장
    • 토큰 수명 짧게: access token은 10~30분 등 짧게, 대신 refresh token 사용
    • refresh token은 DB나 Redis에 저장: 탈취되었을 때 서버가 차단 가능하도록 함
    • IP/User-Agent 체크: 동일하지 않으면 차단 가능
    • 토큰 서명 검증: 서명 위조 방지 (HMAC / RSA)
• 토큰 무효화 어렵다 (리프레시 토큰 등 추가 필요)
  • JWT는 Stateless → 서버가 이 토큰이 유효한 지 기억하지 않음
  • 토큰에 exp(만료 시간)만 있다면, 그 이전까지는 항상 "유효"로 처리됨
  • 즉, 탈취되면 막을 방법이 없음
  • JWT 무효화 (로그아웃, 강제 종료 등) 해결 전략
    • 블랙리스트 저장소 사용
      • 로그아웃 시, 해당 JWT의 jti나 값 자체를 Redis 같은 저장소에 넣음
      • 요청이 올 때마다 블랙리스트 조회 → 있으면 막기
      • 단점: 서버가 블랙리스트 저장소 관리해야 해서 "stateless" 취지에서 벗어남
    • Refresh Token 기반 재발급
      • Access Token은 짧게 (ex: 10분)
      • Refresh Token은 DB나 Redis에 저장해두고, 유효성 체크 가능
      • Access Token 탈취돼도 짧은 시간 후 무효됨
    • 토큰에 사용자 상태 정보 포함 + 서버 검증
      • 예: User.active == false일 경우 토큰 무효 처리
      • 또는 토큰마다 고유 ID(jti) 포함 하고, 현재 유효한 토큰 ID인지 서버에서 조회

🔹 언제 사용?

• RESTful API 서버
• 프론트-백 분리된 SPA 구조
• 모바일 앱, 외부 API 연동

---

✅ 3. OAuth2 인증 (소셜 로그인)

🔹 흐름 요약

1. 유저가 "예) 구글 로그인" 클릭
2. 구글 로그인 후 "인가 코드" 발급
3. 백엔드가 인가 코드로 Access Token 요청
4. Access Token으로 사용자 정보 획득

🔹 장점

• 사용자 비밀번호를 백엔드가 직접 다루지 않음
• 다양한 외부 서비스 연동 가능

🔹 단점

• 구현 복잡 (redirect, token 발급 등)

🔹 언제 사용?

• 소셜 로그인 (카카오, 네이버, 구글 등)
• 외부 API 인증 (GitHub API 등)

---

✅ 세 가지 방식 요약 비교

항목	세션	JWT	OAuth2
서버 상태 저장	O	❌	❌ (보통 JWT와 함께 사용)
확장성	낮음	높음	높음
구현 난이도	쉬움	중간	복잡
로그아웃 처리	쉬움	어려움 (블랙리스트 필요)	외부 연동 필요
클라이언트	브라우저 위주	웹/앱 모두	브라우저 + 외부 서비스

---

3. OIDC?

OpenID Connect (OIDC)는 OAuth2를 기반으로 만든 사용자 인증을 위한 표준 프로토콜이다. 즉, OAuth2 + 사용자 정보 제공 기능을 추가한 인증 프로토콜이다.

✅ OIDC는 어떤 상황에서 쓰냐?

구글 로그인, 카카오 로그인, 네이버 로그인, Azure AD 로그인, Ketcloak 로그인 등...

• ✅ 로그인 인증도 하고
• ✅ 사용자 정보도 주고
• ✅ 토큰 기반으로 API 인증도 가능

✅OIDC와 OAuth2 차이

항목	OAuth2	OIDC (OpenID Connect)
목적	권한 위임 (authorization)	사용자 인증 (authentication)
토큰	Access Token	Access Token + ID Token
사용자 정보	기본적으로 없음	userinfo, id_token으로 제공
로그인 기능	직접 제공 안 함	로그인 절차 포함

👉 쉽게 말해:

OAuth2는 “이 사람 대신 ~~ 해줘”
OIDC는 “이 사람이 누군지 알려줄게 + 로그인도 해줄게”

---

✅ OIDC의 핵심 구성 요소

구성요소	설명
ID Token	JWT 형식의 토큰. 로그인한 사용자 정보(ID, email 등) 포함
Access Token	리소스 서버에 접근하기 위한 토큰 (OAuth2와 동일)
UserInfo Endpoint	사용자 상세 정보를 API로 제공하는 endpoint
Discovery Endpoint	OIDC 서버 메타 정보 제공 (.well-known/openid-configuration)

---

✅ OIDC 인증 흐름 (Authorization Code Flow)

[1] 사용자가 로그인 요청 → redirect to OIDC Provider (e.g., Google)
[2] 로그인 성공 → code 반환
[3] 백엔드가 code로 → Access Token + ID Token 교환
[4] ID Token 파싱 → 사용자 정보 확인
[5] Access Token으로 API 호출 (optional)