OIDC란 무엇인가: 왜 필요한지 그리고 어떻게 작동하는지

OpenID Connect (OIDC) 정의#

OpenID Connect (OIDC)는 OAuth 2.0 위에 구축된 신원 인증 프로토콜입니다. OAuth 2.0이 인증만 제공하는 반면, OIDC는 인증 기능을 추가하여 사용자 인증 및 인증 시나리오에 대한 보다 표준화된 솔루션을 제공합니다.

간단히 말해: OIDC = 인증 프로토콜 + 신원 인증.

OIDC가 필요한 이유?#

OIDC가 왜 필요한지를 이해하기 위해 먼저 OAuth 2.0의 핵심 개념과 워크플로우를 탐색하고, 실용적인 응용에서의 제한을 살펴 보겠습니다. 특정 시나리오 분석을 통해 왜 OAuth 2.0보다 OIDC가 필요한지 확인할 것입니다.

OAuth 2.0의 주요 개념과 인증 흐름#

OAuth 2.0(Open Authorization)은 사용자 이름 및 암호와 같은 자격 증명을 공유하지 않고도 사용자가 제3자 애플리케이션에 자신의 리소스에 대한 액세스를 허용하는 인증 프로토콜입니다. 네 가지 주요 역할이 포함됩니다:

• 리소스 소유자: 리소스를 소유한 사용자
• 리소스 서버: 사용자 리소스를 저장하는 서버
• 클라이언트: 사용자 리소스에 액세스를 요청하는 제3자 애플리케이션
• 인증 서버: 사용자 신원을 확인하고 액세스 토큰을 발급하는 서버

일반적인 OAuth 2.0 인증 흐름은 다음과 같습니다:

표시된 바와 같이, OAuth 2.0은 주로 제3자 클라이언트가 사용자 리소스에 접근할 수 있는 액세스 토큰 발급을 처리합니다.

OAuth 2.0의 제한점#

OAuth 2.0 프로토콜은 액세스 토큰 발급에 중점을 둡니다. 리소스 서버는 이 토큰을 검증하고 승인된 리소스를 반환합니다. 그러나 리소스 서버는 사용자의 신원을 알지 못합니다.

이는 초기 인터넷 생태계에서는 큰 문제가 아니었습니다.

그러나 Google, Facebook, Twitter, Github와 같은 플랫폼이 발전함에 따라 제3자 애플리케이션에 유용한 풍부한 사용자 리소스를 제공하기 시작했습니다.

OAuth 2.0이 제3자 액세스를 사용자 리소스에 승인하는 데는 뛰어나지만, 제한이 있습니다. 일반적인 시나리오는 사용자 정보도 리소스이기 때문에 제3자 애플리케이션이 기본적인 사용자 정보에 접근해야 할 때, 다양한 플랫폼(Google, Facebook, Twitter 등)이 서로 다른 형식으로 사용자 정보를 반환하므로 개발자에게 도전을 줍니다.

OIDC는 이러한 문제를 해결하기 위해 만들어졌습니다.

OIDC의 역할#

OAuth 2.0 위에 사용자 인증을 가능하게 하고 그 제한점을 해결하기 위해 OIDC는 세 가지 역할을 도입했습니다:

• 최종 사용자(EU): 최종 사용자, OAuth 2.0의 리소스 소유자에 해당
• 의존 당사자(RP): 의존하는 당사자, OAuth 2.0의 클라이언트에 해당
• OpenID 공급자(OP): 신원 인증 서비스 공급자, OAuth 2.0의 인증 서버 및 리소스 서버에 해당

OP는 핵심 역할로, OAuth 2.0의 인증 기능을 제공함과 동시에 사용자 정보를 별도의 리소스로 처리합니다.

OIDC는 어떻게 작동하나요?#

OIDC의 인증 프로세스는 OAuth 2.0과 유사하지만, OP가 인증 서버와 리소스 서버의 역할을 결합하여 액세스 토큰과 ID 토큰을 반환합니다. ID 토큰은 사용자 신원 정보를 포함하고 있으며, RP는 ID 토큰을 검증하여 사용자의 신원을 확인할 수 있습니다.

일반적인 워크플로우는 다음과 같습니다:

이는 다양한 플랫폼 간에 사용자 정보를 얻는 방법을 표준화하여, 제3자 애플리케이션이 플랫폼별 차이를 처리할 필요가 없습니다.

OIDC의 ID 토큰 (신원 토큰)#

