You can split your solution into two layers and implement both fully in OutSystems 11:

1. Local biometric authentication (device-level)
2. Server-side authentication using asymmetric keys (public/private key) exposed via REST

Below is a concrete approach for each part.

1. Biometric authentication in the mobile app

In OutSystems 11 mobile, biometrics is done through a native plugin.

a) Choose / install a biometric plugin

On Forge you’ll find plugins like:

• Touch ID / Face ID (iOS)
• Fingerprint / Biometric (Android)

Install the plugin module into your environment, then:

• Add the plugin’s client actions to a core mobile module (typically your main app module or a dedicated “Device” module).
• Expose wrapper client actions if needed (e.g. DoBiometricLogin()).

This matches the recommended “plugins + client actions” architecture for mobile apps: plugins expose JavaScript/native APIs and are consumed via client actions in your app logic.Mobile Application Architecture -- Plugins, UI & Security

b) When to ask for biometrics

A common pattern:

1. First login:

   • User enters username/password (and OTP if you have it).
   • You authenticate against your backend (normal login).
   • If successful, ask: “Enable biometric login on this device?”
   • If yes, store only a flag and a device-specific token, not the password. For example:
     • IsBiometricEnabled (Client Variable or Local Storage)
     • DeviceToken (issued by your backend, see section 2)

2. Next logins:

   • If IsBiometricEnabled = True, show a “Login with Face/Touch ID” button.
   • On tap, call plugin’s biometric check:
     • If biometric auth OK → proceed to your “secure login” flow using the device token / key pair (section 2).
     • If biometric fails → fallback to username/password.

Do not store passwords locally; this is explicitly discouraged.Mobile Application Architecture -- Security > Data Storage and Encryption Best Practices

2. REST authentication using public/private keys

You mentioned “validate using private - public key” via REST. In practice there are two main patterns you can use with OutSystems:

Option A – Token-based (OAuth2-like) approach

This is the most common and aligns with OutSystems best practices.Enterprise Mobile Apps for Millions of Users > Service Security Implementation Using OAuth2

Conceptually:

1. Initial online login (username/password + possibly OTP):

   • Backend API validates credentials.
   • Backend returns:
     • Short-lived Access Token
     • Long-lived Refresh Token
     • Optionally a Device Token bound to that device
   • Mobile stores:
     • Refresh Token (encrypted storage)
     • Device Token (if you use device binding)
     • A flag IsBiometricEnabled = True once user has enabled biometrics.

2. Quick login (biometric):

   • User opens app → clicks “Biometric Login”.
   • Plugin verifies fingerprint/face locally.
   • On success:
     • Mobile calls a secure REST endpoint like POST /token/refresh with:
       • Refresh Token
       • Device Token (if you’re binding tokens to device)
     • Server verifies tokens, returns:
       • New Access Token
     • App uses the Access Token in the Authorization header for subsequent API calls.

3. Security aspects:

   • No username/password stored on device, only tokens.
   • Tokens can be revoked if the device is lost or compromised.
   • Access Tokens short-lived (e.g., 5–10 min). Refresh Tokens longer-lived, but tied to user + device.Enterprise Mobile Apps for Millions of Users > Service Security Implementation Using OAuth2

Where do the public/private keys come in?

In OAuth2-style flows, asymmetric keys are typically used server-side to sign and validate tokens (e.g., JWTs). The mobile app does not need to hold the private key:

• Server: Has a private key; signs tokens.
• Mobile: Only receives tokens; verifies them indirectly (or just trusts server responses).
• Other services: Can verify token signatures using the server’s public key.

This keeps private keys out of the device while still using asymmetric crypto.

Option B – Device key pair + signed challenge

If you really want a flow where the mobile device itself has a key pair:

1. Device key generation:

   • On first successful login, use a native plugin (or custom plugin) to:
     • Generate a private/public key pair inside the OS secure enclave/keystore.
     • Private key never leaves device.
   • Send only the public key to your backend over HTTPS and associate it with:
     • User ID
     • Device ID

2. Quick login (biometric):

   • App calls biometric plugin:
     • Biometric OK → plugin unlocks use of the private key.
   • App calls the backend GET /auth/challenge (no auth yet):
     • Backend returns a random challenge (nonce).
   • App asks plugin to sign the challenge with the private key.
   • App calls POST /auth/verify with:
     • Signed challenge
     • Challenge ID
     • Device ID
   • Backend:
     • Finds the stored public key for that device.
     • Verifies the signature.
     • If valid → authenticates the user and returns an Access Token / session.

3. From OutSystems perspective:

   • Mobile app:
     • Calls plugin actions for key generation and signing (client actions).
     • Calls REST methods (/auth/challenge, /auth/verify) using standard REST integrations.
   • Backend:
     • Can be OutSystems or external.
     • Validates signatures using its crypto libraries.

Again, no password is stored on the device, and the private key never leaves the secure keystore.

3. How to implement in OutSystems 11 (summary step-by-step)

1. Mobile app module

   • Install biometric plugin from Forge.
   • Create client actions:
     • BiometricCheck(): wraps plugin call and returns IsAuthenticated.
     • QuickLogin(): orchestrates flow:
       1. Call BiometricCheck().
       2. If OK:
          • Option A: Call RefreshToken REST and set user/session.
          • Option B: Call GetChallenge, sign, call VerifyChallenge.
       3. Navigate to Home.

2. Security / Token / Key logic

   • If using OAuth2-style:
     • Implement or consume backend endpoints for /login, /token/refresh, etc.
     • Store tokens (Refresh Token, Device Token) in client variables or local storage with encryption.
   • If using device key pair:
     • Have server endpoints for /auth/challenge and /auth/verify.
     • Implement key storage and signature validation on the server.

3. Respect security best practices

   • Do not store passwords locally (even encrypted).Mobile Application Architecture > Security > Data Storage and Encryption Best Practices
   • Use HTTPS with proper TLS; consider SSL Pinning if you’re handling sensitive data.Mobile Application Architecture > Security > SSL Pinning for Secure HTTP Communications

If you share whether your backend is also OutSystems or an external service, and whether you control its implementation, I can suggest a more concrete flow (endpoint examples, data structures, and where exactly in OutSystems to place each part).