I'm working on an API that is intended to be consumed by another system. The data is not owned by the requesting machine and the user(s) that the data pertains to are not driving the transaction. You could think of it as the same use-case as a hospital web service that transfers sensitive data and the people that own the data are not involved in the transaction. Or a banking web service that is used to perform analytical queries against lots of user data but the users in the data are not driving the transaction.
I'm researching authentication & Authorization options for this use case but nearly every document I come across for securing APIs jumps to OAuth 2 and sometimes OpenID Connect. I don't think either are applicable, if I read the RFCs correctly. They seem to center around delegating authentication to a 3rd party with the assumption that a user will then authenticate.
Solution I'm Considering
I've been considering an HMAC token in the Authorization header of the request in which the request details are encoded and signed with a key the client app was given once. Same flow as AWS's authentication scheme for their apis. The only thing I can think of more secure than this is exchanging public encryption keys and having the client encrypt the request with my public key and having me encrypt the response with theirs (PGP/RSA Encryption). Either option would be over TLS with certificate verification. Am I re-inventing the wheel here? Is there a comparable standard of rules to follow for this use case?
Side-note about Encryption over SSL
I've heard it remarked once that encryption over SSL was redundant. I just watched Moxie Marlinspike tear apart SSL at Defcon through a man in the middle and certificate chain spoofing. There is definitely a big difference between the certificate exchange process included in SSL that happens on every session and the one that only takes place once for what I outlined above.