Support us .Net Basics C# SQL ASP.NET Aarvi MVC Slides C# Programs Subscribe Download

ASP.NET Core secret manager

Suggested Videos
Part 107 - ExternalLoginCallback action in core | Text | Slides
Part 108 - Register application with facebook | Text | Slides
Part 109 - ASP.NET Core facebook authentication | Text | Slides

In this video we will discuss what is Secret Manager and why we use it in ASP.NET Core

The main use of Secret Manager is to keep production secrets like database connection strings, API and encryption keys out of source control. 

Why you should not store secrets in configuration files

We usually store database connection strings, third party service credentials, API and encryption keys in configuration files like web.config in class and appSettings.json in core.

These configuration files are part of the project. So when they are committed to the source control repository, everyone who has access to the repository will have access to the sensitive data in these files and could be misused.

From security standpoint, it is not a good idea, to store passwords or other sensitive data in configuration files or source code.

Use of Secret Manager

Secret Manager allows developers to store and retrieve sensitive data during the development of an ASP.NET Core application. It stores sensitive data i.e user secrets in a file with name secrets.json.

To add this file to your project, right click on the project name in Solution Explorer in Visual Studio and select Manage User Secrets from the context menu. This adds secrets.json file. 

The structure of this file is similar to appSettings.json. The important point to keep in mind is, this file is not part of the project folder. It is located outside of the project folder at the following path.

  • {UserName} is the windows user name that you use to log into the computer.
  • {ID} is a GUID (Globally Unique Identifier)
On a single computer you may have multiple core projects and a secrets.json file for each project. It is this GUID, that links a given secrets.json file to a given core project. To establish this link, UserSecretsId node is included in the .csproj file.


A given secrets.json file can be shared by multiple projects

Using Secret Manager to store database connection string

From best practices standpoint, we do not want to store database connecting strings anymore in appSettings.json file. So, move the following database connection string from appSettings.json file to secrets.json file.

  "ConnectionStrings": {

Access secrets from Secrets.json file

In ASP.NET Core application configuration settings can come from different configuration sources like
  1. appsettings.json
  2. User secrets
  3. Environment variables
  4. Command-line arguments
We discussed appSettings.json file in Part 9 and Environment variables in Part 14 of ASP.NET Core tutorial.

Out of the box, IConfiguration service is setup to read configuration information from all the various configuration sources in core. For example, to read the database connection string from secrets.json file, inject and use IConfiguration service.

public class Startup
    private IConfiguration _config;

    public Startup(IConfiguration config)
        _config = config;

    public void ConfigureServices(IServiceCollection services)
        services.AddDbContextPool<AppDbContext>(options =>

        // Rest of the code

Please note that, if you have a configuration setting with the same key in multiple configuration sources, the later configuration sources override the earlier configuration sources 

CreateDefaultBuilder() method of the WebHost class which is automatically invoked when the application starts, reads the configuration sources in a specific order. To see the order in which the configuration sources are read, please check out ConfigureAppConfiguration() method on the following link

User secrets in production

To protect sensitive data, secrets.json file is deliberately kept outside of the project folder. This file is not checked into source control repository. This means secrets.json file is not copied onto the production server, when we actually build and deploy. So, where will the application find database connection string.

Well, on a production server store the database connection string in an environment variable. If you remember, IConfiguration service is setup to read configuration information from all the following configuration sources.
  • appsettings.json
  • User secrets
  • Environment variables
  • Command-line argument
This means, in spite of not having secrets.json file on the production server, our application should work just fine because it will find the required database connection string in the environment variable.

Secret Manager isn't for staging or production server, it should only be used on development machine. For production always use either environment variables, Azure Key Vault, or 3rd party production secret management system. core tutorial for beginners

No comments:

Post a Comment

It would be great if you can help share these free resources