🎯 OAuth2 & OpenID Connect - OAuth2 프로토콜과 OpenID Connect 확장 구조 완전 정복

🧭 1. OAuth2란 무엇인가

OAuth2(Open Authorization 2.0)는 애플리케이션 간에 리소스 접근 권한을 안전하게 위임하기 위한 개방형 표준 프로토콜이다.

즉, 사용자가 직접 자격 증명을 노출하지 않고도 다른 애플리케이션(예: PhotoEditor)이 나를 대신해 내 Google Photo 데이터를 읽을 수 있도록 위임한다.

💡 핵심 개념

• OAuth2는 인가(Authorization) 표준이다.
• “누가 누구의 데이터에 접근할 수 있는가”를 다룬다.
• “누가 로그인했는가”(인증)는 원래 목적이 아니었으나, 이후 OpenID Connect가 이를 확장했다.

---

💬 2. OAuth2가 해결하는 문제

✅ 문제 1. 통합 인증 문제 (Google 사례)

• Gmail, YouTube, Maps, Drive 등 각각 다른 앱이지만 모두 하나의 인증 서버(Auth Server)를 공유한다.
  
• 이 공통 인증 서버가 토큰을 발급하여 한 번 로그인으로 전체 앱 접근을 가능하게 한다.
  

👉 조직 내에서 보안 로직을 통합 관리하고,

서비스(리소스 서버)는 비즈니스 로직만 담당하게 한다.

---

✅ 문제 2. 위임된 접근 (Delegated Access)

PhotoEditor가 내 Google Photos에 접근하려고 할 때:

시나리오	문제
OAuth2 없음	사용자가 PhotoEditor에 Google 비밀번호를 직접 입력해야 함 → 매우 위험
OAuth2 있음	Google이 대신 Access Token을 발급 → PhotoEditor는 사진 읽기만 가능

📌 사용자는 언제든지 Google 계정에서 PhotoEditor의 권한을 취소할 수 있다.

OAuth2의 진정한 목적은 이 “위임된 인가”이다.

---

🧩 3. OAuth2의 구성 요소

구성요소	설명	예시
Resource Owner	자원을 소유한 사용자	Google Photos의 ‘사진 주인’
Client	자원에 접근하려는 앱	PhotoEditor
Authorization Server	토큰을 발급하고 사용자 인증을 담당	Google Auth Server
Resource Server	실제 리소스를 저장하고 제공	Google Photos API
Scope	접근 가능한 범위 (read/write 등)	read:user, photos:read

---

🔐 4. OAuth2 토큰의 종류

토큰 종류	역할	유효기간	비고
Access Token	실제 API 호출 권한	짧음 (수분~수시간)	요청마다 포함
Refresh Token	Access Token 재발급용	김 (수일~수개월)	브라우저·앱에 안전히 보관
ID Token (OIDC)	사용자 정보(JWT) 포함	짧음	인증용 (OpenID Connect 확장)

Access Token은 “출입증”, Refresh Token은 “재발급권”,

ID Token은 “신분증”에 비유할 수 있다.

---

⚙️ 5. Grant Type (권한 부여 방식)

OAuth2는 다양한 시나리오를 고려해 다섯 가지 Grant Type을 정의한다.

이 중 현재는 3가지만 표준으로 유지된다.

Grant Type	사용 시점	사용자 참여	상태	설명
Authorization Code + PKCE	SPA, 웹, 모바일	있음	✅ 유지	가장 안전한 기본 흐름
Client Credentials	서버 간 통신	없음	✅ 유지	백엔드-백엔드 통신용
Refresh Token	Access Token 갱신	없음	✅ 유지	세션 지속용
Implicit	구버전 SPA	있음	❌ 폐기 예정	토큰 노출 위험
Password Grant	내부 단일 시스템	있음	❌ 폐기 예정	비밀번호 직접 노출

---

🔄 6. Authorization Code Flow

최종 사용자가 관련된 가장 기본적인 OAuth2 흐름.

💡 Access Token은 인증 서버와 Resource 서버가 별개여도

JWT 서명 검증으로 신뢰할 수 있다. (공개키 검증)

---

🔑 7. PKCE (Proof Key for Code Exchange)

SPA나 모바일 앱처럼 client_secret을 안전하게 저장할 수 없는 환경을 위한 개선된 흐름.

용어	설명
Code Verifier	클라이언트가 생성하는 랜덤 문자열
Code Challenge	Verifier의 SHA256 해시
Code Challenge Method	해시 알고리즘 (S256 등)

🎯 핵심: Code Challenge를 탈취해도 Code Verifier를 알 수 없어,

악의적 클라이언트가 토큰을 얻지 못함.

---

⚙️ 8. Client Credentials Flow

두 서버(백엔드 간 통신) 간의 인증을 위해 사용.

사용자 없이 클라이언트 ID/Secret으로 토큰을 요청한다.

🧱 마이크로서비스 간 통신에서 가장 일반적으로 사용된다.

---

♻️ 9. Refresh Token Flow

Access Token이 만료되면 클라이언트는 Refresh Token으로 새 토큰을 요청한다.

🔄 Refresh Token도 유효기간이 있으며,

“offline_access” scope를 주면 만료되지 않게 설정 가능 (비권장).

---

🧱 10. Token 검증 방식

검증 방식	설명	장점	단점
Remote Introspection	Resource Server → Auth Server /introspect 호출	실시간 토큰 폐기 가능	네트워크 지연 발생
Local Verification (JWT + JWKS)	Resource Server가 공개키로 자체 검증	빠르고 독립적	토큰 즉시 폐기 불가

💡 대부분의 엔터프라이즈 환경에서는 JWT + JWKS 검증 방식을 채택한다.

---

👥 11. OpenID Connect (OIDC)

OAuth2 위에 얇게 덧씌워진 인증 프로토콜 레이어.

OAuth2가 “인가”를 담당했다면, OIDC는 “누가 로그인했는가”를 표준화한다.

비교 항목	OAuth2	OpenID Connect
목적	인가 (Authorization)	인증 (Authentication)
핵심 토큰	Access Token	ID Token (JWT)
Scope	read, photos, email 등	openid, profile, email 등
표준 API	-	/userinfo
주요 사용처	API 접근 권한	사용자 로그인 식별

✅ OIDC는 openid 스코프가 추가된 OAuth2 요청일 뿐이다.

즉, “Authorization Code Flow + openid scope” = OIDC.

---

🪪 12. ID Token 내부 구조 예시

JWT 형식으로 발급되며, 사용자 정보를 포함한다.

{
  "sub": "112233",
  "name": "Eazy Bytes",
  "email": "tutor@eazybytes.com",
  "aud": "client_app_123",
  "iss": "https://accounts.google.com",
  "iat": 1714200000,
  "exp": 1714203600
}

---

🧠 13. 요약 다이어그램

---

🚀 14. 학습 포인트 정리

학습 항목	요약
OAuth2 핵심 목적	인증이 아닌 인가(Authorization) 표준
인증 확장	OpenID Connect가 Authentication 계층을 제공
보안 모범 사례	PKCE + 짧은 만료 토큰 + HTTPS
검증 전략	JWT + JWKS 공개키 검증 방식
조직 내 구성	Auth Server ↔ Resource Server 분리 구조