Move this out of appsettings.json:

  "Stripe": {
    "SecretKey": "sk_test_XXXX",
    "PublishableKey": "pk_test_XXXX",
    "WebhookSecret": "whsec_XXXX"
  },

…and into Azure Key Vault.

1. Which Stripe values are sensitive (and why)

Current configuration

  "Stripe": {
    "SecretKey": "sk_test_XXXX",
    "PublishableKey": "pk_test_XXXX",
    "WebhookSecret": "whsec_XXXX"
  },

Recommendation (pragmatic, consistent, future‑proof):

Move all three to Azure Key Vault

This avoids:

• Accidentally committing live values later
• Environment-mixing mistakes
• Special‑case handling in code

2. Add Stripe secrets to Azure Key Vault

Go to:

• Azure Portal → Key Vault → Objects → Secrets → Generate/Import
• Create three secrets, using the ASP.NET Core naming convention.

• Secret 1 – Stripe Secret Key
• Name: Stripe--SecretKey
• Value: sk_test_XXXX
• Secret 2 – Stripe Publishable Key
• Name: Stripe--PublishableKey
• Value: pk_test_XXXX
• Secret 3 – Stripe Webhook Secret
• Name: Stripe--WebhookSecret
• Value: whsec_XXXX

3. Remove Stripe keys from appsettings.json

Update your appsettings/json to remove the section entirely, (or leave "Stripe": { } if you prefer structural clarity)

4. Ensure Azure Key Vault is loaded early (same ordering rule)

In Program.cs:

var builder = WebApplication.CreateBuilder(args);

// Must come BEFORE any Stripe config is read
builder.Configuration.AddAzureKeyVault(
    new Uri("https://wcf-keyvault.vault.azure.net/"),
    new DefaultAzureCredential());
``

5. Bind Stripe configuration normally

If you already have a settings class, great. If not, create one in Data/Models:

namespace WebCashFlowV2.Data.Models
{
    public class StripeOptions
    {
        public string SecretKey { get; set; } = default!;
        public string PublishableKey { get; set; } = default!;
        public string WebhookSecret { get; set; } = default!;
    }
}

Register it in Program.cs

builder.Services.Configure<StripeOptions>(
    builder.Configuration.GetSection("Stripe"));

ASP.NET Core will now merge:

• Non‑existent JSON
• Azure Key Vault secrets

…into one clean StripeOptions object.

Step 6 – StripeOptions binding (minimal changes)

You already have this:

var stripeOptions = builder.Configuration
    .GetSection("Stripe")
    .Get<StripeOptions>() ?? new StripeOptions();

Leave this exactly as-is

Once you have these secrets in Key Vault:

Stripe--SecretKey
Stripe--PublishableKey
Stripe--WebhookSecret

ASP.NET Core automatically maps them to:

Stripe:SecretKey
Stripe:PublishableKey
Stripe:WebhookSecret

…and Get() will populate them correctly.

Add one safety check (recommended)

Immediately after binding, add validation:

if (string.IsNullOrWhiteSpace(stripeOptions.SecretKey) ||
    string.IsNullOrWhiteSpace(stripeOptions.PublishableKey) ||
    string.IsNullOrWhiteSpace(stripeOptions.WebhookSecret))
{
    throw new InvalidOperationException("Stripe configuration is incomplete.");
}

This ensures:

• Startup fails fast
• You don’t get mysterious Stripe runtime errors
• Live/test environment mix‑ups are caught immediately

Step 7 – Register Stripe with the Stripe SDK

This is the one step that often gets muddled, so let’s be explicit.

Stripe’s .NET SDK needs the SecretKey registered once at startup.

Add after your stripeOptions are loaded and validated:

Stripe.StripeConfiguration.ApiKey = stripeOptions.SecretKey;

• This replaces any previous hard‑coded Stripe key
• This pulls directly from Azure Key Vault via configuration
• This works for test and live keys without code changes

