Implementing OAuth 2.0 client credentials in C# with IdentityModel

When backend services need to talk to one another without any human in the loop, the OAuth 2.0 client credentials grant is usually the right tool. A console job running on a Sydney-based .NET host can request its own access token, attach it to outgoing HTTP requests, and call a protected API in Melbourne, all without storing a username and password. For C# developers, the IdentityModel library from Duende and the wider .NET community has become the de facto helper for this pattern because it removes the boilerplate around token endpoints, request signing, and JSON parsing.

This article walks through the moving parts of that flow, starting with the basics of how a client credentials grant actually exchanges a client id and secret for a bearer token. It then moves into concrete C# code, including request construction, response parsing, refresh logic, and a few notes on integrating with Australian identity providers such as Microsoft Entra ID, Auth0 regional tenants, and the platforms that sit behind services like the ATO developer portal and Consumer Data Right declarations.

Understanding the client credentials flow for machine-to-machine auth

The client credentials grant is the simplest of the OAuth 2.0 grant types. There is no user, no browser redirect, and no authorisation code. A confidential client, typically a backend service running unattended in a data centre, an Azure region in Sydney, or an on-premises box in a Brisbane office, sends its client id and client secret directly to the token endpoint of an authorisation server. If the credentials are valid and the requested scope is allowed, the server returns an access token, often a signed JWT, that the client then presents as a bearer credential on subsequent calls to a resource server.

What makes this grant attractive to Australian engineering teams is its predictability. There is no consent screen to localise, no PKCE dance to worry about, and no token rotation tied to user sessions. The trade-off is that every service that holds a client secret becomes a high-value target. The Australian Cyber Security Centre's Essential Eight maturity model treats credential management as a first-class control, so storing client secrets in Azure Key Vault, AWS Secrets Manager, or HashiCorp Vault and rotating them on a schedule is more than a nice-to-have. It is the difference between passing an IRAP assessment and being told to come back next quarter.

A subtle point worth keeping in mind: the client credentials flow only works for trusted, server-side callers. You would never embed a client secret in a mobile app, a single-page application, or an Angular bundle served from a CDN in Perth. If your architecture includes such a client, you will need to add an authorisation code flow with PKCE in front of it and keep the client credentials grant reserved for internal service-to-service hops.

Setting up your C# project with IdentityModel packages

IdentityModel is published as a set of NuGet packages under the IdentityModel namespace, and the pieces you actually need for the client credentials grant are small. The workhorse is IdentityModel.Client.HttpClient, which extends HttpClient with RequestClientCredentialsTokenAsync and a strongly typed TokenResponse model. Add it through the Package Manager console or by editing the .csproj directly:

dotnet add package IdentityModel
dotnet add package IdentityModel.Client

For ASP.NET Core projects that want to combine the token client with the Microsoft stack, you will also pull in Microsoft.Extensions.DependencyInjection and Microsoft.Extensions.Http so the token client can be registered in DI and injected wherever it is needed. If your services run on .NET 8 or later, the new IHttpClientFactory patterns slot in cleanly. Older code bases still on .NET Framework 4.7.2, common in Australian banks and government agencies that have not finished their migration off legacy systems, can keep using the synchronous TokenClient class, which has been part of the library for years.

Configuration is typically loaded from appsettings.json, environment variables, or a key vault. A reasonable shape for the configuration object looks like this:

public class OAuthSettings
{
    public string Authority { get; set; }
    public string ClientId { get; set; }
    public string ClientSecret { get; set; }
    public string Scope { get; set; }
}

Bind this section in Program.cs with builder.Configuration.GetSection("OAuth") and resolve it through IOptions<OAuthSettings>. Keeping the authority URL as a single setting is helpful when you have separate environments, for example a dev tenant hosted out of Sydney, a UAT tenant in Singapore, and a production tenant in the Azure Australia East region.

Acquiring access tokens with the ClientCredentialsTokenRequest

Once the configuration is in place, requesting a token is mostly a matter of wiring up an HTTP client and calling the right method. A minimal implementation looks like this:

