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.

Frequently Asked Questions

Can the scanner test OAuth providers that require authentication?
Yes. The Starter tier and above support Bearer, API key, Basic auth, and Cookie authentication for authenticated scans. The domain owner must verify ownership through DNS TXT or an HTTP well-known file.
Does the scanner fix OAuth misconfigurations?
No. The tool detects and reports issues with remediation guidance. It does not patch, block, or reconfigure provider endpoints.
What OAuth-related findings does the scanner report?
Findings include open redirect risks, missing PKCE, weak state handling, insecure redirect URI patterns, and token leakage via URLs or logs. Each finding includes prioritized remediation steps.
How are scans limited to avoid disruption?
Only read-only methods are used, and destructive payloads are never sent. Private IPs, localhost, and cloud metadata endpoints are blocked at multiple layers.