Securing .Net 10 WebApi to be called by Windows Application

Once again, thank you for everyone's help and input. So if I understand the OAuth workflow a little better, the main idea is to use a JWT already authenticated, then the api accepts the JWT, contacts the issuer and validates this request. So this is primarily used for third party authentication if I understand correctly. Btu what if the api is a standalone for one specific app. Wouldn't I just generate a hard coded symmetric key then validate it?

Hi @Kmcnet ,

To build on the great points made by AgaveJoe and Bruce:

The calling application doesn't change the API design. Your Web API shouldn't care if a Windows App, mobile app, or website is calling it. The API's only job is to check for an Authorization: Bearer <token> header, validate the JWT mathematically, and approve or deny the request.

The complexity lies entirely in your Windows App, which is responsible for coordinating the login (using the appropriate OAuth public client flow) and passing the resulting JWT token in the HTTP requests.

Bruce mentioned OAuth/OIDC are already generic protocols, your API can validate tokens from any standard Identity Provider (like Auth0, Keycloak, or a custom OpenIddict server). You don't have to use the Microsoft-specific wrappers. You can use the standard Microsoft.AspNetCore.Authentication.JwtBearer package in .NET 10.

Here is a minimal example in .NET 10:

Web API (Program.cs)

using Microsoft.AspNetCore.Authentication.JwtBearer;
using Microsoft.IdentityModel.Tokens;
using System.Text;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        // Example symmetric key validation (never hardcode in production!)
        var key = Encoding.UTF8.GetBytes("SuperSecretSuperLongSymmetricKey!");

        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidateAudience = true,
            ValidateLifetime = true,
            ValidateIssuerSigningKey = true,
            ValidIssuer = "YourIssuer",
            ValidAudience = "YourWindowsApp",
            IssuerSigningKey = new SymmetricSecurityKey(key)
        };
    });

builder.Services.AddAuthorization();
var app = builder.Build();

app.UseAuthentication(); // Must be BEFORE UseAuthorization
app.UseAuthorization();

app.MapGet("/secure-endpoint", () => "Authorized!").RequireAuthorization();

app.Run();

Windows Application Client

using System.Net.Http.Headers;

string jwtToken = await DoLoginFlowAndGetToken(); // Your custom auth flow logic

using var client = new HttpClient();
// Attach the token 
client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", jwtToken);
var response = await client.GetAsync("https://api.yourdomain.com/secure-endpoint");

if(response.IsSuccessStatusCode)
{
    Console.WriteLine("Success!");
}

This way, your API is completely agnostic to which OIDC provider or client is used, as long as the JWT is valid.

Hope this helps. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guidance or provide feedback.

Thank you. 

Thank you for the response. This is very helpful. A few questions if I may. How is the SuperSecretSuperLongSymmetricKey! generated? And how is the token generated in DoLoginFlowAndGetToken.

Securing the encryption key is the most import aspect of an authentication library. You need a secure storage option.

The DoLoginFlowAndGetToken is the code you write to get the access token is retrieved from the oauth login server that shared by the client and webapi server. You have two types of credentials

• The windows client can securely store a clientid and secret, and request an application access token. The application must be registered with its claims on the server. This is pretty simple web request.
• If you need to know the user, then you host a webview or use browser to login in fetch a token. This is pretty complex code, and you should pick a library.

Generating the Key If you are putting together a custom solution and testing with a hardcoded symmetric key, the key is simply a random string of bytes. You can generate a strong secure key in C# like this:

using System.Security.Cryptography;

// Generates a secure random 256-bit (32 byte) key
byte[] keyBytes = RandomNumberGenerator.GetBytes(32);
string base64Key = Convert.ToBase64String(keyBytes); 

In a real environment, you would store this base64Key string securely, such as in Azure Key Vault or environment variables, instead of checking it into source code.

Note: In production environments with third-party providers (Entra ID, Auth0, etc.), Asymmetric Keys are mostly used. The Identity Server holds a Private Key (used to sign) and the Web API dynamically fetches the Public Key (used to verify).

Generating the Token (DoLoginFlowAndGetToken) In standard setups, DoLoginFlowAndGetToken() doesn't actually generate the token locally at all. It will open a browser window to your Identity Provider. The user types their username and password, the Identity Provider authenticates them, generates the token, and hands it back to your app.

However, if you want to manually create your own tokens locally for a custom scenario or testing, you can use the System.IdentityModel.Tokens.Jwt package:

using System.IdentityModel.Tokens.Jwt;
using System.Security.Claims;
using System.Text;
using Microsoft.IdentityModel.Tokens;

static string GenerateJwtToken()
{
    // The exact same key your WebApi uses to validate
    var key = Encoding.UTF8.GetBytes("SuperSecretSuperLongSymmetricKey!");
    var securityKey = new SymmetricSecurityKey(key);
    var credentials = new SigningCredentials(securityKey, SecurityAlgorithms.HmacSha256);

    var claims = new[]
    {
        new Claim(JwtRegisteredClaimNames.Sub, "user123"),
        new Claim(JwtRegisteredClaimNames.Email, "user@example.com")
    };

    var tokenDescriptor = new SecurityTokenDescriptor
    {
        Subject = new ClaimsIdentity(claims),
        Expires = DateTime.UtcNow.AddHours(1),
        Issuer = "YourIssuer",
        Audience = "YourWindowsApp",
        SigningCredentials = credentials
    };

    var tokenHandler = new JwtSecurityTokenHandler();
    var token = tokenHandler.CreateToken(tokenDescriptor);
    return tokenHandler.WriteToken(token); 
}

If you plan to have actual users log in, I would second the advice to look into an out-of-the-box provider like Auth0, Entra, or a framework like OpenIddict instead of writing token-generation code manually.

Hi @Kmcnet , just checking in. Do you have any update on this post?