Dynamic Client Registration (DCR)#

Dynamic Client Registration is the fallback path mobile apps take when device attestation is unavailable or rejected. Instead of relying on Apple’s or Google’s hardware-attestation services, the app uses bundled credentials to register a per-device OAuth client at first launch and then uses that dynamic client for every subsequent HAAPI token request. Each install ends up with unique credentials that can be revoked individually.

How It Works#

The mobile app holds the credentials for a configured main HAAPI client. On a device where attestation fails, the SDK performs:

  1. A client_credentials grant against the token endpoint using the main client’s authentication method (Secret, MTLS, or Signed JWT) to obtain a one-shot initial registration token.
  2. A registration call to the DCR endpoint, exchanging the initial token for a freshly issued, per-device client whose credentials are typically generated on the device.
  3. From then on, the per-device client is used for HAAPI token requests in place of the main client.

the Curity Identity Server differentiates the two clients via a template client ID: the main client points to a registration template that defines the shape (capabilities, scopes) of the dynamic clients it creates.

Server-Side Setup#

Configure two clients on the server:

  • A main HAAPI client with a real authentication method (Secret, MTLS, or Signed JWT) — not no-authentication.
  • A template HAAPI client carrying the haapi capability and using the authenticate-client-by setting to point at the main client. The template defines what each dynamic client inherits.

The DCR endpoint URL and the template client ID are passed to the SDK as part of the DCR configuration so the client knows where and what to register against.

Trade-Offs#

DCR is genuinely less secure than hardware-backed attestation — the main client credentials, however protected, live on every install. Apps deploy DCR only when accepting devices without proper attestation support is unavoidable. For mixed fleets, the SDK’s HaapiAccessor builder selects the right path automatically, falling back to DCR only when attestation fails.

Was this helpful?