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

Kristian Haahr 1 Reputation point
2021-11-24T17:22:20.283+00:00

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.
    1. 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?
Azure Key Vault
Azure Key Vault
An Azure service that is used to manage and protect cryptographic keys and other secrets used by cloud apps and services.
711 questions
Azure App Services
Azure App Services
A feature of Azure App Service used to create and deploy scalable, mission-critical web apps.
4,605 questions
Azure Active Directory
Azure Active Directory
An Azure enterprise identity service that provides single sign-on and multi-factor authentication.
13,673 questions
Microsoft Graph
Microsoft Graph
A Microsoft programmability model that exposes REST APIs and client libraries to access data on Microsoft 365 services.
911 questions
No comments
{count} votes

1 answer

Sort by: Most helpful
  1. Ryan Hill 16,696 Reputation points Microsoft Employee
    2021-12-02T04:12:07.047+00:00

    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.

    configure-auth-back-end.png

    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.