🔐 보안 인증 표준(OpenID Connect, OAuth 2.0)의 구성과 차이점

1. 서론: 현대 웹 환경에서 인증·인가 기술의 중요성

• 클라우드, 모바일, API 기반 서비스 확산에 따라 외부 애플리케이션 또는 제3자가 사용자 자원에 접근하는 구조 증가함
• 인증(Authentication)과 인가(Authorization)의 분리 필요성 대두됨
• 이에 따라 OAuth 2.0은 자원 접근에 대한 인가 프로토콜로, OpenID Connect는 인증 프로토콜로 사용됨
• 두 표준은 유사한 구조와 메시지 흐름을 가짐에도 불구하고 근본 목적과 처리 범위에서 명확한 차이 존재함

---

2. OAuth 2.0 개요 및 구성요소

2.1 개요

• 사용자의 자원(Resource)에 접근할 수 있는 권한을 제3자에게 위임(Delegation)할 수 있도록 하는 인가 프로토콜
• 인증 프로토콜 아님 → 사용자 확인(Who you are)에 대한 정보를 보장하지 않음

2.2 주요 구성요소

• Resource Owner: 자원에 대한 권한 보유자(예: 사용자)
• Client: 자원에 접근하고자 하는 제3자 애플리케이션
• Authorization Server: 사용자 인가를 처리하고 Access Token 발급
• Resource Server: 실제 자원이 저장되어 있으며 Access Token을 통해 접근 허용

2.3 인가 방식(Grant Types)

• Authorization Code: 서버 간 보안 통신을 전제로 가장 널리 사용되는 방식
• Implicit: 브라우저 기반 애플리케이션에서 토큰을 클라이언트에 직접 반환함
• Resource Owner Password Credentials: 사용자 ID/Password를 직접 입력받아 토큰 요청
• Client Credentials: Client 자신이 자원에 접근할 경우 사용

---

3. OpenID Connect 개요 및 구성요소

3.1 개요

• OAuth 2.0을 기반으로 인증 기능을 확장한 ID 인증 프로토콜
• 인증 토큰(ID Token)을 통해 사용자의 신원을 검증 가능하게 설계됨
• RESTful API 기반의 분산 인증 체계 구성에 적합

3.2 주요 구성요소

• OAuth 2.0의 모든 요소 포함하며, 다음 구성요소 추가됨
  • ID Token: 사용자의 인증 정보를 담고 있는 JWT(JSON Web Token) 기반 토큰
  • UserInfo Endpoint: 추가적인 사용자 프로필 정보를 제공하는 API 엔드포인트
  • OpenID Provider(OP): 인증 기능을 제공하는 서버(Authorization Server와 동일하거나 포함됨)
  • Relying Party(RP): 인증 정보를 사용하는 애플리케이션(Client와 동일 개념)

3.3 주요 흐름

• OAuth 2.0 Authorization Code Flow를 기반으로, 추가로 ID Token을 발급함
• RP는 Authorization Server로부터 ID Token과 Access Token을 수신
• 이후 UserInfo Endpoint를 호출하여 사용자 정보 취득 가능

---

4. OAuth 2.0 vs OpenID Connect 차이점 비교

구분	OAuth 2.0	OpenID Connect
목적	인가(Authorization)	인증(Authentication)
사용자 정보	직접 제공하지 않음	ID Token 및 UserInfo를 통해 사용자 정보 제공
토큰	Access Token만 발급	Access Token + ID Token
표준 형식	토큰 형식 자유로움 (일반적으로 Bearer Token)	ID Token은 JWT 사용 필수
확장성	인증 기능 미제공, 별도 구현 필요	OAuth 기반에 인증 기능을 자연스럽게 확장함
사용 예시	API 접근 권한 위임 (예: 타 서비스에서 Google Drive 접근)	소셜 로그인, 분산 인증 (예: Google로 로그인)
보안 고려	인증 기능 미비로 phishing 위험 존재	ID Token 서명 검증으로 위·변조 방지 가능

---

5. 실무 활용 사례 비교

OAuth 2.0 적용 사례

• 타사 애플리케이션에서 사용자 동의 하에 Google Drive, Dropbox 등 클라우드 자원 접근 위임
• 카카오, 네이버 API 접근을 위한 개발자 등록 및 토큰 발급 절차에서 주로 사용됨
• 모바일 앱에서 API 호출 시 인가 기능으로 활용

OpenID Connect 적용 사례

• Google, Facebook, Apple 등에서 제공하는 소셜 로그인 기능
• 기업 내부의 SSO(Single Sign-On) 환경 구성 시 사용자 인증용으로 도입
• 헬스케어, 금융 등에서 사용자 본인 인증 강화 목적 사용

---

6. 보안적 고려사항

• OAuth 2.0 단독 사용 시 인증 기능이 없기 때문에, Access Token만으로 사용자 신원 추론 시 보안 문제 발생 가능
• OpenID Connect는 ID Token 서명 검증(JWT Signature Verification), Nonce 검증 등을 통해 위·변조 및 재사용 공격 방지
• PKCE(Proof Key for Code Exchange), Token Revocation, Access Token Scope 제한 등 현대 OAuth 2.0 보안 확장기법도 병행 필요

---

7. 결론 및 시사점

• OAuth 2.0과 OpenID Connect는 모두 현대 인증·인가 시스템의 핵심 기반 구성요소
• OAuth 2.0은 자원 접근 위임에 중점을 둔 인가 프로토콜로, 인증 기능 자체는 제공하지 않음
• OpenID Connect는 OAuth 2.0을 확장하여 인증까지 지원하며, 사용자의 신원을 안전하게 검증하는 데 적합함
• 시스템 설계 시 인증과 인가를 명확히 분리하여 표준 프로토콜을 적절히 조합하는 것이 보안성과 확장성 측면에서 필수임
• 향후 FIDO2, WebAuthn 등 생체 인증 기반의 표준과 연계 시 OpenID Connect 기반의 인증 구조가 더욱 강화될 것으로 기대됨

---