7

We are currently busy improving an Android application with connects to an Azure App Service API using client certificates and bearer token for authentication over TLS 1.2.

We are investigating moving to HTTP/2 for bandwidth & performance requirements. HTTP/2 standard has no implementation for client certificate authentication.

We still want an extra layer next to the bearer token authentication. What are valid and secure options to explore to harden our API?

Adding a nonce is a possible solution to block malicious requests, but we would like to limit public access to our API.

  • How about using regular HTTPS for token management and switching to HTTP/2 for everything else? – Stephane Jun 13 '18 at 06:58
  • Azure App Service enables/disable client certification on the full API. This would mean having an App Service for token managment and a different App Service for the API. Not solving the issue of the API being exposed on the public internet without the need of anything, to explore or perform malicious requests. – Preben Huybrechts Jun 13 '18 at 07:03
  • Your API will need to perform authentication anyway. If you require a session token that can only be obtained through your token management interface (through HTTPS+TLS) then you do reach the same functional goal. It true, however, that a connection must reach your application before being rejected instead of being rejected at the connection level. This does increase your attack surface somewhat – Stephane Jun 13 '18 at 12:11

2 Answers2

2

Use a separate subdomain that requires a client certificate. It's only renegotiation that's not allowed, so if you ask for a client certificate at the beginning of an HTTP/2 TLS session it will still work.

0

We solved this by using Azure App Service IP restrictions. This was only possible because we control all the clients.