OutSystems itself doesn’t remove that capability; it’s mostly a scope and responsibility choice of the standard biometric plugins and of OutSystems’ mobile architecture.

In practice, there are three different layers that often get mixed up:

1. Local biometric check (OS‑level)
2. Cryptographic operations (key pairs, signatures, challenges)
3. Application/server authentication (tokens, sessions, REST)

The Forge “biometric” plugins you see typically implement only (1), and sometimes (2) is left entirely to OS native APIs or other custom plugins. Here’s why.

1. What the typical OutSystems biometric plugins actually do

Most Forge biometric plugins (TouchID, Fingerprint, generic Biometric/FaceID, etc.) are thin wrappers over:

• iOS LocalAuthentication (LAContext)
• Android BiometricPrompt / FingerprintManager

Those APIs are primarily meant to answer:
“Is the real device owner present and authenticated?”

So the plugin exposes actions like:

• IsAvailable
• Authenticate → returns Success/Fail message

They don’t define any opinionated, end‑to‑end authentication protocol for your app (token flow, key management, challenge‑response). That protocol is intentionally left up to you to implement at app + backend level.Mobile Application Architecture -- Plugins, UI & Security

2. Why you don’t see “digital signature / challenge / public‑private key” out of the box

There are a few reasons this is not bundled directly into the standard biometric plugins:

1. Different use cases, different cryptographic flows

   • Some apps want OAuth2/JWT tokens only (server signs tokens with its private key).
   • Others want device key pairs and signed challenges.
   • Others only use biometrics to “unlock” a locally stored refresh token.
     If the plugin forced one fixed “digital signature + challenge” scheme, it would not fit many enterprise setups.Enterprise Mobile Apps for Millions of Users – Service Security Implementation Using OAuth2

2. Key management belongs in the OS secure keystore, not in OutSystems
   Generating, storing, and using keys is done via:

   • iOS Secure Enclave / Keychain
   • Android Keystore
     Those APIs are platform‑specific and not directly part of the LocalAuthentication / BiometricPrompt APIs. So you usually need:
   • One plugin for “Biometric prompt”
   • Another plugin (or extended code) for “KeyPair generation + Sign/Decrypt” The Forge plugins you see often cover only the first.

3. Security responsibility and flexibility
   OutSystems recommends you keep:

   • Private keys / strong crypto either server‑side,
   • Or, if on device, well‑isolated in native code / OS keystore, with a well‑defined threat model.
     That tends to be solution‑specific, so the platform and generic plugins avoid baking in a generic crypto protocol and instead let each project decide between:
   • OAuth2/token‑based flows (most common and easier), or
   • Custom device‑key flows (more advanced).Mobile Application Architecture – Security: Data Storage and Encryption Best Practices

4. Mobile app architecture in OutSystems
   OutSystems 11 mobile follows a “plugins + client actions + REST” pattern:

   • Plugin: gives you low‑level capabilities (biometric check, crypto, camera, etc.).
   • Client action: orchestrates those calls.
   • REST integrations: talk to your backend.
     The authentication logic (including any challenge/response, digital signatures, tokens) is expected to live in:
   • Your client actions (front‑end flow) +
   • Your server modules / external APIs,
     rather than inside a single plugin.Mobile Application Architecture -- Plugins, UI & Security

3. How to get to a challenge / signature / key‑pair flow in OutSystems O11

Even though the standard biometric plugins don’t directly expose “SignChallengeWithPrivateKey”, you can still implement the full flow in OutSystems by combining pieces:

Option A – Recommended in most projects (OAuth2‑style)

• Use biometrics only to unlock the app (local user presence check).
• After biometric success, call your backend’s /token/refresh endpoint.
• Backend uses its own private key (e.g. to sign JWTs) and returns short‑lived access tokens.
• No private key living in the mobile app; no need for device signature logic.Enterprise Mobile Apps for Millions of Users – Service Security Implementation Using OAuth2

Option B – Device key pair + challenge/response (what you’re asking about)
You can design it like this:

1. First login (password, MFA…)

   • Backend authenticates normally.
   • Mobile calls a native plugin that:
     • Generates a key pair in the OS keystore.
     • Marks the private key as “user authentication required” (biometric).
   • Mobile sends the public key to your backend, bound to user + device.

2. Subsequent “biometric login”

   • Mobile calls biometric plugin → if OK, the OS allows use of the private key.
   • Mobile calls backend GET /auth/challenge.
   • Backend returns a random nonce / challenge.
   • Mobile asks the crypto plugin to sign the challenge using the private key.
   • Mobile sends signed challenge + device ID to POST /auth/verify.
   • Backend verifies signature with stored public key and issues a token/session.

In OutSystems 11, this becomes:

• Client actions:

  • BiometricCheck() from the biometric plugin.
  • GenerateDeviceKeyPair() and SignData() from a custom/native plugin (or an extended Forge plugin).
  • QuickLogin() orchestration (call biometric, call REST challenge, sign, call REST verify).

• Server:

  • Exposes /auth/challenge and /auth/verify.
  • Stores public keys, validates signatures using .NET/Java crypto libs.

So the reason you don’t see this “out of the box” is:

• Standard biometric plugins purposely solve only the “local biometric check” problem.
• The crypto + protocol part is considered application‑specific and normally implemented:
  • As custom or extended plugins (for key pair + signing), and
  • In your OutSystems server modules / external services (for challenges and verification).

If you share which plugin you’re using and whether your backend is OutSystems or external, you can layer this flow on top of the plugin you already have.