Redirect URI Attestation

Expanded Definition

redirect uri attestation is a control concept for proving that an OAuth client, including an AI agent or MCP-connected workload, is authorised to receive responses only at approved callback endpoints. It sits at the intersection of client registration, metadata trust, and server-side enforcement, and it matters because the redirect endpoint is where authorization codes and tokens can be exposed if validation is loose. In practice, attestation may involve signed metadata, registry approval, or policy-backed proof that the callback URI is bound to the expected workload and publication process. That makes it closely related to the assurance goals described in the NIST Cybersecurity Framework 2.0, even though no single standard governs redirect URI attestation yet. Definitions vary across vendors, especially when “attestation” is used to describe everything from static allowlists to cryptographically verifiable endpoint claims. NHI Management Group treats the term as a governance control, not just a registration checkbox, because the trust decision must survive client drift, endpoint spoofing, and unauthorized metadata changes. The most common misapplication is assuming a registered redirect URI is safe simply because it appears in an app configuration, which occurs when server-side comparison and publication controls are not independently enforced.

Examples and Use Cases

Implementing redirect URI attestation rigorously often introduces registration and change-control overhead, requiring organisations to weigh stronger callback assurance against slower deployment and recovery cycles.

• A service account used by a CI/CD workflow exchanges OAuth responses only after its redirect endpoint is matched against a signed client registry entry.
• An MCP client publishes callback metadata through a controlled internal catalog, and the authorization server rejects any response target that is not on the approved list.
• A production AI agent rotates its callback endpoint during migration, but attestation blocks the change until the new URI is approved by policy and logged for audit.
• Security teams use the Ultimate Guide to NHIs as a reference for why metadata trust must be paired with lifecycle control, not treated as a one-time setup task.
• OAuth implementers compare the control to broader identity assurance guidance in the NIST Cybersecurity Framework 2.0 when deciding how to detect unauthorized callback drift.

Why It Matters in NHI Security

Redirect URI attestation reduces the chance that an attacker can redirect authorization responses to a malicious endpoint after compromising client configuration, deployment tooling, or metadata publication. For NHI and agentic systems, that matters because the callback is often the last checkpoint before a token, code, or delegated capability is issued. When attestation is weak, a seemingly minor config change can become a privilege escalation path, especially in environments where workloads, secrets, and service accounts already move faster than human review. NHI Management Group’s research shows that only 5.7% of organisations have full visibility into their service accounts, which makes endpoint trust even harder to validate in practice. That visibility gap turns redirect handling into a governance problem, not just an OAuth implementation detail. It also aligns with the broader NHI risk posture described in the same research, where excessive privilege and weak lifecycle controls amplify exposure. Organisations typically encounter redirect URI attestation as an urgent issue only after a token theft, callback hijack, or failed incident review, at which point the term becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is the difference between redirect URI validation and PKCE?
• How do teams know whether redirect URI management is under control?
• Who is accountable when a redirect URI migration breaks sign-in?
• Why do redirect URI mistakes create both reliability and security problems?