Because they sit between user intent and delegated access. If plugin logic changes scope handling, request filtering, or consent presentation, the resulting authorisation outcome may differ from what the architecture diagram suggests. Extra review is needed to catch policy drift before it becomes the de facto access model.
Why custom consent and OAuth flows need a second look
Custom consent and OAuth flows are not just interface variations, they are policy enforcement paths. The moment a plugin or app changes scope display, filters requests, or alters consent prompts, it can change the effective authorisation outcome. That is why teams review them as security-critical control points, not as routine UI work.
At a minimum, the design has to preserve the same security intent across the user journey: what is requested, what is shown, and what is actually granted. If those three do not match, the system can drift into overbroad delegated access without any obvious breakage in the application itself.
For the underlying protocol, the base model is OAuth 2.0 as defined in RFC 6749: The OAuth 2.0 Authorization Framework, with security hardening guidance in RFC 9700: Best Current Practice for OAuth 2.0 Security. Those references matter because custom logic often sits exactly where scope discipline, redirect handling, and token handling must remain strict.
Where policy drift usually enters the flow
Policy drift tends to appear when custom code becomes the real decision-maker. A consent page can understate scope names, group multiple permissions into a friendlier label, or silently transform a user-facing request into a broader grant. A plugin can also change which requests are blocked, which are pre-approved, and which are forwarded to downstream systems.
That is especially important where delegation is the point of the flow. If the design is supposed to limit access to a specific resource, audience, or action, then any custom translation layer can widen the blast radius. The architecture may still look compliant on paper, but the runtime behaviour may be effectively different.
Related identity and consent patterns are discussed in Identity Data Privacy and Consent Guide and SaaS-to-SaaS and OAuth App Governance Guide, both of which treat consent, scopes, and revocation as governance decisions rather than cosmetic workflow details. Those are the right lenses when customisation affects what access a user or app can actually obtain.
Why review has to cover both user intent and delegated access
Extra review is needed because oauth consent is an authorisation decision wrapped in a user experience. If the presentation layer is altered, the reviewer has to confirm that the user’s intent still maps cleanly to the permission set being granted, including the right scopes, the right audience, and the right lifetime of the grant.
This is also where third-party and SaaS governance matter. A flow that looks harmless may still create durable access through refresh tokens, offline access, or broad app permissions, which is why teams should validate not only the initial consent screen but the resulting token and revocation behaviour.
For machine-to-machine and delegated access patterns, RFC 8693: OAuth 2.0 Token Exchange is a useful reference point for understanding when one party acts on behalf of another, while OpenID Connect Core 1.0 shows how authentication and identity assertions layer on top of OAuth. If a custom flow blurs those boundaries, the access outcome can become harder to reason about and easier to abuse.
Risk and Threat Considerations
Custom consent and OAuth flows create a risk window because they can conceal privilege expansion, consent phishing, or token theft behind a familiar login path. The danger is not just an exposed token, but a misleading grant process that trains users and administrators to approve access they would otherwise reject.
Failure mechanism: Custom logic changes the requested scopes, the consent presentation, or the post-consent token behaviour, so the access granted is broader or longer-lived than the policy intended.
Impact: Attackers or careless integrators can obtain durable delegated access, move laterally through connected apps, or exfiltrate data under a legitimate-looking authorisation trail.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Consent and delegated access must not broaden privileges beyond need. |
| IA-5 — Authenticator Management | OAuth flows depend on safe token and secret handling across the lifecycle. | |
| Recommendation — Constrain granted access to the minimum scopes and actions required. Protect and rotate tokens, secrets, and other authenticators across the flow. | ||
| OWASP ASVS | V10 — OAuth and OIDC | Custom OAuth and consent flows fall directly under OAuth/OIDC verification. |
| V8 — Authorization | The core issue is whether granted access matches intended authorization. | |
| Recommendation — Verify OAuth and OIDC behaviour for scope, consent, and token handling. Test that authorization decisions match the intended access policy. | ||
Practitioner Guidance
What to verify: Review the exact scope set, audience restriction, token lifetime, refresh behaviour, and revocation path after every customisation to consent or OAuth handling. If the flow can produce a different access outcome without a corresponding policy change, treat that as a defect, not a UI variation.
Decision rule: If the implementation modifies how consent is displayed, filtered, or auto-approved, require security review before release. If it also changes token exchange, delegated access, or third-party app onboarding, require the same scrutiny you would apply to a privileged access change.
Practitioner takeaway: The test is whether the flow still enforces the intended authorisation boundary at runtime, not whether the screens look reasonable in a demo.