Shared-key authenticity
A message authentication code takes a secret key and message and produces a tag. A verifier with the same key can detect unauthorized message changes and confirm that some holder of that shared key created the tag. HMAC is a standard MAC construction built from a cryptographic hash function.
A MAC does not provide confidentiality. Every verifier that holds the shared key can also create a valid tag, so it cannot identify which member of the key-sharing group produced a message.
Message and context
Authenticate an unambiguous byte representation. Bind the tag to its purpose, protocol version, sender or key identifier, recipient or audience, algorithm, timestamp or sequence, and other context required to prevent cross-protocol reuse. Authenticate any unencrypted metadata that changes how the receiver interprets the protected data.
Define replay behavior separately. A valid tag on an old request remains valid unless the protocol checks expiry, nonce, sequence, transaction identifier, or stored replay state.
Key and verification
Generate a dedicated MAC key with a cryptographically secure mechanism. Do not reuse an encryption key or one MAC key across unrelated protocols. Limit which services can read or invoke the key and rotate it through a versioned verification process.
Verify the complete expected tag with a constant-time library operation before acting on the message. Reject unknown algorithms and key identifiers. Do not let the message select an arbitrary verification key or remote key source.
Failure and residual risk
Sharing one key across many services expands forgery authority and makes attribution weak. A valid MAC does not authorize the requested action or prove that the data is current. Ambiguous serialization can authenticate bytes that two components interpret differently. Truncation reduces forgery strength. Logging a MAC key breaks every message protected by it.
Pomerium boundary
Pomerium identity assertions use documented public-key signatures, not a shared MAC that every upstream can forge. Applications should verify the documented assertion rather than invent a hash or shared-secret header. When an application uses MACs for its own messages, it owns key scope, serialization, context, replay, rotation, and authorization.
Evaluation checklist
- Does the use require shared-key authenticity rather than confidentiality or public verification?
- Which services can create a tag, and is that forgery group acceptably small?
- Are purpose, version, audience, algorithm, and replay context authenticated?
- Is the message representation unambiguous across every producer and consumer?
- Is the key dedicated, generated securely, narrowly accessible, and rotatable?
- Does verification occur before side effects with a constant-time library operation?
