API -

Authentication

Principal is who or what that is being authenticated.

Communication protocol and authentication mechanism are different things. HTTPS encrypts everything except domain, subdomain and originating IP. But placing sensitive things in address or query strings is still bad because of logging. You should always use HTTPS when communicating over a public network. You can be a bit less strict when communicating non-sensitive data over a private network.

API authentication is usually handled with a SSO solution over HTTPS. Frequently something SAML or OpenID Connect (OAuth 2) based. In these, service redirects you to identity provider, you authenticate and the identity provider lets service provider know. In enterprises, identity provider is usually linked to a directory service like LDAP or AD that contain principal roles. If you can choose OpenID Connect is better than SAML, as it's simpler.

Other authentication schemes:

• Bearer Authentication (also called token authentication) is an HTTP authentication scheme that involves security tokens called bearer tokens. Also use only over HTTPS be it a private or public network.
• API Keys are widely used in the industry and became some sort of standard because of their simplicity, however, this method should not be considered a good security measure. API keys over HTTPS are easy, but you don't have a single standard way of doing it securely. Typically needs a separate service to manage and rotate the keys.
• HTTP Basic Authentication is rarely recommended due to its inherent security vulnerabilities. More or less OK if the network is secure and private. Basic over HTTPS is fine enough, but not over HTTP!

Use headers for any sensitive information. Please do not put any API keys or sensitive information in query string parameters as they get recorded in routing logs! A better option is to put the API key in the Authorization header.

Private network is sometimes good enough. If not handling highly sensitive data, trusting local network sources might be enough, but note that it won't help anything if somebody gains network access. Be vary of MitM attacks, so just understand the risks.

Service-to-Service API Authentication has a bit more possibilities:

• Client Certificates (X.509) are more secure, but certificate management is more tedious. Like trying to figure why seemingly valid certificate fails. Use only if communicating over untrusty network.
• HMAC over HTTP is where the request body and private key are hashed and sent along the request for validation. You can cache traffic, hard to MitM but easier to listen. Look at JWT.

Understand Confused Deputy Problem. This is the case where a service doing calls for malicious entity that shouldn't get those done. This is more prevalent when using a lot of microservices.

You could introduce a SSO gateway to make thing easier if you have a lot APIs. Avoids having SSO handshake logic on each endpoint. Maybe use a signed JWT with username, roles and URL to refresh? Or SAML-based Shibboleth.

Load balancer with SSL termination is fine enough for less sensitive data. Keep the network sealed after that and remember that the communication can be listened if somebody gets access.

Network segmentation is usually a good addition. Using different networks and subnets for different sets of services.

Encrypting data at rest is a good addition. Encrypting data at rest with AES-256 with the tools and libraries for your platform.