OpenID Connect 클레임과 ID 토큰

OpenID Connect(OIDC)는 OAuth 2.0 위에 신원 계층을 추가합니다. OAuth 2.0이 권한 부여(이 앱이 무엇에 액세스할 수 있는가?)를 처리한다면, OIDC는 신원에 관한 질문(사용자는 누구인가?)에 답합니다. OIDC는 OAuth 2.0 요청에 "openid" 범위를 추가하여 구현하며, 이로 인해 권한 부여 서버는 액세스 토큰과 함께 ID 토큰을 반환합니다.

OIDC ID 토큰은 인증된 사용자에 대한 클레임을 포함하는 JSON 웹 토큰(JWT)입니다. JWT는 일반적으로 RS256 또는 ES256을 사용하여 권한 부여 서버의 개인 키로 서명되며, 신뢰 당사자(클라이언트 애플리케이션)는 권한 부여 서버가 공개한 공개 키(JWKS 엔드포인트)를 사용하여 서명을 검증합니다.

필수이며 흔히 사용되는 ID 토큰 클레임: "sub"(주체, 고유 사용자 식별자), "iss"(발급자, 권한 부여 서버 URL), "aud"(대상, 클라이언트 ID), "exp"(만료 Unix 타임스탬프), "iat"(발급 시각 Unix 타임스탬프). 선택 사항: "auth_time"(인증이 수행된 시각), "nonce"(재생 방지), "at_hash"(액세스 토큰의 해시), "acr"(인증 컨텍스트 클래스), "amr"(사용된 인증 방식).

OIDC UserInfo 엔드포인트는 유효한 액세스 토큰으로 호출하면 인증된 사용자에 대한 추가 클레임을 반환합니다. 클라이언트는 범위를 통해 특정 클레임 집합을 요청합니다. "profile"(name, picture, locale), "email"(email, email_verified), "address"(formatted address), "phone"(phone_number, phone_number_verified). UserInfo 응답은 JSON 객체 또는 JWT입니다.

ID 토큰 검증은 서명 검증으로 시작합니다. 클라이언트는 잘 알려진 엔드포인트에서 권한 부여 서버의 JWKS(JSON 웹 키 집합)를 가져와 JWT 헤더의 "kid"(키 ID) 매개변수와 일치하는 키를 찾은 다음 JWT 서명을 검증합니다. 이를 통해 토큰이 정당한 권한 부여 서버에서 발급되었고 변조되지 않았음을 증명합니다.

서명 검증 후 클라이언트는 다음을 검증해야 합니다. "iss"는 예상한 권한 부여 서버 URL과 정확히 일치해야 합니다(스킴과 경로 포함). "aud"에는 클라이언트 자체의 client_id가 포함되어야 합니다. "exp"는 미래 시점이어야 합니다(만료된 토큰 거부). "iat"는 합리적으로 최근이어야 합니다. 이 네 가지 검사는 OIDC 사양에 따라 모두 필수입니다.

nonce 클레임은 ID 토큰 재생 공격을 방지합니다. 클라이언트는 임의의 nonce를 생성하여 권한 부여 요청에 포함합니다. 권한 부여 서버는 nonce를 ID 토큰에 넣습니다. 클라이언트는 ID 토큰의 nonce가 자신이 보낸 값과 일치하는지 검증합니다. 이를 통해 공격자가 탈취한 ID 토큰을 다른 세션에서 재사용하여 인증하는 것을 방지합니다.

OIDC가 암시적 흐름(response_type=id_token)을 사용하면 ID 토큰이 URL 프래그먼트에 직접 반환됩니다. 클라이언트는 액세스 토큰을 ID 토큰에 결합하기 위해 at_hash(액세스 토큰의 해시)를 검증해야 합니다. at_hash를 검증하지 않으면 액세스 토큰 대체 공격이 가능해집니다. 암시적 흐름이 폐기된 또 다른 이유가 바로 이것입니다.

OIDC는 표준 범위-클레임 매핑을 정의합니다. "openid" 범위는 필수이며 "sub" 클레임을 반환합니다. "profile"은 name, given_name, family_name, nickname, picture, website, locale, zoneinfo, updated_at을 반환합니다. "email"은 email과 email_verified를 반환합니다. 불필요한 범위를 요청하면 최소 공개 원칙을 위반하고 민감한 사용자 데이터가 노출될 수 있습니다.

OIDC 다중 제공자 로그인(예: "Google로 로그인" 및 "GitHub로 로그인")을 구현할 때 클레임 주입 공격이 발생할 수 있습니다. 공격자가 제공자 A를 사용하는 피해자의 이메일 주소로 제공자 B에 계정을 만들면, 애플리케이션이 이메일 클레임만으로 계정을 매칭할 경우 공격자가 액세스 권한을 얻을 수 있습니다. 항상 이메일만이 아니라 (iss, sub) 쌍으로 계정을 매칭해야 합니다.

OIDC 하이브리드 흐름(response_type=code id_token)은 권한 부여 엔드포인트에서 권한 부여 코드와 ID 토큰을 모두 반환합니다. ID 토큰을 사용하면 즉시 신원을 검증할 수 있고, 코드는 백채널을 통해 토큰으로 교환됩니다. 백채널 토큰 교환을 완료하기 전에 사용자 정보를 즉시 렌더링해야 할 때 사용합니다.

신뢰 당사자는 OIDC ID 토큰에서 어떤 클레임 조합을 검증해야 합니까?

OIDC는 OAuth 2.0 흐름에 서명된 JWT ID 토큰을 추가합니다. 서명(JWKS), iss(정확히 일치), aud(client_id), exp(만료되지 않음), nonce(전송된 경우)를 검증해야 합니다. UserInfo 엔드포인트는 범위를 통해 추가 클레임을 제공합니다. 클레임 주입을 방지하려면 이메일만으로 계정을 매칭하지 말고 항상 (iss, sub) 쌍으로 매칭해야 합니다. 암시적 흐름은 폐기되었으므로 OIDC에는 PKCE를 사용하는 권한 부여 코드 흐름을 사용해야 합니다.