ASP.NET Core Data Protection API

ASP.NET Core Data Protection API

Last Updated on August 18, 2025 by Aram

In this article we will learn about the Data Protection API in ASP.NET Core.

This API is not considered something new; It has existed since the days of .NET Framework but it was mainly targeting Windows environments. Now with ASP.NET Core, this has become cross-platform and largely improved.

It provides a very simple abstraction to protect/unprotect small bits of information.

You can protect API keys, Tokens, and Cookies with a single line of code, without managing encryption keys yourself.

Keep reading this article to learn more Data Protection API, how does it work, its evolution timeline, use cases, limitations, and a practical tutorial that shows you how you can use it in ASP.NET Core

What is Data Protection API?

The Data Protection API (DPAPI) in .NET is a built-in service for encrypting and decrypting sensitive data, such as passwords, tokens, or connection strings, without having to write your own encryption logic.

It relieves you from dealing with complex encryption/signing algorithms and handling key management yourself.

Think of it as a secure locker built into .NET where you can store small pieces of sensitive information.

You give it data, it locks it with a strong encryption key.

Later, you can unlock it but only from the same environment (machine, user, or app context) unless you configure it to share keys.

You don’t have to manage encryption algorithms, key storage, or rotation.

It’s all handled for you.

How does Data Protection API work?

Understanding the internal structure of the Data Protection API will help you have a better knowledge of how it works, so here is a breakdown of the core components of the Data Protection API:

1. Data Protector

  • The main service you call to protect (encrypt) or unprotect (decrypt) data.
  • Created from IDataProtectionProvider.CreateProtector("purpose").
  • Purpose string ensures that only matching protectors can decrypt the data.
  • Uses AES-256-CBC + HMACSHA256 by default (can be customized).

2. Key Ring

  • A collection of encryption keys used to protect/unprotect data.
  • Each key has:
    • Unique ID (GUID).
    • Creation and activation dates.
    • Expiration date.
    • Encryption algorithm info.
  • Supports key rotation — old keys are kept for decryption, new keys for encryption.

3. Key Storage

  • Where the key ring lives.
  • Default in dev: ~/.aspnet/DataProtection-Keys or %LOCALAPPDATA%.
  • In production: can be on disk, Azure Blob Storage, Redis, SQL Server, or custom provider.
  • Keys can be encrypted at rest using:
    • Windows DPAPI.
    • X.509 certificates.
    • Azure Key Vault.
    • Custom encryption.

4. Key Management

  • Automatic:
    • New keys are generated periodically (default: every 90 days).
    • Old keys are retained until they expire.
  • Manual:
    • Can create, revoke, or set key lifetime through APIs.

5. Cryptographic Algorithms

  • Default: AES-256-CBC (encryption) + HMACSHA256 (validation).
  • Uses authenticated encryption (Encrypt-then-MAC).
  • Can plug in custom algorithms via AuthenticatedEncryptorConfiguration.

Timeline and Evolution of the Data Protection API

Here’s the timeline and evolution of Data Protection API in .NET, from its inception in the early Windows-only days to the modern cross-platform version we have now:

Windows DPAPI (OS level)

Started with Windows 2000 via the CryptProtectData / CryptUnprotectData API.

Protected Data in .NET

Added as the managed wrapper over DPAPI when .NET Framework 2.0 shipped (2005).

ASP.NET MachineKey (web apps, ViewState/cookies)

Part of classic ASP.NET from the early .NET/ASP.NET releases (ASP.NET 1.0 era, 2002), used for decrypting/encrypting cookies and ViewState before the newer stack.

ASP.NET Core Data Protection API

Introduced with the ASP.NET Core rework (ASP.NET Core became generally available with the platform around 2016).

The ASP.NET Core Data Protection system (Microsoft.AspNetCore.DataProtection) is the cross-platform replacement designed for automatic key management, key rings, and pluggable storage.

.NET 5 (The modern era)

.NET 5 was released Nov 10, 2020; since then Data Protection has continued to be maintained and extended (better hosting integration, key-store extensions, Azure Key Vault / Blob/Redis providers, SystemWeb compatibility bridge, etc.).

Use Cases of Data Protection API

Key use cases of Data protection API are:

– Encrypting config values
– Protecting temporary tokens
– Securing authentication cookies

