light-mode-image
Learn
API ReferenceIssuance

Exchange authorization code for access token

Analytics Events

OPENID_TOKEN_STARTOPENID_TOKEN_SUCCESSOPENID_TOKEN_FAIL
POST/v1/oauth/token

This endpoint is used to exchange an authorization code or a pre-authorized code for an access token, which is later used to request a credential.

  • In an Authorization Code flow the authorization code is obtained from the authorization endpoint after the user has successfully authenticated.
  • In a Pre-authorized Code flow the pre-authorized code is obtained from the offer URI.

See https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-token-endpoint for more information.

Analytic events

  • OPENID_TOKEN_START
  • OPENID_TOKEN_SUCCESS
  • OPENID_TOKEN_FAIL

Header Parameters

DPoP?string

DPoP proof JWT. A signed JWT that demonstrates proof-of-possession of a private key.

DPoP is offered as a closed beta preview feature and is not generally available yet. If you are interested in trying this feature, please contact us

When to use:

  • Token endpoint: Required when dpop_jkt was provided in the authorization request
  • Credential endpoint: Required when using DPoP-bound access tokens (Authorization header must use format: Authorization: DPoP <access_token>)

The DPoP proof must be a signed JWT with the following structure:

Header:

  • alg: Must be ES256
  • typ: Must be dpop+jwt
  • jwk: Public key (JWK format)

Payload:

  • htu: HTTP URI of the target endpoint
  • htm: HTTP method (e.g., POST)
  • jti: Unique identifier for this DPoP proof
  • iat: Unix timestamp when the DPoP proof was created
  • ath: Optional base64url-encoded SHA-256 hash of the access_token. Required when authenticating with the resource server.
  • htcd: Optional base64-encoded SHA-256 hash (content digest) of the HTTP request payload used to validate integrity.

Each DPoP proof must be unique and cannot be reused across requests.

OAuth-Client-Attestation-PoP?string

OAuth-Client-Attestation-PoP proof JWT that demonstrates:

  • Proof-of-possession of a private key from a wallet instance
  • Binding to OAuth-Client-Attestation JWT

OAuth-Client-Attestation-PoP and client attestation in general are offered as closed beta preview features and are not generally available yet. If you are interested in trying this feature, please contact us

When to use:

  • Token endpoint: When OAuth Client has client attestation enabled with dpopRequired set to false.

The OAuth-Client-Attestation-PoP proof MUST be signed with a wallet instance's private key that corresponds to the cnf.jwk claim from the provided OAuth-Client-Attestation and must use the following structure:

Header:

  • alg: Must be ES256
  • typ: Must be oauth-client-attestation-pop+jwt

Payload:

  • aud: HTTP Host of the target endpoint
  • jti: Unique identifier for this OAuth-Client-Attestation-PoP proof
  • iat: Unix timestamp when the OAuth-Client-Attestation-PoP proof was created

Each OAuth-Client-Attestation-PoP proof must be unique and cannot be reused across requests.

OAuth-Client-Attestation?string

JWT generated by the Client Attester (Backend) attesting to a validated Client Instance and bound to a key managed by the Client Instance, ensuring proof of possession.

Client Attestation support is currently offered as a tech preview. As such, functionality may be limited, may not work in all scenarios, and could change or break without prior notice.

When to use:

  • When client attestation is configured for this client_id

Header:

  • alg: Must be ES256
  • typ: Must be oauth-client-attestation+jwt
  • x5c: Must be an array of base64 encoded X509 End-Entity certificates bound to the configured client attestation root certificate.

Payload:

  • sub: OAuth client_id matching the request
  • client_instance_id: Optional identifier to represent the client/app instance.
  • iat: Unix timestamp when the token was created
  • exp: Unix timestamp when the token will expire
  • cnf.jwk: JWK public key from the client instance that the authorization server uses to verify the signature of subsequent DPoP or PoP proofs.

Request Body

application/x-www-form-urlencoded

client_id*string

The client identifier.

grant_type*string

The grant type, which must be 'authorization_code'.

Value in"authorization_code"
redirect_uri*string

The redirect URI that was used in the authorization request.

code*string

The authorization code obtained from the authorization endpoint.

code_verifier*string

SHA256 hash of the code_challenge in the authorization request.

Response Body

application/json

application/json

text/plain

curl -X POST "https://example.vii.au01.mattr.global/v1/oauth/token" \  -H "Content-Type: application/x-www-form-urlencoded" \  -d 'client_id=string&grant_type=authorization_code&redirect_uri=string&code=string&code_verifier=string'
{
  "access_token": "KrrFP8GUeddJJtj7EF-4ugdvCl-dDdWwOqvAbvYsmfy",
  "token_type": "Bearer",
  "expires_in": 900,
  "scope": "mso_mdoc:org.iso.18013.5.1.mDL"
}
{
  "code": "string",
  "message": "string",
  "details": [
    {
      "value": "string",
      "msg": "Invalid value",
      "param": "id",
      "location": "body"
    }
  ]
}
"Unauthorized"
Empty
Empty

How would you rate this page?

Request authorization for access to resources GET

This endpoint is used to request authorization from the user for access to the requested resources. After the user approves the request, an authorization code is returned to the client. See [https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-authorization-endpoint](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-authorization-endpoint) See [https://www.rfc-editor.org/rfc/rfc6749.html#section-3.1](https://www.rfc-editor.org/rfc/rfc6749.html#section-3.1) ### **Analytic events** * OPENID_AUTHORIZE_START * OPENID_AUTHORIZE_SUCCESS * OPENID_AUTHORIZE_FAIL

Issue a verifiable credential POST

Issues a credential to a holder upon presentation of a valid access token, as per [OpenID4VCI](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-credential-endpoint). Supports [encrypted](/docs/issuance/credential-issuance/e2e-encryption) and non-encrypted credential issuance. <Callout> Encrypted credential issuance is currently in technical preview and must be enabled on a per-tenant basis. If you would like to enable this feature for your tenant, please [contact us](mailto:dev-support@mattr.global). </Callout> For non-encrypted credential issuance the valid access token must be provided in one of the following header formats: **Bearer** - Authorization: `Bearer <access_token>`. - Content-Type: `application/json` - Body: `<credential request payload>` OR **DPoP** Only required when using DPoP-bound access tokens. - Authorization: `DPoP <access_token>`. - DPoP: `<dpop_token>` - Content-Type: `application/json` - Body: `<credential request payload>` For encrypted credential issuance, [contact us](mailto:dev-support@mattr.global) to configure how your MATTR VII enforces request and/or response encryption, and then: - For **request** encryption, `Content-Type` must be set to `application/jwt` and the payload must be JWE formatted. - For **response** encryption, include the [`credential_response_encryption`](/docs/issuance/credential-issuance/e2e-encryption#encryption-key-provisioning) property in the raw request payload to specify encryption details. ### **Analytic events** * OPENID_CREDENTIAL_START * OPENID_CREDENTIAL_SUCCESS * OPENID_CREDENTIAL_FAIL