Authorization flow

The authorization code journey step by step, and what the A3BC interface changes to the standard.

1. Your service creates a transaction: it generates state and nonce and redirects the user to the authorization endpoint.
2. A3BC triggers authentication and consent out of band, in the TrustMe app (by identifier or QR code).
3. A3BC redirects the user to your redirect_uri with a single-use code and the state.
4. Your server exchanges the code at the token endpoint and receives an access_token and an id_token.
5. You verify the id_token, read the claims, and call the document API with the access_token if needed.

A3BC specifics

• The standard claims parameter is not supported as is; a mandatory variant is offered (see Mandatory claims).
• Claims requested through scopes are provided if available. If they are missing, the operation still succeeds: no error is raised.
• A single acr_values value is accepted and it is enforced (see ACR).
• The result can only be retrieved for 30 minutes.
• A transaction only fails if the user does not authenticate, does not consent, cannot satisfy the ACR, or on a technical incident.

Choosing your library

A certified OIDC library handles discovery, URL building, code exchange and id_token validation. With an OAuth 2.0 library, you configure endpoints manually and validate the JWT with a dedicated library. Either way you need: the issuer URL (or endpoints), the redirect_uri, the credentials, the scopes, and optionally acr_values and claims.