I’m currently trying to gain more knowledge about the new way of customizing with the Kinetic App Studio. I noticed that we can now directly call an Epicor Function directly from a buttonclick, which is a great improvement! I was wondering, since we need an API Key, what would be the best practice for this.
Right now, in E10, we make sure the API Key from the Production and Test server are different from each other for security reasons. The API Keys are now only used for a few external applications, which is still easy to manage. But what if we start using API Keys for every customization we make? Will we have to change the API Key each time we copy the customization from the Test server to the Production server? Will we have to change all API Keys in all the customizations whenever a copy is made from Production to Test?
I wonder what your findings or suggestions are.
Thanks in advance!
The best practice is to use a secrets manager like Azure Key Vault or Hashicorp’s Vault.
The vault grants access to the identified user for the API-KEY and looks it up for the session. When it’s time to roll the key, you could use PowerShell to change it in Epicor and then update the Vault.
I haven’t done a SPA application yet but I’ve read about solutions using a JWT where once the user authenticates, the app passes an “API key” in the JWT based on some pre-defined scopes. Here’s an article that explains the idea.
Using JSON Web Tokens as API Keys (auth0.com)
But for non-SPA applications, the vault should work.
Question, if you’re staying within your Azure AD domain, and you’ve given role-based read permissions to the vault, couldn’t one still use a vault to get the API-KEY? It’s the anonymous Internet user that’s the problem, right?
OK, there is the case where might be able to sniff out the API-KEY. The only solution I have heard about this is to create a proxy that talks to the API and that proxy would have a managed identity that would get the API-KEY. Kinda kicking the can down the road though…
well, yes, that doc as other examles also contains lines:
export AZURE_CLIENT_ID="generated-app-ID" export AZURE_CLIENT_SECRET="random-password"
so it replaces one secret we want to hide with another.
Theoretically it should be possible to give access GET permission for some secret to my AAD user that I use from browser, and it will probably work. But I never saw it so far.
But you are right - proxy now is new cool way to go - client only supposes to have http-only cookie and everything else should be done in BFF - backend for frontend - get JWT and API key from that cookie and send request to API server.