{
  "id": 10030588,
  "title": "A security researcher told me to close my OAuth registration endpoint. I said no.",
  "url": "https://urgent.news/2026/09/26/a-security-researcher-told-me-to-close-my-oauth-registration-endpoint",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-26T17:30:58.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/nativecode/a-security-researcher-told-me-to-close-my-oauth-registration-endpoint-i-said-no-46c7"
  },
  "original_language": "en",
  "account": "Last week, I received a security report regarding my QR code service. The report outlined two recommendations that, if implemented, would have compromised the product. The report claimed that the OAuth registration endpoint should require an Initial Access Token and manual app review before allowing registration. However, the recommended changes would effectively disable the dynamic registration functionality, which is essential for the product's operation.\n\nThe problem with the report was that it misunderstood the purpose of open dynamic client registration as defined in RFC 7591. This registration mode is specifically designed to facilitate the quick and secure establishment of OAuth connections between clients and servers, without the need for human intervention. The report's proposal, therefore, amounted to turning off the very feature that the service relies on.\n\nAnother suggestion in the report was to enforce a redirect URI allowlist. However, this is an impossible task for dynamically registered clients since their redirect URIs do not exist until they are registered. The correct approach is to verify that the redirect URI registered for a client matches one provided by the client at the time of authorization. This verification is already implemented in the service, which checks if the redirect URI is registered for the client before proceeding with the authorization process.\n\nThe most critical vulnerability identified by the report was not found in the OAuth registration endpoint itself. Instead, it was discovered on the consent screen, where the client name was displayed to the user. The report highlighted the risk of attackers registering malicious clients and using their names to trick users into granting unauthorized access. However, this vulnerability can be mitigated by rendering the client name from a trusted source, rather than directly from the attacker-controlled input.\n\nTo address these issues, I implemented three changes to the service:\n\n1. Recognize apps by redirect host, never by name. This ensures that each client is identified by its unique host, which cannot be easily manipulated by an attacker. The list of trusted hosts is hardcoded and regularly updated, minimizing the risk of domain impersonation.\n\n2. Display a warning when an unrecognized app attempts to register. This warning clearly identifies the destination of the redirect and informs users that the client name may not be trustworthy. By focusing on the destination rather than the name, the warning reduces the likelihood of users being misled by malicious client names.\n\n3. Refuse to register client metadata containing the targeted domain name. This final safeguard prevents attackers from using the service's own brand to impersonate legitimate applications. By explicitly blocking registrations with this domain, the service effectively neutralizes the most convincing version of the impersonation attack.\n\nAdditionally, I addressed the report's suggestion to implement rate limiting on the OAuth clients table. While rate limiting is necessary to prevent abuse and excessive storage costs, it should be implemented in a way that is resilient to serverless architectures. In my implementation, I added a rate limit counter to a Postgres database, ensuring that the control remains effective even in a serverless environment.",
  "summary": "Last week I got an unsolicited security report about my QR code service. It was polite, it was accurate about the facts, and both of its headline recommendations would have broken the product. I want to walk through it, because \"the report was right and the fix was wrong\" is a situation you will hit if you ship anything with an MCP server on it, and because the actual exposure turned out to be…",
  "key_points": [
    "Security researcher advised against OAuth endpoint changes",
    "Proposed changes would disable dynamic registration functionality",
    "Implemented three safeguards to protect service from attacks"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}