API Authentication

API authentication verifies the identity of a client or user before protected resources are accessed. A backend typically checks credentials such as API keys, tokens, or signed credentials before allowing an operation.

Authentication answers “who are you?” Authorization answers “what are you allowed to do?” An API commonly performs authentication first and then uses the authenticated identity to make authorization decisions.

Common mechanisms include API keys, bearer tokens, and session or identity tokens. An API key is usually a secret identifier presented with a request, while a bearer token grants access to whoever possesses it. Token-based systems can carry identity and other claims, depending on the token format and validation rules.

Credentials should be sent over HTTPS so they are protected in transit. Servers should validate credentials on protected endpoints, reject missing or invalid credentials, and avoid exposing secrets in URLs, logs, or error messages.

For a Python backend, authentication is often implemented by middleware or framework dependencies that extract a credential, validate it, and provide the resulting identity to the request handler. Authentication alone does not determine whether that identity may perform a particular action; that is the authorization layer.

Key points

• Authentication verifies identity; authorization determines permitted actions.
• Common API credentials include API keys and bearer tokens.
• Use HTTPS to protect credentials while they are transmitted.
• Validate credentials before executing protected operations.
• Do not place secrets in URLs or accidentally expose them through logs.

Interview questions

What is API authentication, and why is it needed?

API authentication verifies that a request comes from a recognized client or user. The server checks a credential such as an API key or token before exposing protected functionality. Without authentication, an endpoint intended for trusted callers could accept requests from anyone. Authentication should be combined with authorization when different identities have different permissions.

What is the difference between a 401 and a 403 response?

A 401 response indicates that the request has not successfully authenticated, such as when credentials are missing or invalid. A 403 response indicates that the server understood the identity or request context but refuses the requested operation because access is not permitted. The exact behavior can depend on the API's design, but this distinction is the standard HTTP semantics developers should know. Authentication failures and authorization failures should therefore be handled separately.

How would you protect an API key in a Python backend?

I would transmit the key only over HTTPS and avoid placing it in query parameters. The server-side secret would come from a secure configuration or secret-management system rather than source control. I would restrict access to the key, rotate it when appropriate, and prevent it from appearing in application logs. I would also validate the key before performing the protected operation.

What is a bearer token, and what is the security implication of stealing one?

A bearer token is a credential where possession is generally sufficient to present the token as proof of access. The server validates the token according to the authentication scheme and then associates the request with an identity or set of claims. Because possession can be enough, anyone who obtains the token may be able to use it until it expires or is otherwise invalidated. HTTPS, short lifetimes where appropriate, careful storage, and controlled logging help reduce the impact of token theft.

Where should authentication logic live in a Python web application?

Authentication is often centralized in middleware, request dependencies, or another reusable boundary rather than duplicated inside every endpoint. That component can extract credentials, validate them, and expose an authenticated principal to downstream handlers. Endpoint-specific authorization can then use that principal to enforce resource or action permissions. Centralizing authentication reduces inconsistent checks while keeping authorization decisions close to the protected operation.