Authorization Code Flow

This flow covers your application creating a credential offer, the wallet redirecting the holder to an external IdP to authenticate, and the Issuer2 Service mapping the returned ID token claims into the credential. Set "authMethod": "AUTHORIZED" when creating the offer to use it.

Components involved:

  • Your Application — creates the credential offer and displays the QR code.
  • Wallet (Holder) — scans the QR code, redirects the holder to log in, completes the flow.
  • Issuer2 Service — manages the issuance session, correlates issuer_state, applies idTokenClaimsMapping, and signs the credential.
  • External IdP — authenticates the holder and issues the ID token, configured via authProviderConfiguration on the issuer service.

This flow requires an external OAuth/OIDC provider configured via authProviderConfiguration when creating the issuer service before you create an AUTHORIZED offer.

Loading diagram...

This diagram is a simplified overview focused on how the Issuer2 Service behaves. It omits some protocol details (e.g. metadata discovery of the Nonce Endpoint, PKCE, and the separate authorization-server metadata fetch). For the complete, normative sequence see the OpenID for Verifiable Credential Issuance 1.0 specification.

Understanding issuer_state

issuer_state is how the Issuer2 Service correlates the authorization request it receives back at .../openid4vci/authorize with the issuance session created when the offer was made. Set "issuerStateMode": "INCLUDE" when creating the offer to include it.

AUTHORIZED offers omit issuer_state unless issuerStateMode is INCLUDE. Because per-offer overrides need this correlation, an AUTHORIZED offer that uses runtimeOverrides must set issuerStateMode to INCLUDE — see Runtime Overrides.

Last updated on July 20, 2026