Issuing with the Authorization Code Flow
The pre-authorized code flow used earlier suits backend-initiated issuance where the subject is already known. The authorization code flow inverts this: the wallet sends the user to the authorization server to authenticate first, and the issuer resolves the subject's claims from the authenticated identity.
The offer
An offer with an authorization_code grant carries no subject data. The issuer_state ties the wallet's authorization request back to this offer:
- Overview
- Request
- Response
01 Create offer with authorization code grant
Endpoint: POST /api/oid4vci/v1/backend/credential/offers
Captured response: 201 Created
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
The flow
The wallet reads the authorization server metadata, then drives a standard OAuth2 authorization code flow with PKCE:
- Overview
- Request
- Response
02 Fetch authorization server metadata
Endpoint: GET /.well-known/oauth-authorization-server
Captured response: 200 OK
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
- The wallet opens the authorization endpoint with
response_type=code, its client id, a redirect URI, theissuer_state, and a PKCE challenge. - The user authenticates: against the hosted AS, or through a federated IdP registered in step 4 of this walkthrough.
- The wallet exchanges the authorization code for an access token at the token endpoint.
- The credential request proceeds exactly as in the pre-authorized flow: a proof of possession signed by the holder key, answered with the credential.
The issuance session on the backend moves through the same lifecycle states either way, so status polling and callbacks work identically for both grants.