OAuth 2.0: Open Authorization 2.0

Definition

OAuth 2.0 as the Foundation of the EUDI Protocol Stack

The EUDI Wallet protocol architecture is built as layers on top of OAuth 2.0. At the base, OAuth 2.0 provides the authorization framework: how clients request access, how authorization servers issue tokens, and how resource servers validate tokens. OpenID Connect adds an identity layer, defining how to authenticate users and obtain identity claims. OpenID4VCI extends this further, defining how wallets request and receive verifiable credentials. OpenID4VP defines how wallets present those credentials to relying parties.

This layered approach means that EUDI Wallet implementers benefit from the entire OAuth 2.0 ecosystem: existing authorization servers (like Keycloak, Auth0, or Microsoft Entra ID) can be extended with EUDI Wallet capabilities, existing OAuth 2.0 client libraries can be reused, and security practices developed over a decade of OAuth 2.0 deployment apply directly.

The authorization server in the EUDI Wallet context is typically operated by the credential issuer (a government agency, university, or authorized provider). It authenticates the user, obtains consent for credential issuance, and issues access tokens that the wallet uses to request credentials from the issuer's credential endpoint.

Grant Types in EUDI Wallet Flows

The Authorization Code grant with PKCE is the primary flow for interactive credential issuance. The wallet redirects the user to the issuer's authorization server, the user authenticates (typically using their national eID) and consents to credential issuance, and the authorization server returns an authorization code. The wallet exchanges this code for an access token using PKCE (Proof Key for Code Exchange) to prevent authorization code interception attacks. PKCE is mandatory in EUDI Wallet implementations per current security best practices.

The Pre-Authorized Code grant is defined specifically in OpenID4VCI for scenarios where credential issuance is initiated by the issuer rather than the user. For example, after a university registers a student's graduation, it can pre-authorize a diploma credential and provide the student with a credential offer containing a pre-authorized code. The student scans the offer QR code with their wallet, and the wallet exchanges the pre-authorized code directly for an access token without requiring an additional authentication redirect.

Rich Authorization Requests (RAR, RFC 9396) extend OAuth 2.0 authorization requests to express detailed, structured authorization needs. In the EUDI Wallet context, RAR allows wallets to specify exactly which credential type they want to obtain (e.g., "PID credential in SD-JWT format with specific claims") rather than using simple string-based scopes. This enables precise credential issuance control by the authorization server.

Pushed Authorization Requests (PAR, RFC 9126) move the authorization request parameters from the user's browser to a direct server-to-server call, preventing request parameter tampering and reducing URL size issues. EUDI Wallet implementations are recommended to use PAR for improved security in the credential issuance flow.

Token Security Extensions

Standard OAuth 2.0 bearer tokens (tokens that grant access to whoever possesses them) are insufficient for high-security EUDI Wallet operations. Several token security extensions are used to bind tokens to specific holders and prevent token theft.

DPoP (Demonstrating Proof of Possession, RFC 9449) binds access tokens to a cryptographic key held by the wallet. Each API request includes a DPoP proof -- a signed JWT proving the sender possesses the key associated with the token. Even if an attacker steals the access token, they cannot use it because they cannot produce valid DPoP proofs without the private key.

mTLS client certificate binding (RFC 8705) provides an alternative token binding mechanism where the access token is bound to the client's TLS certificate. The authorization server records the certificate thumbprint when issuing the token, and the resource server verifies that the presenting client's certificate matches.

Token lifetimes in EUDI Wallet flows are deliberately short. Access tokens typically expire within minutes, limiting the window for token theft exploitation. Refresh tokens, when used, are rotated on each use (the old token is invalidated when a new one is issued), preventing replay of stolen refresh tokens.

Related Terms