Preventing OAuth2 Dynamic Client Registration Vulnerabilities

When I first implemented an OAuth2 provider, I thought Dynamic Client Registration (DCR) was a "set it and forget it" feature. I was wrong. After realizing that an unauthenticated endpoint could allow any bot to register thousands of clients—effectively filling my database with garbage and creating potential phishing vectors—I had to rethink my approach to API security.

If you don't gate your registration endpoints, you're essentially handing out keys to your infrastructure. Let's look at how to lock this down.

Understanding the Risk of Dynamic Client Registration

Dynamic Client Registration (RFC 7591) allows clients to register themselves with an authorization server. While this is great for automated developer portals, it’s a massive target if left open. Attackers often use these endpoints to perform metadata injection, where they provide malicious redirect_uris or logo_uri values to facilitate XSS or open redirect attacks.

We once tried an "open" registration approach for a small internal project. It lasted about three days before we saw a surge in registration requests from random IPs. We had to pivot to a software-statement-based flow, which requires a pre-signed token to even attempt registration.

Hardening Your Registration Logic

Whether you're working with Node.js or PHP, the defensive strategy remains the same: treat the input as hostile. You must validate the client metadata schema strictly.

1. Enforce Authentication and Software Statements

Never leave your /register endpoint public. Use an initial access token or a signed software statement. If you're using Node.js with express, ensure your middleware checks for a valid scope or a hardware-backed token before reaching the controller.

2. Strict Metadata Validation

Don't just accept any redirect_uri. If an attacker can register a client with a redirect_uri pointing to their own server, they can intercept authorization codes.

In PHP, I use a strict allow-list for URI schemes:

PHP
function isValidRedirectUri(string $uri): bool {
    $parts = parse_url($uri);
    $allowedHosts = ['myapp.com', 'api.trusted.partner'];
    
    return isset($parts['host']) && in_array($parts['host'], $allowedHosts) && $parts['scheme'] === 'https';
}

This simple check prevents attackers from injecting javascript: or data: URIs, which are classic vectors for XSS.

3. Rate Limiting and Payload Constraints

As I discussed in my post on Request Body Parsing Security: How to Prevent DoS and Injection, you must limit the size of incoming payloads. Dynamic registration endpoints are prime targets for DoS attacks via massive JSON blobs.

Implementation Patterns in Node.js

In Node.js, I prefer using a library like joi or zod to enforce a strict schema on the registration request. If the payload contains unexpected fields, reject it immediately with a 400 Bad Request.

JAVASCRIPT
const schema = z.object({
  client_name: z.string().max(100),
  redirect_uris: z.array(z.string().url()).min(1),
  grant_types: z.array(z.enum([CE9178">'authorization_code', CE9178">'client_credentials']))
});

// In your route handler
const result = schema.safeParse(req.body);
if (!result.success) {
  return res.status(400).json({ error: CE9178">'invalid_client_metadata' });
}

This prevents metadata injection by ensuring that only known, expected fields enter your database.

Preventing Sandbox Escape and System Compromise

If you are handling registration metadata, you might be tempted to pass it into system commands or template engines. This is dangerous. If you're running your identity services in a shared environment, ensure you're following the principles outlined in Preventing Sandbox Escape: Hardening Node.js and PHP Isolation.

Never execute code based on client-provided metadata. Even a seemingly benign client_name could be used in a template injection attack if you're auto-generating developer emails based on that field.

Common Security Questions (FAQ)

Q: Should I allow http redirect URIs for development? A: Absolutely not. Even in development, http allows for man-in-the-middle attacks. If you need local testing, use a self-signed certificate or a tunnel like ngrok that terminates TLS.

Q: How do I handle revoked clients? A: Your DCR endpoint should be paired with a robust client management service. When a client is compromised, you need a way to invalidate their client_id and client_secret across your entire distributed API gateway. If you haven't yet, look at how to manage these states carefully, as discussed in OAuth2 Security: Preventing Improper Token Introspection Leaks.

Q: Is it safe to auto-approve registrations? A: Only if the registration request is accompanied by a valid, signed software statement from a trusted partner. Otherwise, always default to a "pending" state that requires manual admin approval.

Final Thoughts

Securing OAuth2 Dynamic Client Registration isn't just about adding an if statement; it’s about assuming every input is an attack. I've found that the most resilient systems are those that reject invalid metadata at the edge before it ever touches the business logic.

I’m still experimenting with OIDC discovery documents to see if we can automate the rotation of registration keys, which might reduce the blast radius if an initial token is leaked. For now, keep your schemas tight, your rate limits aggressive, and your redirect URIs strictly constrained. Security is a process, not a destination.