요약

  • RFC 9207은 OAuth 클라이언트에 좁은 영수증을 제공합니다. 인가 응답에 명시된 issuer는 해당 요청을 위해 기록된 issuer와 일치해야 하며, 불일치 시 클라이언트는 코드나 토큰을 잘못된 엔드포인트로 보내기 전에 플로우를 중단합니다.
  • iss값은 인가 서버 컨텍스트를 식별합니다. 사용자를 인증하거나, 인가 코드를 검증하거나, 토큰 발급을 증명하거나, audience나 scope를 확립하거나, 리소스 서버가 작업을 수락했음을 보여주지 않습니다.
  • 따라서 안전한 운영은 요청 상태, 예상 issuer, 메타데이터, 반환된 issuer, 비교 및 중단 결과, 코드 교환, 토큰 검증, 리소스 판단, 복구를 위한 별개의 기록을 연결해야 합니다.

위험한 콜백은 평범해 보입니다.

브라우저는 등록된 리디렉션 URI로 돌아옵니다.state값은 클라이언트가 생성한 값과 일치합니다. 응답에는 정직한 인가 서버가 생성한 인가 코드가 담겨 있습니다. 비밀번호가 피싱되지 않았고 코드가 위조되지도 않았습니다. 그러나 여러 인가 서버와 작동하는 클라이언트는 여전히 치명적인 라우팅 실수를 할 수 있습니다. 즉, 그 정직한 코드를 공격자가 통제하는 토큰 엔드포인트로 보낼 수 있습니다.

오류는 각각 개별적으로는 그럴듯한 두 기록 사이에 있습니다. 하나는 요청이 시작될 때 클라이언트가 사용하던 인가 서버를 말하고, 다른 하나는 사용자의 브라우저를 통해 전달된 인가 응답입니다. OAuth 2.0의 원래 응답은 응답을 생성한 서버를 명시적으로 식별하지 않았습니다. 클라이언트가 브라우저 라우팅, 일반 콜백 또는 적대적 메타데이터로 이 기록들을 뒤섞게 되면, 유효한 코드가 잘못된 운영자의 손에 들어갈 수 있습니다.

RFC 9207은 이 간극에 의도적으로 작은 수리를 제공합니다. 2022년 3월 IETF Standards Track 문서로 발표된OAuth 2.0 Authorization Server Issuer Identification은 Karsten Meyer zu Selhausen과 Daniel Fett의 공동 작업입니다. 이 문서는 인가 응답을 위한iss파라미터를 정의합니다. 이 사양을 지원하는 서버는 성공 응답과 오류 응답에 자신의 issuer 식별자를 포함합니다. 클라이언트는 이 값을 요청을 보낸 인가 서버에 대해 기록한 issuer와 비교합니다.

두 문자열이 일치하지 않으면 클라이언트는 응답을 거부하고 그랜트를 진행하지 않습니다.

이것이 이 필드의 전부이며, 바로 그렇기 때문에 중요합니다.

콜백에는 발신자가 없었다

OAuth는 의도적으로 역할을 분리합니다. 리소스 소유자는 사용자 에이전트를 사용합니다. 클라이언트는 인가 서버에 그랜트를 요청합니다. 클라이언트는 나중에 그 그랜트를 토큰 엔드포인트에 제시합니다. 액세스 토큰은 최종적으로 리소스 서버에서 사용됩니다. 이 분리 덕분에 많은 서비스가 결합될 수 있지만, 동시에 브라우저의 도착만으로는 안전성을 추론할 수 없는 라우팅 선택을 만들어 냅니다.

RFC 6749는 인가 응답에 코드와, 요청에 포함된 경우 동일한state값을 부여했습니다. 이 state는 필수적입니다. 응답을 사용자의 인증된 브라우저 상태에 결합하고 교차 사이트 요청 위조를 방지하는 데 도움을 줍니다. 그러나 다른 질문에는 답하지 않습니다. 어느 인가 서버가 이 응답을 발급했는가?

