Common API authentication methods and when to use them

Application programming interfaces connect mobile apps, websites, internal systems and external platforms. Authentication is the process that identifies the application or user making a request, while authorisation determines what that identity is allowed to do. Choosing the right method affects security, performance, development time and the experience of customers using an API.

There is no single authentication approach that suits every integration. A private service used between two applications may work well with a signed API key, while a consumer-facing application generally needs OAuth 2.0 with carefully managed access tokens. The design should reflect the sensitivity of the data, the type of client and the possibility that credentials could be exposed.

Australian organisations also need to consider the Privacy Act, the Australian Privacy Principles and the Notifiable Data Breaches scheme when an API handles personal information. A weak login design can turn a minor coding error into an incident involving customer records, payment details or employee data.

The best choice is therefore practical as well as technical. A small Melbourne retailer may need a straightforward connection to a stock system, while a financial technology company serving customers in Sydney, Brisbane and regional areas may require delegated access, strong auditing and additional controls around every request.

API keys for simple application identification

An API key is a long string issued to a client application. The client sends it in a request header, commonly using a name such as X-API-Key, and the server checks whether the value is valid. Keys are easy to issue, revoke and associate with usage limits, which makes them useful for low-risk services and early-stage integrations.

This method works well for public data APIs, internal prototypes, server-to-server calls with limited permissions and services where the key identifies an application rather than an individual. For example, a business might issue separate keys to its warehouse dashboard and reporting tool so that usage can be measured independently.

API keys are not a complete security solution. Anyone who obtains a key may be able to use it, particularly if the server grants broad access. They should never be embedded in browser JavaScript, mobile app binaries or public repositories. TLS encryption is essential, and keys should be stored in a secrets manager, rotated periodically and restricted by endpoint, environment or network where possible.

Basic authentication and its narrow role

HTTP Basic Authentication sends a username and password with every request, encoded in Base64. Encoding is not encryption, so the method is unsafe without HTTPS. It can still be appropriate for a controlled administrative interface, a temporary test environment or a legacy system that operates behind a private network and additional security controls.

The simplicity of Basic Authentication is its main advantage. It is widely supported, quick to configure and easy to troubleshoot. A developer testing an API locally may use it before a production identity platform is ready. In a live environment, however, the same password may be reused across many requests, increasing the damage caused by theft.

Production systems should avoid transmitting permanent credentials where a short-lived token would work better. If Basic Authentication is unavoidable, use strong unique passwords, enforce rate limits, monitor failed attempts, disable unused accounts and require HTTPS from the first request. Australian businesses should also record enough authentication activity to investigate suspicious access without retaining unnecessary personal information.

Bearer tokens for stateless access

A bearer token grants access to whoever presents it. The server usually expects a value in the Authorization header, such as Authorization: Bearer token-value. Unlike a session that requires the server to remember each client, a well-designed token can support stateless API requests across multiple servers and cloud regions.

Bearer tokens are common in mobile applications, single-page web apps and service integrations. They are especially useful when an identity service issues a token after login and the API validates that token on subsequent calls. Access tokens should have limited lifetimes, narrow scopes and a clear revocation strategy. Refresh tokens, if used, need stronger protection because they can obtain new access tokens.

Token leakage remains a serious risk. Do not place tokens in URLs, browser history or ordinary log files. Use secure storage on mobile devices, protect cookies with HttpOnly and SameSite settings when suitable, and avoid sending credentials to third-party analytics tools. A company reviewing an external consumer platform should apply the same caution to permissions and data sharing; even an online entertainment service should receive only the access its integration genuinely needs.

OAuth 2.0 for delegated permissions

OAuth 2.0 allows a user to grant an application limited access without sharing their password with that application. It is commonly used when a customer signs into a service through an established identity provider or permits one application to read selected data from another.

The authorisation code flow with Proof Key for Code Exchange, or PKCE, is the preferred choice for native mobile applications and browser-based applications. PKCE helps prevent an intercepted authorisation code from being exchanged by an attacker. A confidential server-side application can also authenticate itself to the identity provider when exchanging the code.

OAuth 2.0 is valuable when several parties are involved: a customer, a client application, an authorisation server and a resource API. Scopes should express the smallest practical permissions, such as orders.read rather than unrestricted account access. Redirect URIs must be exact, state values should defend against request forgery, and refresh tokens should be rotated or otherwise monitored.

Australian organisations often use OAuth when connecting accounting, payroll, logistics and customer platforms. A retailer operating in Perth and Adelaide might allow an inventory provider to read product quantities but not customer addresses. Separating those permissions reduces exposure if one partner account is compromised and supports clearer consent records under Australian privacy expectations.

