Redirect URIs, Client Types, and Signing Keys

Three registration-time decisions shape your integration: redirect URIs, client type, and signing keys.

Redirect URIs. Register every exact redirect URI your application uses. OIDC Web validates the redirect_uri on each request against this list and rejects unregistered URIs. For Financial-grade API (FAPI) signed-request clients, the check is strict and the redirect_uri is mandatory.

Client type.

• Confidential client — a server-side application that can keep a secret or a private key. Use a strong client-authentication method (see Client Authentication).
• Public client — a single-page app or native/mobile app that cannot keep a secret. A public client authenticates with none and must use PKCE, Proof Key for Code Exchange (see Auth Code Flow).

Signing key (strongly recommended). We recommend signed authorization requests (see JAR) for every production client. To use them, generate an asymmetric key pair: EC P-256 for ES256, or RSA for PS256/RS256. Keep the private key in your application and register the public key with your client.

OIDC Web verifies your signed requests against the registered key. The same key can serve for private_key_jwt client authentication (see Client Authentication).

Recommendation. Provision a signing key and ask iProov to configure your client to require signed requests. The required-signing configuration protects you from the resource-abuse risks described throughout this guide.