How to Write an Effective OIDC Feature Request
OIDC has become the backbone of secure authentication in modern apps. It wraps OAuth 2.0 with identity layers, letting you verify users and pull in profile data without storing passwords. But if you’ve built on it long enough, you’ve hit limits: provider interoperability gaps, missing claims, slow discovery endpoints, inflexible token lifecycles. Each one grinds productivity to a halt.
An OIDC feature request is more than asking for a tweak. It’s a precise, testable change to the protocol or a provider’s implementation. These requests can cover:
- New custom claims for domain-specific user data
- Token binding or rotation enhancements to block replay attacks
- Extended metadata in the discovery document
- Stronger support for dynamic client registration
- Improvements in PKCE handling for SPA security
Submitting a feature request requires clarity. Providers move faster when you deliver exact reproduction steps, API call examples, and specific breaks in the current spec compliance. Reference the relevant section in the OpenID Connect Core documentation. Include how the change impacts cross-provider compatibility. Link to open issues or pull requests in related projects so the request gains traction beyond your team.
The ecosystem changes when engineers push for it. RFC updates arise from stacked, well-documented issues and real-world implementation feedback. A well-framed OIDC feature request can close painful gaps across thousands of applications.
If you need a live, flexible authentication setup ready to test your OIDC ideas, check out hoop.dev — deploy in minutes, see it work, and push your next request with confidence.