Features like "Sign in with Google" and "Connect with Slack" are remarkably easy to verify. You click a button, a consent screen appears, and you sign in with your account. It takes five minutes.
The problem is that flaws in OAuth implementations never manifest during normal operations. As long as you log into your own account yourself, the on-screen behavior is identical whether the configuration is lax or robust. Differences only emerge during an attack, at which point the consequence is someone else gaining access to an account.
In reality, there are not many things a client can check during acceptance testing. However, there are a few focused points you can verify.
Defects that functional testing will not uncover
The OAuth authorization code flow involves several browser redirects before the application ultimately receives an access token. The quality of the implementation is determined by how much room is left for an attacker to intercept during those round trips.
A prime example is authorization code interception. The authorization code issued by the authorization server travels back on the redirect URL. If validation of that redirect destination is lax, an attacker can redirect the code to an endpoint under their control and impersonate a legitimate user. Because public clients (such as mobile apps or browser-based apps) cannot keep client secrets confidential, secrets alone cannot prevent this.
These threats are detailed in RFC 6819's threat model, and mitigation strategies are compiled in the OAuth 2.0 Security Best Current Practice. In short, this is an area governed by established reference specifications rather than individual developer improvisation. That provides a concrete foothold for acceptance testing.
Five points to verify during acceptance testing
Even if clients cannot read code, the following five points can be verified through targeted questions. An inability to answer is, in itself, an answer.
| Checkpoint | Desired answer |
|---|---|
| Redirect URI validation | Validated via exact match against pre-registered URIs |
| PKCE | Used across all authorization code flows |
| state parameter | Issued and validated upon return |
| Requested scopes | Strict minimum required for functionality; rationale logged when adding scopes |
| Token storage location | Server-side; if stored on the client, storage method must be explicitly specified |
1. Redirect URI validation. On the authorization server, only exact matches with pre-registered URIs should be permitted. Prefix matching or wildcard registrations create opportunities for attackers to slip in their own destination. It is also worth confirming whether development endpoints like localhost remain registered.
2. PKCE. Defense against authorization code interception. In OAuth 2.1, PKCE is mandatory for all authorization code flows. If the answer is "not needed because it is not a public client," that relies on outdated assumptions.
3. The state parameter. A value that links authorization requests to responses, serving as a defense against CSRF. Ask not only whether it is generated, but whether it is validated upon return. Implementations that generate it only to discard it unvalidated are surprisingly common.
4. Scopes. This is the area most prone to "requesting broadly just in case." What the application can read and write in the linked service is visible to end users. Excessively broad scopes directly lower user consent rates. Granting permissions strictly when needed aligns with the principles discussed in Operations for Just-in-Time Privilege Granting.
5. Token storage location. Where are access tokens and refresh tokens kept? If stored in browser localStorage, vectors remain for scripts to read them. Storage location is an architectural decision; what matters is whether the rationale behind the choice can be explained.
Why "it works, so it must be fine" fails
Of the five points above, all happy-path tests will pass even if none of them are satisfied.
Even if redirect URIs use prefix matching, everything works normally as long as users return to your company's URL. Even without PKCE, users can still log in. Even without state validation, nothing appears amiss during ordinary usage.
That is why unless "behavior under attack" is included in acceptance test criteria, there is no opportunity to verify it. When acceptance testing relies solely on checking off feature lists, this security layer is systematically overlooked.
There is another issue that manifests over time: authentication integrations tend to loosen during operation rather than right after initial build. Adding a redirect URI for a staging environment or enabling access from an additional subdomain accumulates changes detached from the original design. Reviewing registered URIs once a year will uncover numerous abandoned entries. Configurations naturally drift toward expansion, so they will not shrink unless you intentionally create opportunities to prune them.
Defining acceptance criteria for AI-generated code as an operational process was covered in When AI-Generated Code Is Delivered. Authentication is a prime example where generated code tends to end up "functional yet insecure." For authentication design when hosting MCP servers internally, see OAuth 2.1 Authentication for MCP Servers.
A single line to add to your specifications
Settling requirements before implementation is far less expensive than flagging issues afterward. Including the following line in your specifications or requests for proposals brings the five points above into discussion prior to development.
Authentication and authorization integrations with external services shall be implemented in accordance with OAuth 2.0 Security Best Current Practice, and redirect URI validation methods, PKCE usage, state parameter validation, requested scopes, and token storage locations shall be explicitly documented in design specifications.
The effect of this line is clear: the effort of asking "how was this implemented?" after the fact becomes a required part of the deliverable from day one. While it may slightly increase initial estimates, it is definitively cheaper than rebuilding later.
What to do next
If your live service uses social login or third-party integrations, open the third-party provider's admin console and review the list of registered redirect URIs. You may find development URLs or unused domains still listed. This is one of the few places clients can inspect directly.
If you are commissioning development in the future, include the line above in your specifications. Simply designating the reference standard for developers significantly curbs variations in implementation decisions.
GleamHub offers consultations on development, AI, and automation to support architecture reviews for external service integrations, security reviews of existing implementations, and authentication infrastructure redesigns. Because the scope of verification varies by integration provider and existing setup, please reach out for an individual consultation via Contact Us.
