I have a WPF app that collects secrets from an Azure Vault. I have created an App Registration in Azure that has access to my vault. In order to get a vault token I need to either store the app reg secret in code or use a certificate. An advances hacker who has access to my apps bin folder will be able to untangle both of these methods even if I put the secrets in an encrypted config file.
I have tried using Microsoft Entra ID to collect the logged in user information and then collect the vault token through Microsoft Graph but cannot get this to work (not sure if it's possible). I do not want to provide the user access to the vault. The access must go through the App Registration. Is there another method available and what is the most secure way?
Welcome to the site Kelby. This may be a better question for the Software Engineering forum, but let me share some thoughts based on my experience with a Windows desktop app and Entra ID authentication.
First off, you can never let a client app access a Key Vault directly. Full stop. I hate to say never and often criticize others for doing so, but in this case, it really is never. We can prove, mathematically/logically, that there is no such thing as trustworthy client software. You clearly have this inclination already - so embrace it and live by it. If there's something in that key vault that protects a resource the client app needs, you need to use an intermediate server (ASP.NET Core WebAPI or what have you) as a go-between for the resource.
Speaking about authentication generally, however, it's not out of the question for a client app to have the app registration "secrets" (such as they are) needed to initiate an Oauth login and access APIs, provided the app's only permissions on the Azure tenant are delegated, rather than application-level. This means a human user must authenticate through the Oauth2 process and provide credentials, MFA, etc., through the Entra login pages, and then receives a bearer token back for making Azure API calls.
In this setup, even if the "secrets" leaked (and I keep air-quoting "secrets" because if the client app has them, they are by definition not secret), the worst case scenario is that an attacker uses them to make their own app for making malicious API calls. The problem for the attacker is that he still needs the user credentials and to get past MFA, and if he could did that, he could just go straight to the Azure Portal, but in any case he doesn't need your app key or secret to get there.
Consider Azure Storage Explorer - not a WPF app, but it accesses Azure APIs directly. Same with the Azure Powershell scripts. The app ID and app secrets and/or private certificate keys are buried somewhere deep and they're made to be really hard to find, but they're there. But critically, these "apps" only ever have delegated permissions on the tenant.
All this having been said, in production contexts, very few security professionals are going to allow ANY Azure resource other than simple directory info (user profile, etc.) past their firewall and let your client app access them directly. Storage Explorer etc. are meant to be used either in development, or behind a firewall or by a whitelisted IP, etc. So in practice, the only thing the WPF app likely will be allowed to do on the tenant is authenticate and get user profile information. For anything more you will need to have an intermediate server between the app and the backend resources.