인가 서버를 하나만 구성한 클라이언트에게는 경쟁하는 엔드포인트 번들이 없기 때문에 이 구분이 보이지 않을 수 있습니다. 그러나 두 번째 서버를 추가하면 클라이언트는 "OAuth 플로우가 대기 중"이라는 것 이상을 기억해야 합니다. 어느 issuer가 그 플로우를 소유하는지 기억해야 합니다. 현재의 OAuth 보안 Best Current Practice인 RFC 9700은 이 규칙을 명확히 진술합니다. 다중 인가 서버 클라이언트는 mix-up 공격을 방지하고 각 인가 요청에 의도된 issuer를 결합해야 합니다.

이것은 공동 표준을 개인 신화로 만들지 않고 Daniel Fett의 공개 연구 기록을 보여주는 유용한 사례입니다. Fett의 1차 사이트는 신원 및 웹 프로토콜 보안, OAuth 및 OpenID Connect에 관한 그의 작업을 설명합니다. 2026년 9월 기준으로 그의 IETF 기록에는 네 개의 RFC 중 RFC 9207이 포함되어 있습니다. 이 사실들은 문제의 연속성을 설명합니다. 그러나 이가 응답 파라미터의 단독 발명자이거나 배포된 클라이언트의 운영자라는 뜻은 아닙니다.

하나의 issuer, 하나의 엔드포인트 번들

issuer 식별자는 단순한 표시 이름이 아닙니다. RFC 8414에 따라 쿼리나 프래그먼트가 없는 HTTPS URL입니다. 이는 인가 엔드포인트, 토큰 엔드포인트, 키 위치 및 기타 기능을 식별할 수 있는 인가 서버 메타데이터 문서를 고정합니다. 단일 호스트명이 경로로 구분되는 여러 issuer를 호스팅할 수도 있습니다.

그 번들이 위험에 노출된 경제적·운영적 대상입니다. 클라이언트는 사용자에게 정직한 인가 페이지를 보여주면서도 공격자가 통제하는 토큰 엔드포인트로 구성될 수 있습니다. RFC 9700은 인가 엔드포인트 URL만 저장하는 것으로는 충분하지 않다고 경고합니다. 악의적인 당사자는 정직한 인가 엔드포인트를 주장하면서 자신의 토큰 엔드포인트를 선언할 수 있습니다. 클라이언트는 사용하려는 엔드포인트 집합의 안정적인 식별자로 issuer를 필요로 합니다.

RFC 9207은 브라우저로 전달된 응답을 그 집합에 다시 연결합니다. 메타데이터가 사용될 때 응답의iss는 메타데이터의issuer와 정확히 일치해야 하며, 메타데이터는authorization_response_iss_parameter_supported를 true로 광고할 수 있습니다. 클라이언트는 반환된 값을 추출하고, 폼 인코딩을 디코딩하고, 요청에 대해 예상되는 issuer와 단순 문자열 비교를 수행합니다.

퍼지 정규화는 허용되지 않습니다. 경로 차이, 예상치 못한 슬래시, 동일 호스트의 다른 issuer는 "거의 비슷"하지 않습니다. 요점은 사람의 유사성이 아니라 결정론적 라우팅입니다.

비교는 로컬 결정 표면을 만듭니다. 인가 서버는 자신의 신원을 진술합니다. 메타데이터는 엔드포인트 번들을 설명합니다. 클라이언트는 자신이 선택한 issuer를 기록하고, 서버의 지원 상태를 유지하고, 반환된 값이 수용 가능한지 판단합니다. 그 비교를 실행하는 전역 조정자는 없습니다. 각 클라이언트가 구성과 중단을 소유합니다.

일치는 계속할 권한이지 완료의 증명이 아니다

iss를 오용하는 가장 깔끔한 방법은 그것에 너무 많은 의미를 부여하는 것입니다.

issuer가 일치한다고 리소스 소유자가 인증되는 것은 아닙니다. 인가 서버는 여전히 로그인을 요구하거나 오류를 반환할 수 있습니다. 사용자가 요청된 scope를 이해했거나 의도했다는 증명도 되지 않습니다. 그것은 인가 상호작용과 애플리케이션 정책의 영역입니다.

