Overview
This repository is focused on one job: producing valid AWS Signature Version 4 authorization headers from HTTP request data in ASP.NET Core applications. It sits on top of Cuemon's HMAC authentication abstractions and adds the AWS-specific pieces that generic HMAC signing does not cover, such as credential scope composition, canonical request hashing, and multi-stage signing-key derivation.
The result is a narrow package surface that helps when your application needs to inspect, proxy, or generate outbound AWS requests with explicit control over how the final Authorization header is built. The package page for Codebelt.Extensions.AwsSignature4 covers the concrete APIs.
Concepts
The concepts in this repository all serve one signing flow: turn an ASP.NET Core request into the exact canonical data that AWS expects, then combine that data with AWS scope fields to produce a deterministic authorization header.
Canonical request capture
AWS Signature Version 4 depends on more than a secret key. The request method, canonical URI, sorted query string, canonical headers, signed-header list, and payload hash all have to be normalized in a specific way before the signature can be calculated. In Codebelt.Extensions.AwsSignature4, Aws4HmacAuthorizationHeaderBuilder.AddFromRequest is the boundary where ordinary HttpRequest state becomes AWS signing input.
This is the non-obvious part of the repository's value. The package is not just formatting an Authorization header string. It captures the request shape that AWS will validate later, including canonicalized headers and a SHA-256 payload digest, so the signature is tied to the actual outbound request representation.
Credential scope as signing state
AWS signing uses a scoped key derivation process, not a single raw secret. The date, region, service, and termination string become part of both the credential scope and the derived signing key, which means they are part of the request identity rather than incidental metadata.
In Codebelt.Extensions.AwsSignature4, Aws4HmacAuthorizationHeaderBuilder.AddCredentialScope collects those values and stores the derived scope fields the later signature step needs. The companion date formatting extensions keep the request header values and the credential scope aligned so the timestamp that appears in the header is the same timestamp that shapes the signature.
Header generation with traceable intermediate state
The final authorization header is only trustworthy if the intermediate canonical request and string-to-sign are derived consistently. This repository exposes that flow through builder methods such as ComputeCanonicalRequest, ComputeSignature, and Build, which means the signing process can be inspected in stages instead of treated as an opaque one-shot helper.
That design matters when you need to debug mismatched signatures or compare locally generated headers with AWS examples. The same package also includes Aws4HmacAuthorizationHeader.Create, which parses a serialized header back into an authorization-header object so generated output can be compared or rehydrated after transport.
Usage guidance
Adopt this repository when your code needs explicit control over AWS Signature Version 4 header construction from ASP.NET Core request objects, especially when you want the canonical request and credential scope to stay visible in code instead of being hidden behind a higher-level client. It fits best in middleware, gateways, proxies, test fixtures, or service code that already has direct access to HttpRequest.
If your need stops at generic HMAC authorization semantics, or if another library already signs the outbound AWS request for you, this repository adds AWS-specific signing state that you do not need. In that case, use the lower-level Cuemon.AspNetCore.Authentication abstractions or the higher-level AWS client that already owns the signing step.