OpenID Connect for identity and sign-in

OpenID Connect, or OIDC, is an identity layer built on OAuth 2.0. OAuth answers the question of what an application may access, while OIDC adds a standard way to confirm who the user is. It supplies an ID token containing identity claims, issued by a trusted identity provider.

OIDC suits customer portals, employee applications and single sign-on across multiple systems. A university, government contractor or national retailer can use it to provide a consistent sign-in experience without creating separate passwords for every application. The API should still validate the token’s issuer, audience, signature, expiry and relevant claims rather than accepting any token that merely looks correctly formatted.

An ID token is intended for the client application, not usually as a general-purpose credential for calling APIs. API access should rely on an access token with the correct audience and scopes. This distinction prevents a common implementation mistake in which an application accepts an identity assertion where a resource authorisation token is required.

Multifactor authentication can be enforced by the identity provider, which is useful for privileged staff and sensitive operations. A Sydney-based business with remote employees may combine OIDC, hardware security keys and conditional access rules, while still offering an accessible recovery process for workers who travel between offices or have unreliable connectivity.

Mutual TLS for trusted machine connections

Mutual Transport Layer Security, or mTLS, authenticates both sides of a connection using digital certificates. Ordinary TLS proves the server’s identity to the client; mTLS also requires the client to present a certificate that the server trusts. This creates a strong machine-to-machine control at the network layer.

mTLS is suitable for banking, healthcare, government, telecommunications and high-value internal services. It can also protect connections between microservices where an API key alone would provide insufficient assurance. Certificates can be tied to a device, workload or organisation, and access can be denied before an application request reaches the API.

The operational cost is higher than with a simple token. Certificates must be issued, stored, renewed, revoked and monitored, and teams need a reliable public key infrastructure. Poor certificate management can cause outages when a credential expires during an Australian public holiday or when a regional site loses access to its certificate service.

For that reason, mTLS is most effective when the organisation already has mature infrastructure automation. It should be paired with application-level authorisation, because proving that a machine is trusted does not automatically mean it should access every endpoint or record.

HMAC signatures for request integrity

Hash-based Message Authentication Code, or HMAC, lets a client sign parts of a request using a shared secret. The server independently calculates the expected signature and compares the results. A typical signed request includes the HTTP method, path, timestamp, nonce and selected headers, helping the server detect tampering and replay attempts.

HMAC is useful for payment callbacks, webhooks, trading connections and partner APIs where both parties control backend systems. It can provide stronger assurance than sending a reusable key by itself because an attacker must also reproduce the correct signature for the exact request. Timestamps and one-time nonces should be checked to limit replay attacks.

The secret must remain private on both sides, so HMAC is unsuitable for untrusted browser or mobile clients. Teams also need precise documentation covering canonicalisation, character encoding, clock tolerance and error handling. Small differences in how a request is assembled can cause valid messages to fail authentication.

Australian merchants commonly depend on webhooks for orders, deliveries and payment updates, especially when integrating platforms across multiple states and time zones. A signed webhook, strict timestamp window and idempotency key can help prevent duplicate fulfilment or fraudulent status changes. Logs should capture the event identifier and verification result without exposing the shared secret.

Matching the method to the risk

The decision should begin with the client type. A server-controlled integration may use an API key, HMAC or mTLS, depending on the level of assurance required. A public mobile or browser application should not contain a permanent secret and will generally need OAuth 2.0 with PKCE. A service that needs reliable user identity should add OIDC rather than treating OAuth access as proof of identity.

Data sensitivity and business impact matter just as much. Public weather information may tolerate an API key with rate limiting, while health records, payroll data and financial transactions require stronger identity verification, narrow permissions, encryption and detailed audit trails. Combining methods is often sensible: mTLS can establish the trusted workload, while a short-lived access token determines which operation it may perform.

Controls around the authentication method are equally important. Apply least privilege, rotate credentials, restrict token audiences, validate every claim, monitor unusual locations and revoke compromised access quickly. Rate limiting and anomaly detection can reduce automated abuse, but they should account for Australian usage patterns such as mobile networks, changing IP addresses and customers connecting from regional areas.

A practical implementation should also consider availability. Identity providers, certificate services and key stores need backups, documented recovery procedures and clear ownership. Testing should cover expired credentials, clock drift, replayed requests, revoked users and partial outages. When authentication reflects the actual risk and operating environment, an API becomes easier to maintain and safer for the people and businesses that depend on it.