When your app needs a secret, for example a secret from Azure app registration, then you have currently a few options:
* Store it in code, either as label or return value of an internal procedure
* Ship it with a navxdata file
* Manually enter the value through a setup page

Storing it inside code could potentially lead to leaking the secret. And when the secret is compromised, you need to update the app and deploy a new version. The same goes for using the navxdata file.
Code could be protected by setting show my code = false, but you still need to deploy a new version when the secret gets compromised.
Manually setup requires to share a secret, and then it's not a secret anymore. It's also not scalable as it requires manual setup.

Ideally, secrets are stored in an Azure Key Vault. But to access the key vault, the app needs its own identity. Which still requires a secret.

My suggestion is to allow ISV's to specify the app identity when uploading the app to AppSource. Basically, two values are needed: client id and secret. Those two values should then become available to the app (and the app only) through the NavApp API. E.g. NavApp.AzureClientId and NavApp.AzureSecret.
Optionally, allow specifying more client id and secret combinations. A registered app in Azure can have multiple secrets, each of them has an id. So then you would get something like NavApp.AzureSecret(id).

The app can then use these values to acquire access tokens and get access to an Azure Key Vault.
Ideally, the platform also supports a module to access the corresponding Azure Key Vault. Then we don't have to reinvent the wheel. Currently, the System Application has a module for Azure Key Vault, but that's on-prem only.