For a full public/private key + challenge/sign flow in OutSystems 11, you have to go beyond the standard Key Store and Touch/biometric plugins and introduce a custom native plugin that exposes true key-pair and signing operations.

Below is the concrete picture.

1. What OutSystems gives you out of the box

• Biometric / Touch plugins

  • Do local biometric authentication (fingerprint / Face ID) and return success/failure.
  • They do not generate or use asymmetric key pairs directly; they just unlock the device security (keystore / keychain).

• Key Store Plugin

  • Securely stores key–value secrets in OS-level secure storage (Android Keystore / iOS Keychain).
  • From v2.3.0 you can require user authentication (PIN/biometric) for reading a value via KeyAuthentication.
  • It still doesn’t expose GenerateKeyPair or Sign actions; it’s for secure storage, not full asymmetric crypto.Key Store Plugin

So, OutSystems 11 does not have a ready-made plugin whose job is “generate key pair + sign challenge in OS keystore”.Get Public key from Plugin Touch Id

2. What you need for a full key-pair + challenge/sign flow

To implement the classic flow:

1. Device generates a private/public key pair in the OS keystore/secure enclave.
2. Device sends public key to your backend and associates it with the user/device.
3. When authenticating:
   • Backend returns a random challenge.
   • Device signs the challenge with the private key.
   • Backend verifies the signature with the stored public key.
4. If valid, backend issues a token/session.

You need a custom mobile plugin that exposes, at minimum:

• GenerateKeyPair() – returns the public key (string/bytes) while storing the private key securely on the device.
• SignChallenge(ChallengeData) – returns a signature produced by the private key.
• Optionally: HasKeyPair(), DeleteKeyPair(), etc.

On iOS/Android, this plugin will internally use:

• iOS: Keychain / Secure Enclave (SecKeyCreateRandomKey, SecKeyCreateSignature, etc.).
• Android: Android Keystore (KeyPairGenerator, KeyGenParameterSpec, Signature, with setUserAuthenticationRequired(true) for biometric/lock-screen protection).

You then wrap this native code as an OutSystems mobile plugin (Cordova-style) and consume it via client actions in your mobile module.Integrating Plugins with OutSystems

3. How biometrics (Touch plugin) and Key Store fit in

In this full flow, the relation between the three is:

• Biometric / Touch plugin

  • Used to unlock access to the private key (OS enforces that the key usage requires user authentication).
  • In some native implementations, the call to Sign will itself trigger biometric auth because the key is created with userAuthenticationRequired = true.

• Custom Key-Pair plugin (your implementation)

  • Owns the actual logic:
    • Generate key pair in OS keystore.
    • Sign arbitrary data (challenge) with the private key.
  • May internally use the OS keystore API in a way similar to what Key Store Plugin does, but focused on asymmetric crypto instead of simple key–value storage.

• Key Store Plugin (optional)

  • Can store:
    • Device identifiers
    • Non-cryptographic tokens
    • Flags (e.g., “biometric login enabled”)
  • All protected by PIN/biometric if you set KeyAuthentication = True.
  • It is not strictly required for the challenge/sign flow; it’s just a secure storage helper.Key Store Plugin

So:

• Touch/biometric plugin → authentication UX.
• Custom key-pair plugin → real cryptographic operations.
• Key Store plugin → optional secure data storage, but not the cryptographic core.

4. End-to-end flow in OutSystems (summarized)

First-time setup (after normal login)

1. User logs in with username/password (and OTP if you have it).
2. Backend authenticates and returns success.
3. Mobile app calls GenerateKeyPair() (custom plugin).
   • Private key stored in the OS secure keystore (biometric-protected).
   • Public key returned to the app.
4. App sends public key to backend via REST: POST /device/registerKey.
5. Backend stores:
   • UserId
   • DeviceId
   • PublicKey

Quick login (biometric + challenge/sign)

1. User taps “Login with Face/Touch ID” in your mobile app.
2. App calls biometric plugin:
   • If biometric OK, continue; else show fallback login.
3. App calls backend: GET /auth/challenge?deviceId=....
   • Backend returns random ChallengeId + ChallengeData (nonce).
4. App calls SignChallenge(ChallengeData) (custom plugin).
   • OS may prompt biometric again if configured; private key never leaves device.
   • Plugin returns Signature.
5. App calls backend: POST /auth/verify with:
   • ChallengeId
   • Signature
   • DeviceId
6. Backend:
   • Loads stored PublicKey for DeviceId.
   • Verifies signature over ChallengeData.
   • If valid → issues Auth Token / session; if invalid → deny.

All REST calls and orchestration are built with standard OutSystems REST integrations and client actions; the only non-standard part is the custom plugin itself.Get Public key from Plugin Touch IdIntegrating Plugins with OutSystems

So, to directly answer your question:

• For a full public/private key + challenge/sign flow, OutSystems 11’s Key Store and Touch plugins are not enough by themselves.
• You must create (or wrap) a custom native plugin that:
  • Generates the key pair in the OS keystore.
  • Signs challenges with the private key.
• Then use:
  • Biometric/Touch plugin to handle local user auth.
  • Your key-pair plugin for signing.
  • Optionally the Key Store plugin for other secure data on the device.

If you’d like, I can outline a minimal plugin API (JS signatures + client actions) tailored to your scenario.

Yes, the custom plugin does consist of Client Actions in OutSystems — that’s how you expose the native functionality to your mobile app.

How a custom plugin is structured in OutSystems 11

When you integrate a Cordova/native plugin in OutSystems, you create a plugin wrapper module (a library) that contains:

1. Client Actions

   • Each Client Action represents one operation of the plugin, for example:
     • GenerateKeyPair (returns public key)
     • SignChallenge (receives challenge, returns signature)
     • HasKeyPair
     • DeleteKeyPair
   • These actions must be Public so your mobile app module can reference them.Mobile Plugins

2. JavaScript nodes inside those Client Actions

   • Inside each Client Action you add a JavaScript node that calls the plugin’s API (the Cordova JS exposed by the native code).
   • This JS node is the actual “bridge” between OutSystems and the native plugin.Mobile Plugins

3. Extensibility Configurations (plugin URL)

   • In the plugin wrapper module, you configure the Extensibility Configurations with the Cordova plugin repository URL (GitHub, npm, etc.).
   • MOBS (Mobile Apps Build Service) uses this URL at build time to fetch the native plugin code and package it into the generated APK/IPA.Integrating Plugins with OutSystems

How your app uses it

• Your mobile app references the plugin wrapper module.
• In your app logic (Client Actions of your app), you call the plugin’s Public Client Actions:
  • e.g., Plugin_Auth.GenerateKeyPair(), Plugin_Auth.SignChallenge(ChallengeData).
• From the app’s perspective, they are just normal Client Actions; the JS inside them talks to the native plugin.

So, for your public/private key + challenge/sign flow:

• The custom plugin is a combination of:
  • Native code (Android/iOS) implementing key pair + sign.
  • OutSystems Client Actions + JavaScript that expose that native code.
• Without Client Actions, the OutSystems app would have no way to call the plugin.

If you want, I can sketch what the GenerateKeyPair and SignChallenge Client Actions would look like (inputs/outputs) for your scenario.