creating a TLS encrypted API

Question

I have an HTTP API endpoint on my server that is encrypted (TLS). It is not a public API; users must sign-in and validate their account/identity to access the API.

When I connect with my test client (using a newly generated keypair client-side each time), I get this response:

{[] [] [Domain Control Validated COMODO SSL Wildcard] [] [] [] []  *.blah.com [{Domain Control Validated} {COMODO SSL Wildcard} {*.blah.com}]}
2015/05/26 10:53:34 client: handshake:  true
2015/05/26 10:53:34 client: mutual:  true

Everything looks good.

Now, each user of my API must have a public/private keypair kept clientside to use to connect to the API to comply with the TLS protocol. This is all good and well as I understand it.

Users are going to send sensitive data and files through the wire to be stored on my server.

My next step is to authenticate the users and ensure their data is safe in transit. Which should I use?

• HTTP basic auth
• OAUTH
• OAUTH2

I read over https://www.owasp.org/index.php/REST_Security_Cheat_Sheet but it is mostly about securing a public API from attack. The part about securing the data itself is a footnote at the end.

Answer 1

As for the title of your question: your communication channel is encrypted by TLS. That part is OK.

The body of the question is actually about authentication. You have a few options, the main ones being:

• reuse the client certificates your users already have (due to the way you set up encryption by requesting both client and server certificates). Depending on the specific case you are it it could be enough for authentication (or not: you have a one factor authentication solely based on the possession of the certificates).
• use a password-based system, HTTP Basic Auth is an example
• use oAuth, which can allow you to offload authentication on another party (Google, Twitter, LinekedIn, ...). The added value is that you do not need to worry about managing the authentication lifecycle (account creation, password management), the other party may also have a robust system (multifactor) in place. The con is that you do not own authentication, you have to trust someone else to do a good job.
• put in place multi-factor authentication (HOTP) implemented for instance via Open OTP (the mechanism used by Google Authenticator, Authy, ...)