Migration from 2.0.x to 2.1.x

View product develop

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

Database Changes

Liquibase is used for automated migration of database schema during startup of PowerAuth Cloud backend components.

The optional migration of the audit_log table data must be performed manually if needed, as described in the Migrate audit_log table data section.

The audit_log table column subject_id and the related audit_log_subject_id_idx index are added as part of the Liquibase migration. Based on the data volume in the audit_log table, the index creation may take very long time and cause Liquibase timeout. Therefore, it is recommended to add the column and the index manually before running the Liquibase migration.

To do so, apply one of the following SQL scripts based on your database platform. The Liquibase migration can be run safely afterwards as it will ignore any objects that already exist.

Postgres

ALTER TABLE audit_log ADD subject_id VARCHAR(256);
CREATE INDEX CONCURRENTLY audit_log_subject_id_idx ON audit_log(subject_id);

Oracle

ALTER TABLE audit_log ADD subject_id VARCHAR2(256);
CREATE INDEX audit_log_subject_id_idx ON audit_log(subject_id) ONLINE;

MSSQL Standard edition

ALTER TABLE audit_log ADD subject_id varchar(256);
GO
CREATE NONCLUSTERED INDEX audit_log_subject_id_idx ON audit_log(subject_id);
GO

MSSQL Enterprise edition

ALTER TABLE audit_log ADD subject_id varchar(256);
GO
CREATE NONCLUSTERED INDEX audit_log_subject_id_idx ON audit_log(subject_id) WITH (ONLINE = ON);
GO

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 before migrating the data (handled automatically by Liquibase on startup).

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

Reporting registration flags in the public API can be enabled or disabled (default) using the following configuration property:

ENROLLMENT_SERVER_FLAG_REPORTING=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 May 26, 2026 (08:58) View product