There are currently some use cases where ASP.NET Core is already using these APIs under the hood.

And in some other cases, where you need custom data protection or hiding important keys in a manual way, you can simply create a protector from the provider.

Then, call the Protect method to encrypt your data, and decrypt it back to the original form via the Unprotect method.

Here is a breakdown for the use cases which are already using Data Protection API behind the scenes and other use cases where you can use them on-demand:

Used automatically by ASP.NET Core (under the hood)

You don’t call the API directly but it is already done behind the scenes.

Here are some use cases where the Data Protection API is being utilized without any problem

  • Authentication cookies (Identity, cookie authentication middleware)
  • Anti-forgery tokens (ValidateAntiForgeryToken attribute)
  • TempData (when using cookie-based provider)

Require Explicit Use of Protect/Unprotect Methods

Here, you call the API directly in your code in the below cases:

  • Custom sensitive data encryption (e.g., encrypting tokens, API keys, personal data before DB storage)
  • Protecting data for external integration (e.g., encrypt payloads shared between services)
  • Passing protected state in cookies or URLs
  • Manual migration from machineKey (only if bridging old ASP.NET data manually)

Limitations

Data Protection API is not meant to protect large strings or files. For these, you can use different security approaches.

Also, there are no async equivalents for Protect and Unprotect.

Here’s why:

  • The encryption and decryption process is done entirely in memory with already-loaded keys.
  • There’s no network call or heavy I/O happening during Protect and Unprotect method calls.
  • Key loading from storage happens once at startup (or on rotation), so by the time you call Protect, everything is ready in memory.
  • Async would just add overhead without performance benefits.

If you’re storing or retrieving large payloads or keys from a slow storage provider (e.g., database, Azure Blob), you’ll handle that async outside the Data Protection API, but the actual protect/unprotect call will still be synchronous.

How to use Data Protection API in ASP.NET Core

Project Creation

  1. Create a new project in VS 2022
  2. Select ASP.NET Core Web API, and then choose Next
  3. Put any name to the project and press next.
  4. Choose .NET 9 as the framework (or whatever you are currently using), and then press on Create.

Implementation

Create 3 new folders with names: Interfaces, Services, Controllers

Interface

Inside the Interfaces folder, add a new class with name IDataProtectionService

This should normally include a clone of the data protection API methods: Protect and Unprotect

Service

Now let’s implement the above interface in a new service class: DataProtectionApi

As you might have noticed, we are using C# 12 amazing feature of Primary Constructor to inject the IDataProtectionProvider.

Controller

The controller should expose 2 endpoints that will directly consume the DataProtectionApi Service methods, as the below:

Program.cs

This is about the glue to connects the different components together

So you program.cs file should look as the below:

Data Protection API Configuration Options

The most basic configuration with all default setting is to call .AddDataProtection directly.

But if you need to override some of these settings, then you can easy do that.

You have several options to control where keys are stored, how they’re protected, and how the system behaves.

Here are some of the most common use cases and how you can configure them in program.cs:

Persist Keys to a Specific Location

Most apps need this to survive restarts or work in a farm.

Encrypt Keys at Rest

Recommended so that if storage is compromised, keys are still protected.

Configure Key Lifetime

Controls how often new keys are generated, based on lifetime presented asTimeSpan

Testing on Postman

Now that everything has been added and setup correctly. We can easily switch to Postman and test the 2 new endpoints:

Protecting Data

Here we will call the /EncryptedData endpoint as POST to denote that we are creating a new resource as encrypted data:

Unprotecting Data

And in this endpoint we will be decrypting the protected data from the previous endpoint:

Final Thoughts

Data protection API is a powerful and easy way to protect your key data that are small in length. It abstracts away lots of complex operations of choosing the right algorithm and implementing it, also relieves you from having to manage the keys and rotating it.

All provided for you with simple methods and a completely straightforward provider that can be seamlessly injected into any service or controller thanks to the powerful built in DI of ASP.NET Core.

So try a POC with it and let us know your feedback and comments.

References

ASP.NET Core Data Protection Overview

How to: Use Data Protection

Data Protection API

Bonus

Enjoy this wonderful collection of masterpieces by Wolfgang Amadeus Mozart:

Classical Music for Brain Power – Mozart

Leave a Reply