일치는 인가 코드를 검증하지도 않습니다. 클라이언트가 올바른 토큰 엔드포인트를 선택한 후에도, 그 엔드포인트는 코드, 해당되는 경우 클라이언트 신원, 리디렉션 URI 및 기타 그랜트 조건을 여전히 검증해야 합니다. 코드는 만료되었거나, 재사용되었거나, 다른 클라이언트에 결합되었거나, 기타 이유로 무효할 수 있습니다.

일치는 토큰이 발급되었다는 증명도 아닙니다. 그것 자체로는 토큰 유형, audience, scope, 수명, 발신자 제약 또는 폐기 상태에 대해 아무것도 말하지 않습니다. 리소스 서버는 토큰이 제시될 때 자체 판단을 해야 합니다. 유효하고 올바르게 스코프된 토큰조차도 애플리케이션 작업이 성공했거나 사용자가 기대한 결과를 받았다는 증명이 되지 않습니다.

따라서 영수증은 다음과 같은 순서를 이룹니다.

  1. 클라이언트가 요청을 생성하고 의도된 issuer를 브라우저 결합 state와 함께 저장했습니다.
  2. 브라우저가 인가 응답을 반환했습니다.
  3. 응답이 issuer를 명시했습니다.
  4. 클라이언트는 그 issuer를 저장된 issuer와 비교하고 수용하거나 중단했습니다.
  5. 클라이언트는 검증된 메타데이터 또는 동등한 정적 구성에서 엔드포인트를 선택했습니다.
  6. 토큰 엔드포인트가 코드를 수락하거나 거부했습니다.
  7. 모든 토큰은 리소스 서버에 의해 검증되고 강제되었습니다.
  8. 애플리케이션은 결과를 관찰하고 조사하거나 되돌릴 수 있는 충분한 증거를 유지했습니다.

RFC 9207은 4단계를 소유합니다. 4단계를 "OAuth 성공"이라고 부르면 그 이후의 모든 판단이 지워집니다.

이 필드는 서명이 아니다

일반 인가 응답의iss파라미터는 암호학적으로 보호되지 않습니다. RFC 9207이 직접 그렇게 말합니다. 이것이 모순처럼 들리는 것은 필드를 보편적인 인증 인증서로 취급할 때뿐입니다.

명시된 위협은 더 좁습니다. mix-up 공격에서 클라이언트는 침해되지 않은 인가 서버가 생성한 응답을 받지만 어느 엔드포인트 집합이 코드를 받아야 하는지에 대해 혼란에 빠집니다. 공격자가 클라이언트가 받기 전에 그 정직한 응답을 변경할 수 있다면, 공격자는 이미 인가 코드를 읽을 수 있으며 mix-up 경로를 필요로 하지 않습니다. 이 필드는 모델 내부의 라우팅 혼란을 방지합니다. 모든 공격자에 대한 무결성을 주장하지 않습니다.

무결성이 보호된 인가 응답이 필요한 곳에서는 다른 메커니즘이 issuer를 전달할 수 있습니다. 예를 들어 JARM은 응답 파라미터를 서명된 JWT에 넣습니다. 인가 엔드포인트에서 ID 토큰을 반환하는 OpenID Connect 플로우도 필수 규칙에 따라 클라이언트가 검증하는 경우 issuer를 전달할 수 있습니다. 여러 issuer 식별자가 나타나고 서로 불일치하면 응답을 거부해야 합니다.

이것은 실천된 최소 초기 사양입니다. 모호성을 노출하는 가장 작은 공유 신호를 추가합니다. 더 강한 봉투, 지원 서버 정책, 마이그레이션 선택은 필요로 하는 시스템에 맡깁니다. 이 필드는 대체 방어를 금지하지 않습니다. RFC 9700은 클라이언트가 올바르게 검사하는 경우 issuer별 고유 리디렉션 URI도 허용합니다.

레거시 지원은 명시적 정책이다

