Wallets can authenticate a user or prove attributes, but they do not issue the enterprise access token that protects APIs. OAuth 2.0 remains the layer where scopes, audiences, and policy decisions are controlled, so authorization must stay inside the enterprise boundary.
Why EUDI wallets do not replace enterprise OAuth 2.0
EUDI wallets can prove who a user is and, in some cases, reveal attributes or credentials, but they do not become the enterprise authorization layer for API access. Enterprise systems still need a token service that can issue, scope, and validate access for a specific resource. That separation keeps the wallet in the identity proofing role and OAuth 2.0 in the access control role.
That distinction matters because OAuth 2.0 is not just “login plumbing.” It defines how a client gets an access token, how the resource server interprets it, and how scopes and audiences constrain what the caller can do. An identity wallet may help establish trust in the person or credential behind the request, but it does not replace the policy boundary that enterprise APIs enforce.
For machine access, delegated access, and application-to-application calls, the enterprise still needs an authorization framework that can express client type, token audience, consent, and service-specific privileges. The wallet may provide an input to that process, but the enterprise must still decide whether the request should receive an access token at all, and what that token permits.
Where the boundary sits in practice
Think of the wallet as evidence about the subject, and OAuth as the mechanism that turns that evidence into a usable access token. The wallet can present a verifiable credential, a person’s identity assurance, or a cryptographic proof. The enterprise then maps that signal into local authorization policy, resource scopes, and session boundaries before any API is exposed.
That is why wallet-first access designs usually still rely on federation, token exchange, or an enterprise authorization server. The wallet does not know the internal application model, the API inventory, the required audiences, or the business-specific privileges attached to a given transaction. Those controls belong to the enterprise boundary, not the wallet itself.
This also avoids a common architecture mistake: treating a high-assurance external identity as if it were automatically sufficient for internal access. Strong identity proofing does not eliminate the need for least privilege, resource scoping, separation of duties, or explicit approval logic. It only improves confidence in who is asking.
How enterprises should combine wallets and OAuth
Wallets and OAuth work best as complementary layers. The wallet establishes trust in the user or credential, while OAuth defines what an application, API, or delegated session can actually do. In that model, the wallet helps answer “who is this?” and OAuth answers “what is this subject allowed to access right now?”
That combination is especially important when the same enterprise must support people, mobile devices, service integrations, and automated flows. A wallet may be suitable for human-facing proofing or reusable identity presentation, but API authorization still needs a protocol that handles scopes, audience restriction, token lifetime, and client authentication consistently across systems.
If the enterprise is using the wallet as a front end to a broader trust framework, the practical question is whether the wallet evidence is translated into a controlled authorization decision. If it is not, teams risk creating a parallel access path that bypasses the normal enterprise policy engine.
Risk and Threat Considerations
Conflating wallet-based identity presentation with API authorization creates a control gap. If the wallet output is treated as sufficient proof for direct access, an attacker or misconfigured client can gain broader access than intended, especially where audience restrictions, scope checks, or consent boundaries are weak.
Failure mechanism: The enterprise accepts an externally asserted identity or attribute as if it were an internally issued access token, so the policy layer that should constrain resource access is skipped or weakened.
Impact: Overbroad access, token misuse, broken delegation boundaries, and a higher chance of unauthorized API calls, especially in environments that support both human and non-human callers.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-63 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | IAL — Identity Assurance | Wallets provide identity assurance, not resource authorization, which shapes trust decisions. |
| Recommendation — Map wallet assertions to the right assurance level before granting access. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Direct API access without enterprise authorization can bypass function-level controls. |
| Recommendation — Enforce function-level authorization in the API gateway and service layer. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Enterprise access still needs authenticated users before authorization decisions. |
| AC-3 — Access Enforcement | Enterprise policy must enforce what authenticated callers can do after wallet-based proofing. | |
| Recommendation — Require strong user authentication before issuing access tokens. Enforce access decisions at the resource boundary, not in the wallet. | ||
Practitioner Guidance
What to verify: Confirm that the wallet is only supplying identity or attribute evidence, and that every protected API still requires an enterprise-issued token with explicit audience and scope validation.
Decision rule: If a wallet outcome can be replayed directly against an API, the access design is too loose and needs a separate authorization step before rollout.
What good looks like: The wallet improves assurance at sign-in or assertion time, while the enterprise authorization server remains the only place where access rights, token issuance, and resource boundaries are decided.
Practitioner takeaway: EUDI wallets strengthen identity assurance, but enterprises should treat OAuth 2.0 as the access control layer that enforces local policy, not as an optional legacy component.