OAuth 2.0 provider validation
What middleBrick covers
- OAuth 2.0 endpoint configuration validation
- Redirect URI and scope enforcement checks
- Client authentication and public client boundary analysis
- Token introspection and revocation verification
- PKCE and code challenge handling tests
- Findings mapped to OWASP API Top 10 and compliance evidence
What OAuth 2.0 provider validation is
OAuth 2.0 provider validation is the process of confirming that your authorization server correctly implements specification behavior for issuing, introspecting, and revoking tokens. It checks that redirect URIs, scopes, client authentication, and token bindings operate as defined in the RFC. Validation ensures that access delegation follows the intended security model rather than default framework conveniences that weaken isolation between clients and resources.
Common mistakes when skipping validation
Teams that skip provider validation often rely on default middleware behavior and assume framework defaults are secure. This leads to several classes of weaknesses:
- Overly permissive redirect URIs that enable open redirects or authorization code interception.
- Insufficient scope validation allowing privilege escalation across APIs.
- Weak client authentication where public clients handle confidential credentials or vice versa.
- Token introspection and revocation endpoints that do not enforce authentication, leaking authorization data.
- Implicit flow usage in browser-based clients, exposing tokens in URLs and referrers.
These issues violate the separation between resource owners, clients, and authorization servers and can enable token substitution or cross-client access.
A robust validation workflow
A repeatable validation workflow combines specification review, runtime probing, and continuous monitoring. Start by auditing your provider configuration against RFC requirements and your application threat model. Define allowed redirect URI patterns, enforce exact host and path matching, and require proof-of-key for public clients using PKCE. Use scope whitelisting and validate audience claims in tokens. Automate checks in CI to catch regressions before deployment. Finally, enable logging and token revocation to detect misuse and support incident response.
POST /oauth/token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&code=CODE
&redirect_uri=https%3A%2F%2Fclient.example.com%2Fcallback
&client_id=CLIENT_ID
&code_verifier=CODE_VERIFIERWhat middleBrick covers out of the box
middleBrick scans your OAuth 2.0 provider endpoints to validate configuration and surface deviations from expected security properties. The scanner exercises authorization, token, introspection, and revocation paths using read-only methods to detect misconfigurations without modifying state.
- Redirect URI handling and open redirect surface.
- Scope validation and over-privileged access patterns.
- Client authentication mechanisms and public versus confidential client boundaries.
- Token binding, audience checks, and JWT well-formedness.
- Introspection and revocation endpoint authentication requirements.
- PKCE enforcement and code verifier handling.
By mapping findings to OWASP API Top 10 and supporting evidence for SOC 2 Type II and PCI-DSS 4.0 control frameworks, the scanner helps you prioritize remediation based on risk and compliance relevance.
Limitations and complementary practices
middleBrick does not replace a human-led review of business logic, such as how your application interprets scopes or enforces tenant isolation. It does not perform intrusive payload delivery or attempt to exploit active vulnerabilities. Complement scanning with protocol-level testing, formal verification of critical flows, and periodic manual penetration tests for high-risk OAuth deployments.