OAuth providers security
What middleBrick covers
- OAuth endpoint discovery and misconfiguration detection
- OpenID Connect metadata and JWKS inspection
- Redirect URI validation and open redirect probing
- PKCE and state parameter strength checks
- Token claims and scope exposure analysis
- Read-only, non-intrusive scanning with safety blocks
Threat model for OAuth provider endpoints
OAuth provider endpoints expose flows that involve redirection, token exchange, and scope delegation. The primary risks are authorization code interception, incorrect redirect URI validation, weak state handling, and token leakage. Black-box scanning targets the public surface: authorization and token endpoints, discovery documents, and dynamic configuration responses. The scanner checks for common implementation weaknesses such as missing PKCE, insecure redirect URI patterns, and overly permissive CORS on token-introspection endpoints.
Detection of OAuth misconfigurations
The scanner evaluates OAuth providers for misconfigurations aligned to OWASP API Top 10. It tests for open redirectors that can be abused to exfilterate authorization codes, missing or weak state parameters, and improper validation of code challenges and verifiers. It also probes for information leakage in URLs and fragments, such as tokens or error details, and inspects whether the provider enforces HTTPS strictly and applies appropriate HTTP security headers.
- Authorization endpoint redirect validation and open redirect probing.
- State parameter presence, format, and cryptographic unpredictability checks.
- Token endpoint verification of code challenge methods and PKCE enforcement.
- HTTPS enforcement, HSTS presence, and secure cookie attributes on provider-hosted pages.
Provider discovery and metadata risks
OpenID Connect discovery documents and OAuth provider metadata are often assumed static, but misconfigurations here can undermine the entire flow. The scanner parses provider metadata to detect overly broad allowed origins, missing TLS requirements, and incorrect signing key exposure. It also checks discovery documents for references to unsupported or deprecated signing algorithms, which can lead to algorithm confusion attacks.
- Validation of issuer, authorization, and token URLs for correctness and scope.
- Analysis of JWKS exposure to ensure no accidental leakage of private material.
- Checks for allowed origins and redirect URIs to prevent wildcard abuse.
Scope, claims, and token handling
Excessive scope and poorly scoped tokens increase the blast radius of a compromised authorization code or token. The scanner examines scopes requested by clients and compares them against a minimal set principle. It also inspects ID and access tokens for sensitive claims in plaintext, missing audience validation, and missing or weak nonce usage. Token binding and replay protections are assessed where observable through metadata and error behavior.
- Scope minimization guidance and detection of overly permissive scopes.
- Claims inspection for PII or sensitive data exposure in tokens.
- Audience and issuer validation checks to mitigate token replay across services.
Limitations and complementary testing
Black-box scanning can surface configuration and implementation weaknesses but cannot validate server-side secret storage, internal trust relationships, or custom protocol extensions. It does not perform intrusive payload delivery such as active SQL injection or command injection. Business logic flaws in consent screens, approval flows, or conditional access policies require domain-aware review. The tool supports audit evidence collection and aligns with security controls described in frameworks such as PCI-DSS 4.0 and SOC 2 Type II.
- No active exploitation of SQL injection or command injection is performed.
- Business logic and consent-granting flows are outside black-box scope.
- Findings map to recognized API security controls and support compliance evidence.