🆔 OAuth 2.0 & OIDC 개념 정리

1. OAuth (Open Authorization)의 정의

OAuth는 인터넷 사용자가 자신의 비밀번호를 제3자에게 노출하지 않고 특정 웹사이트나 애플리케이션에 저장된 개인 정보에 대한 접근 권한을 안전하게 부여하기 위해 설계된 인가(Authorization) 프레임워크이다.

마치 호텔 예약 시 받는 카드 키와 같이 카드 키 자체가 이용자의 신분증(ID/PW)은 아니지만 특정 방(리소스)에 들어갈 수 있는 권한을 증명하는 것과 같다.

2. OAuth 1.0과 OAuth 2.0

OAuth는 모바일 환경의 급성장과 보안 요구사항의 변화에 맞춰 1.0에서 2.0으로 진화하였다. 두 버전은 구조적 차이가 크며 상호 호환되지 않는다.

OAuth 1.0 (초기 표준)
2007년 트위터와 구글 등이 주도하여 논의를 시작했고 2010년 RFC 5849로 표준화되었다.

• 특징
  - 모든 HTTP 요청마다 디지털 서명(HMAC-SHA1 등)을 생성하여 데이터 무결성을 검증한다.
• 한계
  - 서명 생성 로직이 매우 복잡하여 구현 난도가 높으며 웹 브라우저 기반 환경에 치중되어 있어 모바일 애플리케이션 환경에 유연하게 대응하기 어렵다.

OAuth 2.0 (현대 표준)
1.0의 복잡성과 한계를 해결하기 위해 2012년 RFC 6749를 통해 발표되었다. 현재까지도 전 세계적인 업계 표준으로 자리 잡고 있다.

OAuth 2.0 프레임워크는 시스템의 구성 요소를 다음의 네 가지 역할로 정의한다.

Resource Owner (리소스 소유자): 자신의 정보에 대한 접근 권한을 부여하는 사용자
Client (클라이언트): 사용자의 리소스에 접근하려는 제3의 애플리케이션
Resource Server (리소스 서버): 사용자의 보호된 데이터를 호스팅하는 서버 (Google Drive, Kakao Profile)
Authorization Server (인가 서버): 사용자의 동의를 확인하고 클라이언트에 Access Token을 발급하는 서버

• 특징
  - 복잡한 애플리케이션 계층의 서명 방식 대신 전송 계층 보안(HTTPS/TLS)에 의존하여 보안을 유지하고 구현 생산성을 높였다.
  - 클라이언트의 특성(웹, 모바일, 서버 간 통신 등)에 따라 최적화된 4가지 이상의 승인 방식(Grant Types)을 제공한다.
  - 인증 서버와 리소스 서버의 역할을 명확히 분리하여 대규모 시스템 확장에 용이하도록 설계되었다.
  - 실제 데이터에 접근하기 위해 Access Token을 사용한다.

3. OpenID Connect (OIDC)

OAuth 2.0은 인가를 위한 프레임워크로 설계되었기 때문에 사용자가 누구인지 확인하는 인증 기능은 표준에 포함되어 있지 않았다. 이런 한계를 보완하기 위해 2014년 OAuth 2.0 프로토콜 계층 위에 구축된 신원 확인 표준이 OIDC이다.

OIDC는 OAuth 2.0의 흐름을 그대로 계승하면서도 사용자의 신원 정보를 담은 ID Token을 추가로 발행한다는 점이 핵심이다.

클라이언트가 인증 요청 시 scope 매개변수에 openid를 포함하면 서버는 Access Token과 함께 ID Token을 발급한다. 이 토큰은 JWT 형식을 사용하여 사용자의 신원 정보를 구조화한다.

클라이언트는 발급받은 ID Token을 직접 해독하여 사용자의 고유 식별자(sub), 이름, 이메일 등의 정보를 즉각 확인할 수 있다.

기존 OAuth 2.0에서는 사용자 정보를 얻기 위해 Access Token을 사용하여 유저정보 API를 추가로 호출해야 했으나 OIDC는 토큰 자체에 정보를 포함하고 있어 통신 횟수를 줄여준다.

또한 서비스 제공자들이 동일한 OIDC 규격을 따르므로 개발자는 표준화된 방식으로 다양한 플랫폼의 신원 정보를 처리할 수 있어 여러 서비스에서 하나의 계정으로 로그인 상태를 유지하는 단일 로그인(SSO) 시스템 구축의 필수 기술로 자리 잡았다.