사용자가 제3자 애플리케이션을 승인할 때, OP는 OAuth 2.0 액세스 토큰과 JWT 형식의 ID 토큰을 모두 반환합니다. 이 ID 토큰은 사용자 ID, 사용자 이름, 이메일 및 아바타와 같은 사용자 신원 정보를 포함합니다. RP는 ID 토큰을 검증하여 사용자의 신원을 확인할 수 있습니다.

ID 토큰은 JWT 형식으로, iss(발급자), sub(주체), aud(청중), exp(만료 시간), iat(발급 시간)과 같은 표준화된 클레임을 포함합니다:

• iss (발급자): ID 토큰을 발급한 OpenID 공급자의 고유 식별자
• sub (주체): 사용자의 고유 식별자
• aud (청중): ID 토큰을 수신하는 클라이언트 애플리케이션의 식별자
• exp (만료 시간): ID 토큰이 만료되는 시간
• iat (발급 시각): ID 토큰이 발급된 시각

ID 토큰에 대한 자세한 정보는 다음을 참조하세요: ID token.

Userinfo 엔드포인트#

Userinfo 엔드포인트는 OP에서 인증된 사용자 세부 정보를 얻기 위해 제공하는 표준 HTTP API입니다. 이 엔드포인트에 액세스 토큰으로 GET 또는 POST 요청을 보내면 JSON 형식의 사용자 정보를 받을 수 있습니다. 반환된 데이터에는 고유 사용자 ID(sub), 사용자 이름(name), 이메일 및 사진과 같은 표준화된 필드가 포함됩니다.

Userinfo를 얻는 프로세스는 OAuth 2.0에서 보호된 리소스에 액세스하는 방식과 동일한 패턴을 따릅니다. 일반적으로 userinfo 엔드포인트에서 얻은 사용자 정보는 ID 토큰에 있는 것보다 더 포괄적입니다. 이는 ID 토큰이 주로 신원 확인 및 기본 사용자 정보를 목적으로 하기 때문입니다.

Userinfo 엔드포인트에 대한 자세한 정보는 다음을 참조하세요: Userinfo endpoint.

주의할 점은 userinfo 엔드포인트에서 수신한 사용자 정보는 요청된 범위와 승인 중 부여된 권한에 따라 달라집니다.

OIDC의 범위#

OIDC의 범위는 RP가 액세스할 수 있는 사용자 정보를 정의합니다. OIDC는 표준 범위를 정의하며, openid 범위는 OIDC 인증 흐름에서 필수적입니다.

일반적인 표준 범위에는 다음이 포함됩니다:

• openid: OIDC 인증 요청을 나타냅니다
• profile: 이름과 아바타와 같은 기본 사용자 정보
• email: 사용자의 이메일 정보
• phone: 사용자의 전화번호
• address: 사용자의 주소 정보

다른 범위는 다른 사용자 정보를 반환합니다. 예를 들어, openid profile email을 요청하면 ID 토큰과 Userinfo에서 기본 사용자 정보와 이메일을 반환하며, openid profile email phone address는 전화번호와 주소 정보를 포함합니다.

OIDC를 기반으로 한 신원 관리#

OIDC는 단순한 인증 프로토콜이 아니라 유연하고 확장 가능한 신원 관리 시스템을 구축할 수 있는 강력한 도구입니다. OAuth 2.0에 인증 레이어를 추가하고 사용자 정보 리소스를 표준화하며, 확장된 신원 관리 기능의 기초를 마련함으로써 OIDC는 다양한 신원 관리 시나리오를 가능하게 합니다:

• 싱글 사인온(SSO): OIDC는 확장된 사용자 세션 정보를 통해 자연스럽게 SSO를 지원하여 통합된 로그인 상태 관리 및 크로스 애플리케이션 신원 공유를 가능하게 합니다
• 조직 구조 관리: 확장된 사용자 조직 정보는 복잡한 조직 구조, 부서 계층 구조 및 사용자 그룹 관계를 관리할 수 있습니다
• 권한 관리: 확장된 사용자 권한 속성은 세밀한 리소스 액세스 제어, 역할 정보 및 권한 정책 설정을 가능하게 합니다

OIDC의 유연성은 진화하는 신원 관리 요구에 적응합니다. 많은 신원 관리 시스템들이 OIDC를 기반으로 구축되었으며, Logto와 같이 SSO, 조직 관리 및 권한 관리 기능을 제공합니다.