요약

  • RFC 7662는 보호 리소스가 권한 부여 서버에 토큰이 현재 활성 상태인지 묻고 해당 리소스에 관련된 메타데이터를 받을 수 있게 한다.
  • active: true는 의미 있는 토큰 상태 결론이지만, 요청된 애플리케이션 작업의 승인도, 실행 기록도, 지속적인 결과 영수증도 아니다.
  • 인트로스펙션 응답을 캐싱하면 교환의 부하와 지연이 줄어드는 대신 최신성이 희생되므로, 운영자는 토큰 상태, 권한 부여 정책, 비즈니스 결과를 별도의 증거 평면에 유지해야 한다.

적용 범위가 정해진 초록불

토큰 인트로스펙션의 매력은 이해하기 쉽다. 베어러 토큰이 모든 속성을 로컬에서 검증할 수 없거나 검증하고 싶지 않은 API에 도달한다. API는 토큰을 인트로스펙션 엔드포인트로 보낸다. 권한 부여 서버가 이를 평가하고 유일한 필수 멤버가active인 JSON 객체를 반환한다. false 응답은 문의를 깔끔하게 끝낸다. true 응답은 계속 진행하는 데 필요한 스코프, 클라이언트, 사용자, 토큰 유형, 만료, 대상, 발급자 및 기타 사실을 돌려줄 수 있다.

그 답은 형식적인 의례가 아니다. RFC 7662에 따르면 활성 토큰은 일반적으로 권한 부여 서버가 발급했고, 취소되지 않았으며, 유효 기간 안에 있는 토큰이다. 권한 부여 서버는 만료, 사용 시작 전 시각, 취소, 서명을 포함해 해당 토큰에 적용되는 검사를 수행해야 한다. 또한 호출하는 보호 리소스에서 그 토큰을 사용할 수 있는지도 고려해야 한다.active를 “엔드포인트가 200을 반환했다”로 축소하는 서비스는 프로토콜의 핵심 결론을 버리는 것이다.

반대쪽 실수는 그 결론에 원래보다 큰 관할 범위를 부여하는 것이다. 인트로스펙션은 권한 부여 서버가 호출자에 대해 토큰에 관해 확립할 수 있는 것을 보고한다. 그것은 보호 리소스의 전체 애플리케이션 상태를 갖지 않는다. 토큰 상태만으로 청구서가 이미 결제됐는지, 거래 한도가 소진됐는지, 기록이 법적 보존 상태인지, 유지보수 창이 요청 작업을 닫았는지는 알 수 없다.

따라서 유용한 문장은 정확하다. 이 토큰은 현재 이 보호 리소스에서 권한 부여 증거로 사용할 수 있다. 위험한 축약은 더 넓다. 요청이 승인됐다.

Richer의 경계는 판결이 아니라 인터페이스다

Justin Richer는 OAuth 2.0 토큰 인트로스펙션에 관한 IETF 표준 트랙 명세 RFC 7662에 이름을 올린 인물이다. 이 문서는 두 종류의 권한 사이의 경계를 공식화한다. 권한 부여 서버는 토큰 수명 주기와 그 뒤의 그랜트를 안다. 보호 리소스는 시도되는 작업, 그 작업이 영향을 미칠 객체, 이를 규율하는 로컬 정책을 안다.

OAuth의 기본 역할 모델은 이 분리를 드러낸다. 클라이언트는 액세스 토큰을 리소스 서버에 제시한다. 리소스 서버는 토큰을 검증하고 요청이 수용 가능하면 보호 리소스를 제공한다. 인트로스펙션은 그 서버가 검증 사실을 얻는 표준화된 방법 중 하나다. 그것은 리소스 서버의 정책 책임을 권한 부여 서버로 이전하는 것이 아니다.

계정 업데이트에 적절해 들리는 스코프를 가진 활성 토큰을 가정하자. 리소스 서버는 여전히 요청을 거부할 수 있다. 계정이 다른 테넌트에 속해 있거나, 호출자가 승인된 네트워크 밖에 있거나, 제안된 값이 한도를 위반하거나, 더 강한 인증 이벤트가 필요하거나, 클라이언트가 마지막으로 읽은 뒤 객체가 변경됐기 때문이다. 반대로 리소스 서버는 문서화된 로컬 정책에 따라 간결한 스코프를 여러 작업에 매핑할 수 있다. RFC 7662는 그 매핑을 제공하거나 감사하지 않는다.

그래서 “권한 부여”에는 두 수준의 설명이 필요하다. 권한 부여 서버는 위임된 자격 증명에 관한 사실을 말할 수 있다. 애플리케이션은 그 사실이 구체적 요청의 정책을 충족하는지 결정해야 한다. 둘을 합치면 마지막 관문에 책임자가 없는 초록불 이벤트가 만들어진다.

답은 누가 묻는지에 따라 달라질 수 있다

인트로스펙션은 반드시 보편적인 신상 정보 파일일 필요는 없다. RFC 7662는 권한 부여 서버가 질의하는 보호 리소스에 맞춰 응답을 조정할 수 있게 한다. 서로 다른 호출자에게 다른 정보를 반환할 수 있고, 공개하는 스코프를 해당 리소스에 관련된 것으로 제한할 수 있다. 따라서 같은 토큰이 서로 다르지만 모두 유효한 답을 낳을 수 있다.

