Chapter 9. Common authorization server vulnerabilities
This chapter examines why the authorization server is the most security‑critical and complex element in an OAuth deployment and outlines how attackers commonly target it. Because it operates both a user-facing front channel and a machine-facing back channel, it must combine general web security hardening (TLS, secure logging, OS and account hygiene) with rigorous protocol checks. The central message is that tight validation, conservative defaults, and careful handling of redirects and tokens are essential to prevent seemingly small implementation choices from becoming exploitable weaknesses.
A major class of risks centers on front-channel flows and transient credentials. Authorization codes can be harvested from browser history or misdirected through tampered redirects; the reliable countermeasures are to make codes one-time use, revoke on reuse, and bind each code to the issuing client. Redirect behavior matters too: unsafe redirect semantics can leak credentials, and the only consistently safe way to validate redirect_uri is exact matching. Looser patterns (subdirectory or subdomain matching) can be abused with path traversal or attacker-controlled subdomains to route users to malicious endpoints, where codes or access tokens may leak via the Referer header or URL fragments—an issue sometimes described as covert redirect.
The chapter also highlights server-side pitfalls that enable client impersonation and open-redirect abuse. If the token endpoint doesn’t verify that the redirect_uri exactly matches the value used during authorization, attackers can redeem stolen codes through a legitimate client. Separately, blindly redirecting error responses to a registered redirect_uri can turn the authorization server into an open redirector that attackers chain with other tricks to exfiltrate tokens. Recommended mitigations include enforcing redirect_uri consistency at the token endpoint, rejecting invalid requests with HTTP 400 instead of redirecting, optionally clearing Referer data via intermediate pages, appending a trailing “#” on error redirects to prevent fragment reattachment, and maintaining strict, specific redirect_uri registrations. Together, these practices close common gaps and keep the authorization server from becoming an attack conduit.
Why is the authorization server such a high‑value target, and what baseline hardening should it have?The authorization server sits at the center of OAuth, exposing both browser-facing and API endpoints. Hardening must include end-to-end TLS with valid certificates, strict TLS settings, secure cookies, CSRF protection where applicable, HSTS, robust logging and log protection, input validation and normalization, least‑privilege OS/user accounts, patch management, rate limiting/abuse detection, and secure key/secret storage.How can an attacker hijack an authorization code via the browser, and how do we prevent it?Authorization codes travel through the user agent and can persist in browser history. On a shared machine, an attacker may inject a previously stored code into a new flow. Mitigations: make codes single‑use and short‑lived; immediately invalidate a code after redemption; bind the code to the issuing client_id; and ensure the token request’s redirect_uri exactly matches the authorization request’s redirect_uri.Why must authorization codes be single‑use, and what should happen if a code is reused?Single‑use codes prevent replay from browser history, logs, or referrers. On detecting reuse, the authorization server must refuse the request and should revoke any tokens issued from that code (if possible), alert and log the incident, and rate‑limit or temporarily block the client/session as appropriate.What does “binding the authorization code to the client_id” accomplish?It ensures a code issued to one client cannot be redeemed by another. The token endpoint must verify that the client_id authenticated at the token endpoint matches the client_id associated with the original authorization request; otherwise, any client could exchange another client’s code for a token.Why is exact redirect_uri matching the only consistently safe option?Looser strategies like “allow subdirectory,” “allow subdomain,” or wildcard matching enable exploits such as path traversal or subdomain abuse, letting attackers steer responses to pages they control. Exact string matching of a pre‑registered, fully qualified redirect_uri blocks these manipulations.How does path traversal in redirect_uri get abused, and how do we block it?If a server accepts a redirect_uri that merely starts with a registered path, an attacker can append sequences like ../ to climb directories and land on an attacker‑controlled page on the same host. Prevent this by: using exact redirect_uri matching; normalizing URIs before comparison; rejecting any redirect_uri containing traversal or unusual encodings; and avoiding patterns/wildcards.What is “client impersonation” at the token endpoint, and how is it prevented?If the token endpoint doesn’t require the redirect_uri to match the exact value used in the authorization request, an attacker who stole a code via redirect manipulation can present it to the victim client’s callback so the victim client redeems it. Prevention: at the token endpoint, require the redirect_uri parameter and verify it exactly equals the one from the original authorization request for that code.How can an authorization server accidentally act as an open redirector, and what are the mitigations?Following the spec naively, some servers redirect users to the client’s redirect_uri even when the request is invalid (for example, bad scope). If clients can register arbitrary redirect_uris, this becomes an open redirect. Mitigations: return HTTP 400 for invalid requests instead of redirecting; use an intermediate error page controlled by the authorization server; and append “#” to error redirect URIs to prevent fragment leakage.What’s the risk difference between HTTP 302 and 307 redirects in OAuth front‑channel flows?Browsers may replay the original method and body on 307 redirects, potentially forwarding credentials or form data to the redirect_uri host. To avoid leaking secrets, do not use 307 for authorization responses; use 302/303 patterns that do not forward the original request body.How do Referer headers and URL fragments leak secrets, and how can we reduce that risk?Authorization codes in query strings may leak via Referer when the browser loads resources on another domain; access tokens in fragments can be propagated by browsers during chained redirects. Mitigations: avoid error redirects that bounce through third‑party pages; use an intermediate error page or return HTTP 400; append “#” to error redirects; set a strict Referrer‑Policy; keep responses same‑origin; and prefer code flows that avoid placing tokens in the front channel.
pro $24.99 per month
access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
OAuth 2 in Action ebook for free