Step 8 – Register services (almost unchanged)

Your existing registrations:

builder.Services.AddSingleton(stripeOptions);
builder.Services.AddSingleton<StripeService>();
``

These stay exactly as they are

Your StripeService can now:

• Read SecretKey (already set globally)
• Use PublishableKey when needed
• Use WebhookSecret for signature validation

Nothing else needs to change.

Final, correct ordering in Program.cs (complete example)

Putting it all together, the correct final structure looks like this:

var builder = WebApplication.CreateBuilder(args);

// 1. Add Azure Key Vault FIRST
builder.Configuration.AddAzureKeyVault(
    new Uri("https://wcf-keyvault.vault.azure.net/"),
    new DefaultAzureCredential());

// 2. Bind Stripe configuration
var stripeOptions = builder.Configuration
    .GetSection("Stripe")
    .Get<StripeOptions>() ?? new StripeOptions();

// 3. Validate Stripe configuration
if (string.IsNullOrWhiteSpace(stripeOptions.SecretKey) ||
    string.IsNullOrWhiteSpace(stripeOptions.PublishableKey) ||
    string.IsNullOrWhiteSpace(stripeOptions.WebhookSecret))
{
    throw new InvalidOperationException("Stripe configuration is incomplete.");
}

// 4. Initialise Stripe SDK
Stripe.StripeConfiguration.ApiKey = stripeOptions.SecretKey;

// 5. Register services
builder.Services.AddSingleton(stripeOptions);
builder.Services.AddSingleton<StripeService>();

That’s it.

Why this is the “right” solution

✅ No change to your existing design
✅ No use of IOptions required
✅ Compatible with Key Vault, test keys, and live keys
✅ Fail‑fast configuration validation
✅ Clean separation of concerns

Quick answers to likely follow‑up questions

❓ Do I need separate code for test vs live Stripe?
No. Just change the Key Vault secret values.
❓ Should PublishableKey really be in Key Vault?
Not strictly required, but strongly recommended to avoid environment mix‑ups.
❓ Will this work in Azure App Service?
Yes — via Managed Identity.
❓ Will this work locally?
Yes — via az login.

Move this out of appsettings.json:

"ConnectionStrings": {
  "SqlDBcontext": "Data Source=(localdb)\\MSSQLLocalDB;Initial Catalog=WebCashFlow;Integrated Security=True;Connect Timeout=30;Encrypt=True;Trust Server Certificate=False;Application Intent=ReadWrite;Multi Subnet Failover=False;Command Timeout=30"
}

…and into Azure Key Vault, without breaking your app

Step‑by‑step: Move SQL connection string to Azure Key Vault

Step 1: Add the connection string as a Key Vault secret

Go to:

• Azure Portal → Key Vault → Objects → Secrets → Generate/Import
• Name: ConnectionStrings--SqlDBcontext
• Value: YourConnectionString
• Click Create

Step 2: Remove it from appsettings.json

Update appsettings.json to remove the connection string completely.

Step 3: Ensure Key Vault is added early (same rule as before)

In Program.cs, make sure this appears before anything calls GetConnectionString(...):

var builder = WebApplication.CreateBuilder(args);