이 속성은 운영상 중요하다. 한 API에서 복사한 인트로스펙션 로그는 다른 API가 무엇을 알거나 할 자격이 있었는지 자동으로 증명하지 않는다. 대상과 리소스 맥락이 증거와 함께 이동해야 한다. RFC 8707은 관련된 구분을 강화한다. 리소스 표시자는 액세스 토큰이 어디에서 사용되도록 의도됐는지 식별하는 데 도움을 주고, 스코프는 요청된 액세스를 설명한다. 목적지와 권한은 상호 보완적 제약이며, 어느 것도 비즈니스 작업 결과는 아니다.

선택적 응답 멤버에도 같은 절제가 필요하다.exp와nbf는 시간을 제한한다.aud와iss는 대상과 발급자를 식별하는 데 도움을 준다.client_id,username,sub는 토큰과 배포에 따라 서로 다른 참여자나 주체를 식별한다.jti는 토큰 식별자다. 어느 것도 감사 행에 넣기 편하다는 이유만으로 청구서 번호, 작업 키, 데이터베이스 커밋 ID가 되지 않는다.

활성 답변 안에는 시계가 있다

“활성”이라는 단어는 현재 시제처럼 들리지만, 분산 시스템은 특정 시점에 알던 것만 보고할 수 있다. RFC 7662는 보호 리소스가 인트로스펙션 응답을 캐시할 수 있음을 명시적으로 허용한다. 이유는 실용적이다. 캐시는 권한 부여 서버 부하를 줄이고 모든 보호 요청에서 네트워크 지연을 제거할 수 있다. 비용도 똑같이 명시적이다. 더 긴 캐싱은 답변의 최신성을 약화한다.

10:00에 인트로스펙션된 토큰이 5분 동안 활성으로 캐시됐다고 하자. 10:01에 보유자가 RFC 7009에서 표준화한 메커니즘으로 이를 취소하거나, 관리자가 기반 그랜트를 무효화한다. 캐시가 만료될 때까지 보호 리소스는 이전 답변에 따라 계속 행동할 수 있다. 두 구성 요소 모두 구성된 규칙에 따라 동작하고 있을 수 있다. 이 불일치는 시간적이며, 반드시 소프트웨어 결함은 아니다.

따라서 캐시 수명은 보안 결과를 수반하는 정책 결정이다. 이는 토큰 수명, 취소 기대치, 작업 민감도, 권한 부여 서버 가용성, 오래된 허용의 비용과 관련되어야 한다. 공개 카탈로그 읽기와 권한 있는 계정 복구 작업이 인트로스펙션 클라이언트를 공유한다는 이유만으로 같은 최신성 예산을 물려받아서는 안 된다.

취소도 이미 일어난 일을 되돌리지 않는다. RFC 7009는 토큰을 무효화하고, 서버에 따라 관련 그랜트나 토큰도 무효화한다. 그러나 배송을 취소하거나 자금 이체를 되돌리거나 이미 변경된 데이터를 지우지는 않는다. 토큰 수명 주기는 향후 자격 증명 수용을 규율한다. 애플리케이션 교정은 효과를 규율한다.

검증은 영수증이 아니다

마지막 경계는 권한 부여 뒤에 나타난다. 보호 리소스는 요청을 수용하고도 커밋 전에 실패할 수 있다. 변경을 커밋하고도 응답을 잃을 수 있다. 큐는 소비자가 나중에 거부할 작업을 수용할 수 있다. 두 번의 재시도가 여전히 활성인 같은 토큰을 갖고 각각 정책을 통과하면서 하나의 인간 의도—혹은 두 개—를 가리킬 수 있다.

어떤 인트로스펙션 멤버도 그 모호성을 해소하지 않는다.jti는 하나의 토큰과 관련된 활동을 연관지을 수 있지만, 하나의 토큰은 보통 많은 요청을 승인한다. 스코프는 개별 작업을 명명하지 않고 작업 클래스를 제한할 수 있다. 인트로스펙션 트랜잭션 자체는 기록될 수 있지만, 그 성공적 완료는 토큰 정보가 반환됐다는 것만 증명한다.

중대한 결과를 낳는 API에는 자체적인 지속 작업 ID가 필요하다. 이들은 멱등성 키, 클라이언트 제공 명령 ID, 조건부 버전 또는 다른 도메인별 메커니즘을 사용할 수 있다. 또한 타임아웃 후 조회할 수 있는 결과가 필요하다. 인증 증거, 리소스 서버의 권한 부여 결정, 작업 ID, 커밋 결과, 응답 전달은 관측 시스템이 나중에 이들을 조인하더라도 별도 기록으로 남아야 한다.

요점은 토큰 인트로스펙션을 깎아내리는 것이 아니다. 시스템의 나머지 부분을 대신한다고 요구하지 않고 사용하는 것이다. Richer의 명세는 보호 리소스가 토큰의 현재 상태에 관해 좁고 어려운 질문을 규율 있는 방식으로 물을 수 있게 한다. 좋은 아키텍처는 그 답변이 관찰한 적 없는 결정과 이벤트에 대해 증언하게 만들기를 거부함으로써 답변의 강도를 보존한다.

출처