Skip to main content

Mobile Authentication Use Cases

This section shows how to configure each Nevis Mobile Authentication use case with nevisAdmin 4 patterns.

Before you configure any use case, set up the nevisFIDO component itself. See nevisFIDO Setup.

The central pattern​

Every use case on this page connects to the same nevisFIDO backend. In most projects that backend is a nevisFIDO UAF Instance pattern, which both deploys nevisFIDO and holds the settings that apply across use cases, such as the link type, the Firebase configuration and the policies.

If nevisFIDO is deployed by a different project, assign a nevisFIDO UAF Connector pattern instead. The nevisFIDO field of every use case pattern accepts either, so the pages below apply unchanged. The settings described on this page then live in the project that owns the instance.

One instance per virtual host

If you create more than one nevisFIDO UAF Instance, connect each one to a different Virtual Host.

The URLs that nevisFIDO allocates on a virtual host are fixed, that is, they always start with /nevisfido/, and they map to exactly one nevisFIDO backend. A second instance on the same virtual host would claim the same URLs. nevisAdmin 4 rejects such a configuration during validation.

Keep one flow on one virtual host

Every pattern that takes part in the same flow must be assigned to the same Virtual Host. Each pattern exposes its own paths, and it exposes them only where it is assigned.

nevisAdmin 4 validates each pattern on its own, so a configuration split across two virtual hosts generates and deploys without a single error. The failure appears at runtime, as a 404 on whichever path was left on the other host, which is hard to trace back to the cause. If a flow works up to a certain call and then stops, compare the Virtual Host field of every pattern involved before looking anywhere else.

Settings that apply to more than one use case​

A few settings do not belong to any single use case. They are configured once on the nevisFIDO backend (on the nevisFIDO UAF Instance pattern in the project that owns the instance) and then gate several of the flows below, which is why a use case can be configured completely and still not work.

SettingWhat depends on itIf it is not set
Link Type, together with Deep Link or Custom URI LinkOnboarding, every out-of-band flow that shows a QR code or a link, and all mobile-only operationsThe rendered code or link cannot reach the mobile application
Firebase ConfigurationPush notification delivery, used by transaction confirmation and out-of-band authenticationNo push notification is sent, so the operation is never delivered unless another channel is configured
PoliciesEvery registration and authentication operationdefault.json is mandatory, and it is applied whenever an operation does not name a policy

Set these before configuring the individual use cases. See Policies and Mobile-Only Operations with Deep Links and Custom URIs.

Editing the project as YAML

The name of a field in the user interface is not always the key used in the project files. Link Type is stored under the key link, not linkType.

This only matters if you edit a nevisAdmin 4 project directly in its Git repository rather than in the user interface. An unrecognized key is not applied, so the setting silently keeps its previous value. If you filled in Deep Link but the link type never took effect, nevisAdmin 4 reports Configuration is unused. Set 'Link Type' to 'Deep Link'. during generation.

Credential lifecycle​

These use cases create, use and remove the FIDO UAF credential on the user device. They follow the order in which a credential is normally used.

  • Onboarding - let a user set up the mobile app and register a credential as part of a self-registration flow, before the user has any other authentication means.
  • Registration - register a mobile device for a user who is already authenticated.
  • Authentication - authenticate a user with a registered device, either as the only factor or as a second factor.
  • Transaction Confirmation - have the user confirm the details of a specific operation, such as a payment, on the mobile device.
  • Deregistration - remove a registered device, for example when the user replaces the phone.

Managing registered devices​

  • Device Management - let the mobile application query and update its own device information, such as dispatch targets and registered authenticators, and pick up pending out-of-band operations.

The paths that back this are exposed by the nevisFIDO UAF Device Service pattern, but several of the use cases above already expose them. Check whether you need the pattern before adding it.

Controlling how authentication happens​

These use cases do not add a separate flow. They constrain the flows above.

  • Policies - decide which authenticators are acceptable, for example whether a PIN is sufficient or biometrics are required.
  • App Attestation - verify that the app talking to nevisFIDO is your genuine, unmodified app.

Reaching the mobile app​

This is a matter of how the out-of-band message reaches the app, not a separate use case. The setting that controls it, the link type, is part of the nevisFIDO UAF Instance pattern.