Skip to content

Transaction Signing⚓︎

Transaction signing can be directly initiated from the Mobile SDK. 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.

Create a transaction⚓︎

When directly creating a new transaction for signing in the Mobile SDK, only the clientadditionaldata (optional, data to sign), clientstate (optional, state information), 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.

=== Android

```java
// 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
}
```

=== iOS

```swift
// 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 user is logged in.

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.