API security, deamon app, multi tenant - chicken and the egg

Question

Hi fellows,

alright, im building saas application, but i'm concern a little bit about the security. I hope you can point me the right direction.

I have many components in play. Graph api, my own api, my own web app with user auth(openid microsoft work accounts) and my own client with code flow auth (client credentials).

So my concern is that, my client has to store the clientId (its the same for all the tenants who accepted admin consent) and the clientSecret.

1. concern is that, if the clientid and secret will be stolen from the client, then it can be used to get an access token for other tenants.
   i'm creating a client secret pr. customer, and i'm using role based authorization, so the damage can be stopped by deleting the clientSecret for that
   single customer and the access to resources is limit.
   2. concern, is how the hell can i store the clientid and clientSecret safe on the client machine. I can use key vault, but in that case, i need to store vaultname, appid, and thumbrint instead. My brain are going in inception mode. Should i go for key vault method and encrypt the appid and thumbrint? if yes, how to encrypt it as best practise?

Answer 1

Hi @Kristian Haahr ,

Personally, I never liked authentication because it's so complex and tiresome. Having said, I can tell what I do know it hopefully it helps.

For your first concern, I wouldn't go the route of creating a client secret per customer. Utilize the client secret per app (service) as stated in best practices. Through the App Registration, you can control who can or can't login through the provider (screenshot below) through the provider. Which means you can utilize delegate permissions for signed in users. Since the delegate permission will use the user to get the access token, you can restrict users that are allowed to receive that token.

As for your second concern, if by client you mean someone running a desktop application, you can leverage the Azure Identity libraries to access the Key Vault. That SDK will utilize a user that has signed into the AD tenant to access the key vault. This does assume that user identity is associated with an access policy. You can place all client id, secret, etc. in the key vault and all the application needs is the KeyVault URI and an identity with said access policy on it. It's the route I would take to avoid storing sensitive information with the app. Another bonus side is you can change app registrations, secret values, etc. without even having to change application code or update application settings.

Kick it up another notch by leveraging App Configuration to retrieve Key Vault reference values based on certain feature flags. That way, all you app knows is an app configuration endpoint and key vault values are retrieved at runtime.