Aug 18 2021 03:48 PM - edited Aug 18 2021 05:30 PM
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.
Aug 19 2021 12:53 AM
SolutionAug 19 2021 05:54 AM
@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?
Aug 19 2021 07:52 AM
@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 :)
Aug 19 2021 12:53 AM
Solution