The most common mistake is hiding runtime differences behind a shared wrapper, which creates config drift, token mismatch, and brittle dependencies. A better approach is shared claim shapes and environment validation, with each app using the SDK that matches its own runtime and trust model.
Where centralised auth in a monorepo goes wrong
The centralisation mistake is usually architectural, not just organisational. Teams often try to hide all auth logic behind a shared wrapper, but each app still has its own runtime, token handling, redirect behaviour, and trust boundary. When the wrapper abstracts away those differences, the codebase looks consistent while the deployed behaviour drifts.
That drift shows up when one app assumes browser semantics and another runs server-side, when one environment uses one issuer or audience and another uses a different one, or when config defaults silently change. The result is brittle coupling, surprising failures during deployment, and auth code that is harder to test because the shared abstraction no longer matches the real execution context.
A better mental model is to centralise the shared contract, not the entire implementation. Share claim shapes, validation rules, naming conventions, and environment checks, then let each app use the SDK and flow that matches its own runtime and trust model. That keeps the boundary explicit instead of forcing incompatible applications through one generic auth layer.
Why shared wrappers create config drift and token mismatch
Shared wrappers tend to fail when they flatten differences that matter to security and reliability. One app may need a browser session, another a backend-to-backend access token, and a third a machine credential with different rotation and audience expectations. If those distinctions are forced into one helper, the wrapper becomes a source of hidden assumptions rather than a control point.
Token mismatch is a common downstream failure. A wrapper may accept tokens that are valid in one environment but wrong for another, or it may emit claims that downstream services do not recognise consistently. In practice, that produces intermittent authentication failures, confusing 401s, and hard-to-reproduce bugs that only appear after deployment or during a runtime change.
Configuration drift is the other big failure mode. Once teams rely on shared defaults, they stop validating the environment at the edge of each app. Small differences, such as issuer URLs, audiences, callback paths, cookie settings, or secret sources, can accumulate until the wrapper encodes a configuration that no longer matches reality.
How to centralise the right parts without overfitting the wrong ones
The safest pattern is to centralise the invariants that truly should not vary, then keep runtime-specific behaviour local. Shared claim schemas, environment validation, naming standards, and error handling can live in a common package because they describe the contract. Flow selection, session mechanics, SDK choice, and transport-specific details should stay close to the application that uses them.
That separation matters because different runtimes fail in different ways. An app that renders on the server, an SPA, and a worker process do not share the same trust assumptions, storage options, or token lifecycle constraints. Treating them as interchangeable usually creates a clean interface on paper and a fragile implementation in production.
For teams working with OAuth-based machine or service access, the distinction between a generic auth wrapper and a context-aware token flow is especially important. Standards such as RFC 6749: The OAuth 2.0 Authorization Framework and RFC 8707: Resource Indicators for OAuth 2.0 are useful reminders that audience and delegation context are part of the design, not an afterthought.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V10 — OAuth and OIDC | The issue involves auth flow correctness, token handling, and environment-specific validation. |
| Recommendation — Verify OAuth and OIDC behaviour separately for each application and runtime. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Shared auth code often fails through poor credential and token lifecycle handling. |
| Recommendation — Manage authenticators and tokens with lifecycle controls that match each app's environment. | ||
Practitioner Guidance
What to verify: Check that each application owns its own runtime-specific auth settings, including issuer, audience, callback behaviour, and token storage assumptions. If a shared package is masking those values, it is probably hiding a future production breakage.
Decision rule: If the auth behaviour depends on runtime, transport, or trust boundary, keep that logic local to the app. Centralise only the validation and claim contract that every app genuinely shares.
Common mistake: Teams often optimise for DRY code and end up sharing an abstraction that is too broad to be safe. A smaller shared surface is usually easier to govern, easier to test, and less likely to break when one app changes framework or deployment model.
What good looks like: Each app can fail fast on bad environment data, use the SDK that fits its runtime, and still produce claims and tokens that conform to the same organisational contract.
Practitioner takeaway: Centralise the policy and contract, not the runtime behaviour. If the wrapper has to guess which environment it is serving, it is already too generic for secure auth.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org