> ## Documentation Index
> Fetch the complete documentation index at: https://docs.livingsecurity.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Authentication

> Choose an API key or OAuth client credentials for your integration, and understand how each uses a service account.

**You do not need OAuth to use the Public API.** For a private, server-side
integration, start with a scoped API key and follow the
[quickstart](/developers/v1/quickstart). Choose OAuth client credentials when
your security policy requires short-lived access tokens or your integration
platform already supports that flow.

Both options use a service account. A service account is the integration's
identity, not a third authentication method.

## How the pieces fit together

| Item | Purpose | What your integration sends |
| - | - | - |
| **Service account** | Names the workload and defines its permission ceiling. | Its ID identifies the account; it does not authenticate a request. |
| **API key** | Authenticates directly as that service account, with a chosen permission set and expiration. | The key secret using HTTP Basic authentication or `Authorization: Bearer <api_key_secret>`. |
| **OAuth client** | Authenticates to a token service to obtain scoped access tokens for that service account. | An access token using `Authorization: Bearer <access_token>`. |

Create one [service account](/developers/developer-hub/service-accounts) per
integration. Choose an API key or an OAuth client for that account; you do not
need both methods on each API request. Neither credential can exceed the
account's current permissions.

The quickstart uses Basic authentication. A Bearer header is also supported for
API keys; using that header does not mean you need an OAuth client.

## Choose an API key for a straightforward integration

Use an API key for your own scheduled jobs, reporting scripts, data pipelines,
or other backend services when a secret stored in your secret manager fits
your security requirements.

* Make authenticated requests directly; no token exchange is required.
* Select only the permissions the workload needs and set an expiration.
* Rotate the key using its overlap window, or revoke it immediately if exposed.

An API-key integration does not need an OAuth client. Start with the
[quickstart](/developers/v1/quickstart), then see
[API keys](/developers/developer-hub/api-keys) for creation and rotation.

## Choose OAuth for short-lived access tokens

Use OAuth client credentials for a confidential backend service when your
organization requires expiring access tokens or an integration tool expects
the `client_credentials` grant.

1. Create a scoped OAuth client for the service account.
2. Authenticate the client to your regional token endpoint using the client
   authentication method supplied during setup.
3. Send the resulting access token with your API requests. Obtain a new token
   before the current token expires.

OAuth adds token acquisition and expiry handling to your integration. The
client secret still needs secure storage and rotation; short-lived tokens do
not eliminate that responsibility. Client credentials does not use refresh
tokens: authenticate the client again to obtain a new access token.

OAuth access must be enabled for your organization. If it is not enabled,
use an API key or contact Living Security Support about your requirements.
See [OAuth client credentials](/developers/v1/oauth) for client creation,
one-time secrets, revocation and recovery.

## Keep credentials on your backend

Service-account API keys and OAuth client secrets belong in server-side
secret storage. Do not put them in browser code, mobile apps, source control
or logs. A service-account credential acts as the workload; it does not sign
in a person or provide a customer-consent flow.

Use the [regional API host](/developers/v1/regions) for your organization with
either method. Changing authentication methods does not change the resource
URL, API version or the permissions an operation requires.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.