public async Task<TokenResponse> GetTokenAsync(IHttpClientFactory factory)
{
    var client = factory.CreateClient("identity");
    var disco = await client.GetDiscoveryDocumentAsync(_settings.Authority);
    if (disco.IsError) throw new Exception(disco.Error);

    var response = await client.RequestClientCredentialsTokenAsync(new ClientCredentialsTokenRequest
    {
        Address = disco.TokenEndpoint,
        ClientId = _settings.ClientId,
        ClientSecret = _settings.ClientSecret,
        Scope = _settings.Scope
    });

    if (response.IsError) throw new Exception(response.Error);
    return response;
}

The GetDiscoveryDocumentAsync call is worth explaining. IdentityModel follows the OpenID Connect discovery convention and pulls the token endpoint URL from the authority's .well-known/openid-configuration document. This means you do not hard-code https://login.microsoftonline.com/.../oauth2/v2.0/token and risk breaking when Microsoft renames an endpoint, which it has done more than once. For an Australian Entra ID tenant, the discovery URL typically looks like https://login.microsoftonline.com/<tenant-id>/v2.0.

After the token is in hand, attach it to outgoing calls by setting the Authorization header:

request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", token.AccessToken);

A useful pattern when you are calling multiple downstream APIs from the same host is to wrap each downstream call in a DelegatingHandler that fetches and caches the token automatically. This keeps the bearer token out of business logic and makes it trivial to swap providers, for instance when a service that originally talked to an in-house identity provider starts consuming APIs exposed through the Consumer Data Right registry.

Caching tokens and handling token lifetime in production

Tokens issued under the client credentials grant usually have a lifetime between five minutes and one hour. Asking for a fresh token on every HTTP call would burn CPU on the authorisation server, inflate your logs, and potentially trigger rate limiting on shared tenants, a real concern when you are running against the same Entra ID instance as the rest of the Australian public service. Caching is not optional. It is the only sensible way to run the flow in production.

The simplest cache is an in-memory IMemoryCache entry keyed by the requested scope. On token acquisition, store the access token along with its expires_in value and a small safety margin, say sixty seconds shaved off the end so you never hand out an expired token. When the entry expires, the next call triggers a fresh request. For multi-instance deployments, swap the in-memory cache for a distributed one such as Redis or the SQL-backed DistributedCache you might already have running on a managed instance in Sydney.

Two edge cases deserve attention. First, clock skew: if your service runs on a host whose clock drifts more than a minute or two behind your identity provider, you may receive a token that is already considered expired. Synchronise with time.windows.com or, better, an Australian NTP source such as time.csiro.au. Second, refresh storms: when a cached token expires under load, dozens of worker threads may race to renew it. Guard the renewal with a SemaphoreSlim or a per-scope lock so only one thread issues the actual HTTP request and the others wait for the result.

Comparing token client libraries for C# developers

IdentityModel is not the only way to grab client credentials tokens in C#. Depending on your stack, you might reach for a different library.

For most teams in Australia who are calling Entra ID, Auth0, or an on-premises IdentityServer, IdentityModel.Client plus a small caching layer is the sweet spot. It is dependency-light, easy to mock in tests, and does not lock you into a Microsoft-only identity story, a real plus if your integration roadmap includes the Consumer Data Right or cross-jurisdictional APIs.

Practical recommendations for a stable deployment

A few habits separate a client credentials integration that runs quietly for years from one that wakes someone up at 3 a.m.

• Keep client secrets in Azure Key Vault or an equivalent secrets manager and load them at startup through IConfiguration so they never appear in source control or container images.
• Treat the token endpoint like any other downstream dependency: instrument it with structured logging, trace it with OpenTelemetry, and alert on non-2xx responses with a meaningful threshold rather than a single failure.
• Rotate client secrets on a documented schedule, ninety days is a common baseline in Australian government, and rehearse the rotation in a non-production tenant so production cutovers are boring.
• Pin the version of IdentityModel in your .csproj and review release notes before upgrading; minor versions occasionally tighten validation rules that can surface latent issues in your token handling.
• Write at least one integration test that exercises the real token endpoint against a sandbox tenant, because mocked token responses tend to drift away from the actual server behaviour faster than anyone expects.