현실의 클라이언트는 모든 인가 서버를 한 번에 업그레이드하지 않습니다. 따라서 RFC 9207은 배포가 보편적이라고 가장하는 대신 지원 상태를 구분합니다.

파라미터를 지원하는 서버를 아는 클라이언트는iss가 없을 때 그 서버로부터의 응답을 거부해야 합니다. 서버는 메타데이터에서 지원을 광고할 수 있습니다. 서버가 파라미터를 지원하지 않는 것으로 알려진 경우, 클라이언트는 없이도 응답을 수용하거나 그런 서버를 완전히 거부할 수 있습니다. 로컬 구성이 결정합니다. 서버가 지원을 광고하지 않고iss를 보낼 때 클라이언트는 신중해야 합니다. 계획에 없는 파라미터는 일관성 없는 구성의 신호일 수 있습니다.

이 유연성은 허점이 아닙니다. 운영자 책임이 살아 있는 곳입니다. 다중 issuer 클라이언트는 issuer 목록, 그들의 엔드포인트 메타데이터, 예상되는 지원 비트, 그 믿음의 날짜와 출처, 존재하는 경우 레거시 예외, 그리고 그것을 제거할 수 있는 소유자가 필요합니다. 그렇지 않으면 "호환성"이 방어를 우회하는 무기한 경로가 됩니다.

이 전환은 시스템이 두 번째 인가 서버를 추가할 때도 변화를 일으킵니다. 단일 issuer 클라이언트는 오늘 mix-up 방어가 필요하지 않을 수 있습니다. 또 다른 issuer를 추가하는 순간, 오래된 가정은 만료됩니다. 따라서 제품 확장은 보안 마이그레이션을 만듭니다. 새 공급자가 서비스에 들어오기 전에 issuer 상태가 요청별로 되어야 합니다.

운영자가 실제로 테스트할 수 있는 영수증

표준 적합성은 메타데이터를 한 번 읽는 것으로 확립할 수 없습니다. 유용한 운영 테스트는 요청 생성에서 시작하여 분기를 따라갑니다.

요청 식별자, 사용자 에이전트 결합, 선택된 issuer, 메타데이터 버전, 인가 및 토큰 엔드포인트, 지원 플래그, 리디렉션 URI를 기록하십시오. 반환 시iss의 존재 여부, 디코딩된 값, 정확한 예상 값, 비교 결과, 불일치 시 코드 교환이 억제되었는지 여부를 기록하십시오. 성공 응답, 인가 오류, 누락된 값, 중복 값, 알 수 없는 issuer, 서로 다른 경로를 가진 issuer가 호스트를 공유하는 두 issuer를 테스트하십시오.

그런 다음 부정적 약속을 검증하십시오. issuer가 불일치할 때, 코드, 클라이언트 자격 증명 또는 토큰을 포함하는 요청이 예상치 못한 엔드포인트에 도달해서는 안 됩니다. 클라이언트와 통제된 테스트 엔드포인트의 로그가 일치해야 합니다. 차단된 네트워크 요청 없이 사용자에게 보이는 오류만으로는 방어 영수증이 아닙니다.

마지막으로, 인시던트 보고에서 계층을 분리하여 유지하십시오. issuer 불일치는 실패한 신원 비교를 식별할 뿐, 침해를 증명하지 않습니다. 토큰 엔드포인트 거부는 그 엔드포인트가 하나의 그랜트를 거부했다는 증명일 뿐, 인가 응답이 악의적이었다는 증명이 아닙니다. 리소스 거부는 issuer 결합이 작동했다는 소급 증거가 아닙니다. 각 이벤트는 서로 다른 불확실성을 좁힙니다.

이 필드는 하나의 모호성을 무시할 수 없게 만들 때 성공합니다. 클라이언트가 자격 증명을 이동하기 전에 비교할 수 있는 이름을 제공합니다. 클라이언트, 인가 서버, 토큰 엔드포인트 또는 리소스 서버가 단독으로 내려야 하는 판단을 면제하지는 않습니다.

출처