Transaction Signing

Transaction signing can be initiated from the server or directly from the Mobile SDK. In the latter case, the transaction will only be stored in the server upon successful completion of the signing.

Server-side, the signed transaction can be retrieved from through the server API.

Server-initiated Transactions

Server-side, the transaction to be signed is created through the server API. As part of the response qrdata is returned. This data can then be encoded in QR code to be scanned by the app, or a deeplink when working on the same device.

To start the signing flow for a specific qrData:

AndroidiOS

try { 
    NextAuth.getNextAuth().getFlowManager().start(qrData);​
} catch (NextAuthException e) {
    // TODO: Handle exception
}

do {
  try flowService.start(with: data)
} catch {
    // TODO: Handle error
}

Handle Callbacks

The expected sequence of FlowUpdate callbacks (happy path) to be handled is as follows:

1. PROCESSING as its State -- the flow has started, but does not expect any input (yet). See here for more information.
2. WAIT_FOR_INPUT as its State. The CurrentUserInteraction.Type is CONFIRM_TRANSACTION -- asking the user to confirm the transaction to be signed. See here for more information.
3. PROCESSING as its State -- the nextAuth Mobile SDK is processing the users confirmation.
4. WAIT_FOR_INPUT as its State. The CurrentUserInteraction.Type is VERIFY_SECOND_FACTOR -- asking the user to enter their second factor for verification. See here for more information. The RequiredSecondFactorType restriction is taken into account when setting AllowedSecondFactors on the CurrentUserInteraction.
5. PROCESSING as its State -- the nextAuth Mobile SDK is verifying the user's second factor and signing the transaction.
6. DONE as its State -- the flow successfully finished, the transaction is signed.

Info

The FlowUpdate callback(s) for a flow with CurrentUserInteraction.Type = VERIFY_SECOND_FACTOR is mandatory for transactions. Contrary to logins, the entry of the second factor cannot be bypassed through caching.

Client-initiated Transactions

When directly creating a new transaction for signing in the Mobile SDK, only the clientState (optional, state information), clientAdditionalData (optional, data to sign), and requiredSecondFactorType (optional, which second factor is required) fields can be set. Creating a transaction either immediately starts a Flow of type SIGN_TRANSACTION, or it terminates with an error.

AndroidiOS

// prepare transaction object
Transaction transaction = new Transaction();

// optional
transaction.setClientAdditionalData(challenge);
transaction.setRequiredSecondFactorType(InteractionSecondFactorInfo.SecondFactorType.PIN);

// select first and only account
List<Account> accounts = NextAuth.getNextAuth().getAccountManager().getAccounts();
Account account = accounts.get(0);
try { 
    NextAuth.getNextAuth().getTransactionManager().create(transaction, account);
} catch (NextAuthException e) {
    // TODO: Handle exception
}

// prepare transaction object
let transaction = Transaction()

// optional
let transaction = Transaction(
    clientState: .init(),
    clientAdditionalData: .init(),
    requiredSecondFactorType: .pin
)

// select first and only account
guard let account = NextAuth.default.accounts.first else {
    return
}

do {
    try NextAuth.default.create(transaction: transaction)
} catch {
   // TODO: Handle error
}

Handle Callbacks

The expected sequence of FlowUpdate callbacks (happy path) to be handled is as follows:

1. PROCESSING as its State -- the flow has started, but does not expect any input (yet). See here for more information.
2. WAIT_FOR_INPUT as its State. The CurrentUserInteraction.Type is VERIFY_SECOND_FACTOR -- asking the user to enter their second factor for verification. See here for more information. The RequiredSecondFactorType restriction is taken into account when setting AllowedSecondFactors on the CurrentUserInteraction.
3. PROCESSING as its State -- the nextAuth Mobile SDK is verifying the user's second factor and signing the transaction.
4. DONE as its State -- the flow successfully finished, the transaction is signed.

Info

For client-initiated transactions, no CONFIRM_TRANSACTION interaction is used. The confirmation of the user can be asked before creating the transaction.

Info

The FlowUpdate callback(s) for a flow with CurrentUserInteraction.Type = VERIFY_SECOND_FACTOR is mandatory for transactions. Contrary to logins, the entry of the second factor cannot be bypassed through caching.