# Verifier Integration: choosing the right integration mode



# Verifier Integration: choosing the right integration mode

When integrating with the Verifier, pick the mode based on **where your app runs**, **whether you can securely store keys**, and **whether a user is involved**.

#### Quick decision checklist

- **Browser SPA / Mobile app (without a backend that can securely store keys)?** → Public + PKCE
- **Backend available and you can store keys securely?** → Confidential
- **No user, purely service-to-service?** → M2M (client\_credentials)

#### 1) [Public client — Authorization Code Flow + PKCE](https://knowledgebase.dome-marketplace.eu/books/identity-management-developer-guides/chapter/verifier-public-client-integration-authorization-code-flow-pkce)

Choose this if:

- Your client runs in an environment that **cannot keep secrets** (SPA in the browser, mobile app, desktop app).
- You want the simplest setup (no client keys/JWKS to manage).

What it implies:

- Client authentication at `/oidc/token`: **none**
- Security for the code exchange: **[PKCE](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce) (`code_challenge` / `code_verifier`)**
- You still use the normal user login flow: `/oidc/authorize` → (wallet presentation) → `/oidc/token`

Recommended when: **front-end apps** and “quick testing” scenarios.

---

#### 2) [Confidential client — Authorization Code Flow + JWT-based client authentication](https://knowledgebase.dome-marketplace.eu/books/identity-management-developer-guides/chapter/verifier-confidential-client-integration-authorization-code-flow-client-secret-jwt)

Choose this if:

- You have a **backend** (or a secure server-side web app) that can **store keys securely** (vault/HSM).
- You want **strong client authentication** at the token endpoint.
- You plan to follow the stricter profile using **signed authorization requests (`request_uri`)**.

What it implies:

- Client authentication at `/oidc/token`: **JWT client assertion** (e.g., `client_secret_jwt` in our registrations, typically ES256 + JWKS)
- If you use `request_uri` at `/oidc/authorize`, use a **`did:key` client\_id** (signed request object profile).
- User login still applies: `/oidc/authorize` → (wallet presentation) → `/oidc/token`

Recommended when: **server-side apps** and partners wanting a “strongest” integration.

---

#### 3) [M2M (Machine-to-Machine) — Client Credentials](https://knowledgebase.dome-marketplace.eu/books/identity-management-developer-guides/chapter/verifier-m2m-integration-guide)

Choose this if:

- There is **no user interaction** (background jobs, service-to-service calls).
- You need tokens representing a **machine/service identity**, not a person.

What it implies:

- No `/oidc/authorize` and no redirects.
- Token request is directly to `/oidc/token` with `grant_type=client_credentials`.
- Requires a **machine credential** (LEARCredentialMachine) presented as part of the M2M flow.

Recommended when: **backend integrations** without a human login step.