builder.Configuration.AddAzureKeyVault(
    new Uri("https://wcf-keyvault.v

(Already encountered this ordering rule with Syncfusion — it applies here too.)

Step 4: Leave your Program.cs configuration unchanged

Program.cs currently contains:

var sqlConnectionConfiguration = new SqlConnectionConfiguration(
    builder.Configuration.GetConnectionString("SqlDBcontext")

Leave this unchanged.

Step 5: Optional but recommended – validate at startup

Fail fast if the connection string is missing. Insert the following code before the var sqlConnectionConfiguration line.

var connectionString =
    builder.Configuration.GetConnectionString("SqlDBcontext");

if (string.IsNullOrWhiteSpace(connectionString))
{
    throw new InvalidOperationException(
        "SQL connection string 'SqlDBcontext' not found."
    );
}

var sqlConnectionConfiguration =
    new SqlConnectionConfiguration(connectionString);

This avoids:

• Silent failures
• Confusing SQL exceptions later

Step 6: Test locally

• Make sure you’re logged in
• az login
• Ensure your user has:
• Key Vault Secrets User role
• Run the app
• Confirm
• Data loads correctly

What happens later when you move to Azure SQL?

This setup already prepares you perfectly.

Today (local DB):

(localdb)\MSSQLLocalDB
Integrated Security=True

Future (Azure SQL):

Server=tcp:yourserver.database.windows.net;
Database=WebCashFlow;
Authentication=Active Directory Default;
Encrypt=True;

✅ You will just change the secret value in Key Vault
✅ No code changes
✅ No config file changes
✅ No redeployment required (unless you want)

Important note (future best practice)

When you switch to Azure SQL, do not use SQL passwords if you can avoid it.

Instead:

• Use Managed Identity
• Use

Authentication=Active Directory Default

• Grant the Managed Identity access to the database

At that point:

• The connection string still lives in Key Vault
• But it contains no password at all

Final result (after this step)

The current configuration in appsettings.json looks like this:

 
"Smtp": {
  "Host": "mail.chrisbell.co.uk",
  "Port": 587,
  "UseSsl": true,
  "FromName": "Website Contact",
  "FromEmail": "chris@chrisbell.co.uk",
  "Username": "UserName",
  "Password": "Password"
}

The following should go to Key Vault (sensitive)

• UserName
• Password

But these can safely be left in appsettings.json

• Host
• Port
• UseSSL
• FromName
• FromEmail

Move SMTP secrets to Azure Key Vault

Step 1: Add SMTP secrets to Azure Key Vault

• Azure Portal → Key Vault → Objects → Secrets → Create
• Secret 1 – SMTP Username
• Name: Smtp--Username
• Value: UserName
• Secret 2 – SMTP Password
• Name: Smtp--Password
• Value: Actual Password

Step 2: Remove sensitive fields from appsettings.json

Update appsettings.json to look like:

"Smtp": {
  "Host": "mail.chrisbell.co.uk",
  "Port": 587,
  "UseSsl": true,
  "FromName": "Website Contact",
  "FromEmail": "chris@chrisbell.co.uk"
}

Step 3: Ensure Key Vault is added early (already done)

In Program.cs, make sure this is before any services read SMTP config

builder.Configuration.AddAzureKeyVault(
    new Uri("https://wcf-keyvault.vault.azure.net/"),
    new DefaultAzureCredential());
``

Step 4: Bind SMTP settings normally (recommended pattern)

Create a settings class if you don’t already have one (save in Data/Models):

namespace WebCashFlowV2.Data.Models{

    public class SmtpOptions
    {
        public string Host { get; set; } = default!;
        public int Port { get; set; }
        public bool UseSsl { get; set; }
        public string FromName { get; set; } = default!;
        public string FromEmail { get; set; } = default!;
        public string Username { get; set; } = default!;
        public string Password { get; set; } = default!;
    }
}

Register it in Program.cs

builder.Services.Configure<SmtpOptions>(
    builder.Configuration.GetSection("Smtp"));

Why this works

ASP.NET Core merges configuration from:

• appsettings.json
• Azure Key Vault

So that

• Non‑sensitive values come from JSON
• Sensitive values come from Key Vault
• Your app code never needs to know the difference

Step 5: Validate at startup (fail fast)

This is optional but strongly recommended: In Program.cs insert:

var smtpOptions = builder.Configuration.GetSection("Smtp").Get<SmtpOptions>();

if (string.IsNullOrWhiteSpace(smtpOptions?.Username) ||
    string.IsNullOrWhiteSpace(smtpOptions.Password))
{
    throw new InvalidOperationException("SMTP credentials are missing.");
}

•  Catches misconfigurations immediately
• Avoids silent email failures

Step 6: Test locally

• Make sure you’re logged in:
• az login
• Ensure your user has:
• Key Vault Secrets User role
• Run the app
• Send a test email

If it sends → success

If it fails → check secret names or ordering

What happens in Azure (no code changes)

• DefaultAzureCredential switches to Managed Identity
• Username & password come from Key Vault
• JSON stays secret‑free
• Same code, same behaviour

Final result (clean & secure)

What we’re going to do (high level)

1. Store the Syncfusion licence key as a secret in Azure Key Vault
2. Make ASP.NET Core read it automatically via AddAzureKeyVault
3. Remove the licence key from appsettings.json
4. Register the Syncfusion licence at app startup

Step 1: Add the Syncfusion licence key to Azure Key Vault

In azure Portal Select

• Key Vault → Objects → Secrets → Generate/Import
• Name: Syncfusion--LicenseKey Important naming convention: use double dash(--)
• Value: Your Syncfusion License Key
• Leave all other options as default
• Click Create

Why the --?

ASP.NET Core maps:

Syncfusion--LicenseKey

to:

Syncfusion:LicenseKey

This allows clean strongly-typed access later.

Step 2: Ensure Key Vault is already wired up (you’ve done this)

We should already have this in Program.cs:

builder.Configuration.AddAzureKeyVault(
    new Uri("https://wcf-keyvault.vault.azure.net/"),
    new Default

No more needed here. This means that:

• Local → az login
• Azure → Managed Identity

Step 3: Remove the licence key from appsettings.json

If present, remove this line from appsettings.json

"SyncfusionLicenceKey": "Your Syncfusion License Key",

After removal, appsettings.json should not contain the licence key at all.

Step 4: Register the Syncfusion licence at startup

Syncfusion requires the licence to be registered before components are used.

Open Program.cs

• Near the top enter 
• using Syncfusion.Licensing;

After builder.Configuration is available (before builder.Build()), but crucially also after

builder.Configuration.AddAzureKeyVault(
    new Uri("https://wcf-keyvault.vault.azure.net/"),
    new DefaultAzureCredential());

Enter the follwoing:

var syncfusionLicenseKey = builder.Configuration["Syncfusion:LicenseKey"];

if (!string.IsNullOrWhiteSpace(syncfusionLicenseKey))
{
    SyncfusionLicenseProvider.RegisterLicense(syncfusionLicenseKey);
}
else
{
    throw new InvalidOperationException("Syncfusion license key not found.");
}

This will now read straight from Azure Key Vault.

Step 5: Test locally

• Make sure you’re logged in: az login
• Ensure your Entra ID user has:
• Key Vault Secrets User role (or equivalent)
• Run the app

If the licence key is valid:

• No Syncfusion watermark
• No licence errors

If something is wrong:

• You’ll get the explicit exception we added

Step 6: Deploy to Azure

When deployed:

• DefaultAzureCredential switches to Managed Identity
• Azure App Service / Function accesses Key Vault
• Same code, no changes
• No secrets in config

Final state (clean + secure)

I asked Microsoft Copilot to help me move some Azure Entra ID configuration from appsettings.json to Azure Key Vault. My exact question was:

In appsettings.json I have the following (with some values removed)

"AzureAd": {
   "Instance": "https://WebCashFlow.ciamlogin.com/",
   "Domain": "WebCashFlow.onmicrosoft.com",
   "TenantId": "tenantID",
   "ClientId": "clientID",
   "ClientSecret": "clientSecret",
   "CallbackPath": "/signin-oidc",
   "SignedOutCallbackPath": "/signout-callback-oidc",
   "SignedOutRedirectUri": "/",
   "RemoteSignOutPath": "/signout-oidc" // optional but good to include
 },

Firstly, which of the above can I safely keep in appsettings.json?

Secondly, can you give me a step by step guide to moving the other items to Azure Key Vault. (I use Visual Studio Insiders, if any part can be done from within VS.)?

This is answer I received. and the process I followed.

Part 1 – What can safely stay in appsettings.json?

Here is your configuration again, classified line by line:
"AzureAd": {
"Instance": "https://WebCashFlow.ciamlogin.com/",
"Domain": "WebCashFlow.onmicrosoft.com",
"TenantId": "tenantID",
"ClientId": "clientID",
"ClientSecret": "clientSecret",
"CallbackPath": "/signin-oidc",
"SignedOutCallbackPath": "/signout-callback-oidc",
"SignedOutRedirectUri": "/",
"RemoteSignOutPath": "/signout-oidc"
} 

SAFE to keep in appsettings.json:

These are identifiers or URLs, not secrets:

• Instance
• Domain
• TenantId
• ClientId
• CallbackPath
• SignedOutCallbackPath
• SignedOutRedirectUri
• RemoteSignOutPath 

These values are routinely visible in front end requests and metadata endpoints. Keep them exactly where they are.

MUST be moved to Azure Key Vault

• ClientSecret

Why?

• It is a credential
• Anyone who gets this can impersonate your app against Entra ID
• Treat it with the same care as a database password or Stripe secret key

Part 2 - Target end state

 At the end of this step:

Your app will still read Configuration["AzureAd:ClientSecret"], but Key Vault will supply it instead of a file.

Part 3 - Step by step: Move ClientSecret to Azure Key Vault

Step 1 – Create an Azure Key Vault

 Azure Portal (recommended for first time)

Before getting into the detail, I have a question. Having logged into the Azure portal, the first question is 'Which Directory'. These are the directories I appear to have:

It is not clear to me which directory I should use. The ones I can (probably) discount are:

• By switching to 'WebCashFlow' I can see that this directory contains the Entra ID users for my WebCashFlow project, so this could be possible.  However, when I tried to 'create a resource' in this directory I got a message that stated there was no Azure subscription for this directory - so could not create any resource.

• I faced the same problem after switching to 'BlazorCodeEntraTenant'. This looks to be another directory used for Entra ID testing, but had fewer users than WebCashFlow, so probably isn't the 'live' Entra ID directory for WebCashFlow users.

• Switching directory to 'CashFlowProject' required 2FA which I was unable to provide, so not that directory.

• Switching directory to 'CashFlowV1B2C' also required 2FA which I was unable to provide, so not that directory.

• It definitely isn't going to be the directory associated with my personal Outlook account, so by a matter of elimination, it must be the directory associated with 'blazorcode.uk'

I therefore assume I should use the 'blazorcode.uk' directory.

• Go to Azure Portal → Create a resource
• Search for Key Vault
• Create
• Select Subscription
• Select Resource Group (or add a new resource group)
• Name: wcf-keyvault (This is the name I ended up with, the screenshot shows my first attempt, with a different name.)
• Region: UK South
• Pricing tier: Standard
• Leave networking as default for now
• Create the vault

Step 2 – Add the Client Secret to Key Vault

I got as far as creating the Azure Key Vault, however when I tried to add a Secret I got the following error message “The operation is not allowed by RBAC. If role assignments were recently changed, please wait several minutes for role assignments to become effective. “

The answer to this problem was to give myself permission to add secrets.

• In the Key Vault:
• Select Access Control (IAM)
• Select + Add
• In the Roles tab
• Enter Key Vault Secrets Officer in the Search box
• A list should be displayed; highlight Key Vaults Secrets Officer and click Next
• On the Members tab
• Select + Select Members
• In the right-hand pane, highlight the member and click Select
• The right-hand pane will close and the member will be displayed in the main pane. Select Review + assign

Add the Client Secret to Key Vault

• In the Key Vault:
• Select Objects
• Select Secrets
• Click + Generate/Import
• Set
• Name: AzureAd--ClientSecret
• Value: your actual Entra ID client secret
• Create

Note the double dashes (--). This maps automatically to AzureAd:ClientSecret.

Step 3 – Allow your app (developer) to read the secret

For now we’ll use your own Azure identity so you can test locally.

• In Key Vault → Access control (IAM)
• Add role assignment:
• Role: Key Vault Secrets User
• Assign access to: User
• Member: your Azure login

Step 4 – Install required NuGet packages

In Visual Studio, add NuGet packages:

• Azure.Identity
• Azure.Extensions.AspNetCore.Configuration.Secrets

Step 5 – Wire Key Vault into Program.cs

Open Program.cs

At the top of the file insert:

using Azure.Identity;
using Azure.Extensions.AspNetCore.Configuration.Secrets;

Add, after var builder = WebApplication.CreateBuilder(args)

builder.Configuration.AddAzureKeyVault(
    new Uri("https://wcf-keyvault.vault.azure.net/"),
    new DefaultAzureCredential());

Note the Uri of the key vault name.

In theory, this does not break anything.

• If Key Vault is unreachable → app still loads
• If secret is found → it overrides file values

Step 6 – Remove ClientSecret from appsettings.json

Edit appsettings.json:

"AzureAd": {
  "Instance": "https://WebCashFlow.ciamlogin.com/",
  "Domain": "WebCashFlow.onmicrosoft.com",
  "TenantId": "tenantID",
  "ClientId": "clientID",
  "CallbackPath": "/signin-oidc",
  "SignedOutCallbackPath": "/signout-callback-oidc",
  "SignedOutRedirectUri": "/",
  "RemoteSignOutPath": "/signout-oidc"
}

• No code changes required elsewhere
• Configuration["AzureAd:ClientSecret"] still resolves

Step 7 – Test locally

• Sign in to Azure CLI: az login - What's this? See next section
• Run your Blazor Server app
• Attempt authentication

Expected result:

• Sign in works exactly as before
• No secrets on disk
• You can rotate the secret without redeploying

Azure CLI

These are the instructions for running the Azure CLI. Two commands have been suggested

• az login
• az account show

Option 1 (Recommended): Azure Cloud Shell in the Azure Portal

This is the easiest and safest option — nothing to install. (But I'm not sure it would work for the 'Sign into Azure CLI: az login' in the Test locally scenario above.)

• Steps
• Go to https://portal.azure.com
• Log in
• In the top right toolbar, click the Cloud Shell icon ">_"
• When prompted:
• Choose Bash
• Create storage if asked (you can accept defaults)
• Run the command: az account show

Option 2: Local machine (actually, this is needed to Test Locally)

If you prefer running commands locally.

Step 1 – Install Azure CLI (if not already installed)

• Windows:
• https://learn.microsoft.com/cli/azure/install-azure-cli-windows 
  

Step 2 – Open a terminal

• Windows
• PowerShell or Command Prompt

Step 3 – Log in

• az login
• This opens a browser window. Sign in with your Azure account.

Step 4 – Run the command

• az account show

What output you should look for

The command returns JSON like this:

{
  "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "name": "Pay-As-You-Go",
  "tenantId": "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy",
  "user": {
    "name": "you@yourdomain.com",
    "type": "user"
  }
}

The important fields:

Why run az login to test the application locally?

Short Answer: 

You need to run az login locally because DefaultAzureCredential needs some identity to authenticate as, and on your local machine that identity usually comes from the Azure CLI login.

Long Answer:

What DefaultAzureCredential actually does:

DefaultAzureCredential does not magically authenticate by itself.
Instead, it tries a chain of possible credential sources in a fixed order and uses the first one that works.

Simplified, the order looks like this:

1. Environment variables (e.g. AZURE_CLIENT_ID, AZURE_CLIENT_SECRET)
2. Managed Identity (only works inside Azure: App Service, VM, Function, etc.)
3. Visual Studio / Visual Studio Code login
4. Azure CLI (az login)
5. Azure PowerShell (Connect-AzAccount)

On a local development machine, steps 1 and 2 usually do not apply, so it eventually falls through to Azure CLI authentication.

This is why az login matters.

Why az login is required locally?
When you run:

builder.Configuration.AddAzureKeyVault(
    new Uri("https://wcf-keyvault.vault.azure.net/"),
    new DefaultAzureCredential());

 Your app asks: “Who am I, and what identity should I present to Key Vault?”

On your local machine:

• There is no Managed Identity
• There may be no environment variables
• But there can be an Azure CLI login

When you run

az login

You are:

• Authenticating your Entra ID user account
• Storing a token securely in the Azure CLI cache
• Making yourself available as an identity provider

DefaultAzureCredential then:

• Detects the Azure CLI token
• Uses your signed in Entra ID user to request access tokens
• Calls Key Vault as you

What identity is being used after az login?

Your own Entra ID user account, not the app’s client secret. This is important.

• That means:
• Your user must have at least:
• Key Vault Secrets User, or
• Key Vault Secrets Officer, or
• an equivalent access policy / RBAC role
• This access is separate from your app’s production identity

This is by design and is considered best practice.

Why this is good practice:

• Security:
• You do not store client secrets locally
• No secrets in appsettings.json
• No secrets checked in to source control
• Environment separation
• • Local → uses developer identity
• • Azure → uses Managed Identity
• • No code changes required between environments
• Same code everywhere

Your code never changes; only where the identity comes from does.

What happens in Azure (production)?

When you deploy to Azure (App Service, Function App, etc.):

• DefaultAzureCredential stops at: ✅ Managed Identity
• az login is not used
• Your Entra ID application does not need the ClientSecret
• Key Vault access is granted to the Managed Identity

So this: new DefaultAzure
✅ Works locally
✅ Works in Azure
✅ No conditionals
✅ No secrets in config

Common misunderstanding about the ClientSecret

You mentioned: “I added a secret for my Azure Entra ID ‘ClientSecret'"

That secret is not being used locally if you are relying on az login.

It would only be used if:

• You explicitly configured ClientSecretCredential, or
• You set:
• AZURE_CLIENT_ID
• AZURE_TENANT_ID 

 Most modern ASP.NET guidance recommends not using client secrets at all if Managed Identity is available.

Summary

Why do I need az login locally?

• Because:
• DefaultAzureCredential needs an identity
• Locally, the simplest identity source is the Azure CLI
• az login provides that identity securely
• Your user account is used to access Key Vault
• This mirrors how Managed Identity works in Azure

My Conclusion

It's complicated - but it appears to work!

This process assumes that the 'Admin' role has already been created.

• Log into the Azure Portal
• Change directory to the one containing the Entra External ID
• Select 'Microsoft Entra ID' from Azure Services
• Or enter 'Entra' in the search bar
• Select 'Enterprise applications'
• Select the application from the list displayed in the body of the screen
• Select 'Manage > Users & Groups' from the menu
• Click 'Add user/group' (No need to select user at this stage)
• Click 'None Selected' (in this case)
• This will open a pane to the right. Tick the users you want to assign to the role. Click 'Select' at the foot of the pane.
• In my case only 'Admin' was available as a role and was selected automatically.
• Click 'Assign'

To remove Admin rights from a User

• Log into the Azure Portal
• Change directory to the one containing the Entra External ID
• Select 'Microsoft Entra ID' from Azure Services
• Or enter 'Entra' in the search bar
• Select 'Enterprise applications'
• Select the application from the list displayed in the body of the screen
• Select 'Manage > Users & Groups' from the menu
• Tick the user you wish to remove Admin rights from - make sure you select the user with Admin 'Role assigned'.
• Click 'Remove assignment' on the toolbar.
•