How do I hide/encrypt connection strings or API keys in my web parts?

[kbeeveer46]

I am making API calls in my web parts to get information from other apps within our company (not hosted in SharePoint).  I am storing the API keys and connection strings (urls) to these APIs in a settings files but all of it can be viewed in plain text when I view the SharePoint site in the browser and look at the source code. The same goes for API keys that are required to use third party software in my web parts. Is there a way to hide this information from the user? Thanks.

[#2 · Accepted solution]

For APIs, they should be secured with Azure AD and requests should be authenticated in order to reach the API, so should not be a problem if the API URL is discovered by users as they would still need to authenticate.
Regarding API keys for services that may not support authentication, I would recommend creating a simple API to handle all the user requests. Like above, API would be secured by Azure AD and receive only authenticated requests from users. The keys to the last API could be secured with KeyVault and retrieved by your API when needed, so all handled on the backend and never exposed in the browser

Hope this helps

[#3]

@Joel Rodrigues Thanks for your response. I figured using the AadHttpClient was the way to go after doing some research. Do you know if it's possible to use the same app registration in Azure for multiple versions of the same API call? For example, I have DEV/QA/PROD versions of an API and they all use a different URL for the endpoint. For example, the QA one has "qa" at the beginning of the URL.

From what I've researched, when I create an app registration I have to use the endpoint URL (like qa.website.com/api) as the Application ID URI. If that's the case does that mean I have to create an app registration for DEV, QA, and PROD?

[#4]

@kbeeveer46 happy to help

Regarding the app registration, yes, you can use the same app for multiple APIs. You can do this by using (for example) the default naming convention for the App ID URL (api://id_of_the_app) instead of the function URL. You just need to ensure that when you setup the API authentication, you allow that App ID URL to be an accepted audience and also use that same value as the audience when getting the tokens from SPFx.

If you use one app registration for each API, just make sure that you use the correct App ID URI when requesting the token and all should work the same.

I think the discussion on whether to use one single app or multiple is complex and I won't go into it :) I have used both approaches in the past for different projects and it really depends on a lot of things. I think that the recommendation is to use one app per resource whenever possible, but this is not always possible. For example I had clients refusing this and enforcing a single app registration to multiple resources because of their internal policies. Either way, technically both works :)