8. OAuth 및 JWT

1. 인증 기술의 변화 배경

인터넷·스마트폰·SNS 등장
- 사용자가 모바일 기기와 다양한 서비스 플랫폼에 동시 접속하는 환경이 되면서, 서비스 규모가 급격히 확대됨.
- 분산 서버 구조 및 마이크로서비스 아키텍처가 보편화됨.
기존 쿠키/세션 방식의 한계
- 쿠키/세션은 서버가 세션 스토어(메모리, 레디스 등)에 인증 상태를 유지하고, 클라이언트는 세션 ID만 브라우저 쿠키로 보관.
- 분산된 여러 서버나 도메인 환경에서는 세션 스토어 동기화나 도메인 설정이 복잡해지고, 부하 분산 시 세션 데이터 일관성 유지 문제가 발생함.

2. 싱글 사인온(SSO)

정의
- User가 한 번 로그인하면, SSO에 연동된 여러 시스템·서비스에 추가 로그인 없이 접근할 수 있는 인증 방식.
구성 요소
1. 통합 인증 서버 (Identity Provider)
  - 모든 인증 과정을 이 서버에서 처리.
2. 서비스 제공자 (Service Provider)
  - 실제 애플리케이션 서버. SSO 토큰을 받아 사용자 인증 여부를 판단.
동작 흐름 (간략)
1. 사용자가 서비스 A에 접근 → 인증되지 않으면 통합 인증 서버로 리디렉션
2. 통합 인증 서버에서 로그인 → SSO 토큰 발급
3. 서비스 A는 발급된 토큰을 검증 후 접근 허용
4. 이후 서비스 B에 접근할 때도 동일 토큰으로 인증 처리 가능
단점
- 초기에는 표준화되지 않아 각 플랫폼마다 구현 방식이 달랐고, 주로 상용 솔루션(유료)이 많았음.
- 대규모 엔터프라이즈 환경이 아니면 구축·운영 부담이 큼.

3. OAuth

배경 및 필요성
- 사용자 개인정보(이메일, 프로필 정보 등)를 외부 서비스와 안전하게 공유할 필요가 생김.
- 예: 사용자가 A 서비스에 가입할 때 구글 계정으로 간편 로그인.
- 직접 ID/PW를 제공하지 않고, “권한 위임(authorization)” 방식으로 최소한의 정보만 공유.
개념
1. 리소스 소유자(Resource Owner)
  - 최종 사용자(예: 구글 계정 소유자).
2. 클라이언트(Client)
  - 사용자가 접근하려는 애플리케이션(예: A 서비스).
3. 리소스 서버(Resource Server)
  - 실제 사용자 정보를 저장하고 있는 서버(예: 구글 API).
4. 권한 서버(Authorization Server)
  - 권한 부여와 토큰 발급을 담당(예: 구글 OAuth 인증 서버).
동작 흐름 (Authorization Code Grant 예시)
1. 사용자 → 클라이언트(A 서비스)
2. 클라이언트 → 권한 서버 (인증 요청, 리디렉션)
3. 사용자 로그인 및 권한 동의 → 권한 서버가 Authorization Code 발급
4. 클라이언트 → 권한 서버 (Authorization Code + Client Secret)로 Access Token 요청
5. 권한 서버 → 클라이언트에 Access Token 발급
6. 클라이언트 → 리소스 서버에 Access Token 제시 → 사용자 정보(프로필 등) 조회
장점
- ID/PW를 직접 제공하지 않으므로 보안 강화
- 사용자가 동의한 범위(scope) 내에서만 정보 접근 허용
- SNS 로그인, 서드파티 API 호출 등 다양한 시나리오에서 활용 가능
역사
- 2006년 트위터 오픈 API 계기로 개발 시작 → 2010년 IETF 표준화(RFC 6749)

4. JWT (JSON Web Token)

등장 배경
- 분산 시스템, 모바일 앱, SPA 환경에서 서버 측 세션 저장 없이 상태를 관리하기 위해 2010년 제안.
- 2015년 웹 표준(RFC 7519)으로 채택.
구조
1. Header (헤더)
  - 토큰 타입(JWT)과 서명 알고리즘(HS256, RS256 등) 명시
```
{
  "alg": "HS256",
  "typ": "JWT"
}
```
2. Payload (페이로드)
  - 실제 담고자 하는 클레임(claim) 정보(예: 사용자 ID, 권한, 만료 시간 등)
```
{
  "sub": "user123",
  "role": "admin",
  "iat": 1600000000,
  "exp": 1600003600
}
```
3. Signature (서명)
  - base64UrlEncode(Header) + "." + base64UrlEncode(Payload) 문자열을 비밀키(또는 공개/개인 키 쌍)로 서명한 값
  - 수신자는 이 서명을 검증하여 토큰 변조 여부를 확인