It seems the answer could be to use HMAC. Perhaps, others could expand on this?
A and B just need to share the HMAC key. Handling (and changing) this key can be tricky; if an attacker acquires it, the entire scheme falls over.
Depending on what the system is used for, how valuable breaking into it would be, and how long you expect it to be up, you might need to rotate the key every so often, by having A and B agree on a new key. This is a little more complicated; since B now needs to check C's HMACs against two keys (the original and the new one) until every message signed by the original key has expired.
Perhaps, I will provide an API method for automatically expiring an HMAC and fetching a new one. During this rollover period, messages sent using the old HMAC will be allowed to fail, since they can just come get a new copy from Alpha server.
Another option is to not do any wheel re-inventing at all. Have C go to A and ask it for an TLS client certificate. C can just open a good old TLS connection to B with the certificate (mutual authentication). The shared "secret" (not really a secret) would simply be A's certificate thumbprint. Furthermore, certificates have tons of features built right in: including the expiry date that you are looking for.