Migration from 2.0.x to 2.1.x

View product v2.1.0

This guide contains instructions for migration from PowerAuth Cloud version 2.0.x to version 2.1.0.

Database Changes

For convenience, you can use liquibase for your database migration.

For manual changes, use SQL scripts:

`pa_activation` Table

This release enforces uniqueness of activation codes at the database level and aligns the activation_code column definition with the JPA entity. The changes are applied automatically by Liquibase. For details on each step, see the PowerAuth Server 2.1.0 migration guide.

MSSQL: a maintenance window is required. The migration drops the existing pa_activation_code index before adding the new unique constraint. Between these two steps, queries on activation_code will perform a full table scan. Plan a maintenance window before running this migration on MSSQL.

PostgreSQL / Oracle: a maintenance window is recommended. The unique constraint creation (index build) locks the pa_activation table and can take several minutes on large deployments. Plan a maintenance window before upgrading the application.

Add Column subject_id to audit_log table

Added a new indexed column subject_id holding an identifier linking the audit record to an entity it is related to (e.g. user ID for user-related audit records).

The auditing tables may be already updated in your database schema if the database schema is not separated for different PowerAuth applications. In case the column audit_log.subject_id and its index audit_log_subject_id_idx are already present, you can safely skip this migration step.

Migrate audit_log table data

If you are using the /v2/audit/log endpoint (for example, you are using the Admin Console web application), you need to migrate the audit_log table data. Otherwise, the endpoint will return no records created before 2.1.0 version.

The schema must be migrated first before migrating the data (see the previous section).

The migration scripts for the supported databases, along with instructions on how to use them, can be found here:

Configuration Updates

The activation removal endpoint can be configured to allow authentication using POSSESSION factor (1FA). By default, two-factor authentication is used when removing activations, either POSSESSION_KNOWLEDGE or POSSESSION_BIOMETRY.

You can enable 1FA for activation removal by setting the environment variable:

ENROLLMENT_SERVER_ACTIVATION_REMOVE_ALLOW_1FA=true

REST API Updates

GET /v2/registrations/{registrationId}

The response has been extended with:

a new protocol attribute indicating the protocol used for the registration (possible values are powerauth and fido2)
a new externalId attribute containing the external ID associated with the registration

GET /v2/registrations

Each registration returned by the endpoint has been extended with:

a new protocol attribute indicating the protocol used for the registration (possible values are powerauth and fido2)
a new externalId attribute containing the external ID associated with the registration

POST /v2/registrations

Registration request body has been extended with:

a new additionalData attribute - The registration’s custom attributes set through a private API in a free JSON structure.

POST /v2/fido2/assertions/challenge

The endpoint has been modified:

a new optional attribute userId is accepted, allowing to specify the user for which the assertion challenge is generated
the externalId attribute is no longer mandatory

the response has been extended with the allowCredentials attribute (credentials associated with the assertion), using the following structure:

  {
    "allowCredentials": [
      {
        "credentialId": "string",
        "type": "string",
        "transports": [
          "string"
        ]
      }
    ]
  }

the response contains a new operationId attribute representing the operation ID the assertion is associated with

POST /v2/fido2/assertions

The appId attribute used to verify the challenge can be approved by given application is no longer mandatory. If not present, the user ID retrieved from response.userHandle is used to determine the application ID.

POST /admin/applications/{id}/push/hms

The appId attribute in the request body is no longer required and will be ignored if present. The path parameter is used exclusively.

POST /messages/send

The call now supports an optional numerical value for badge displayed as a badge on the app icon.

Last updated on Apr 30, 2026 (08:20) View product