Machine-to-Machine (M2M) Authentication
Overview
Lightcast MCP uses OAuth 2.0 Client Credentials (Machine-to-Machine) authentication to secure access to the MCP server.
This authentication flow is designed for server-to-server communication and is recommended for AI agents, backend services, automation workflows, and enterprise integrations.
Every request to the Lightcast MCP Server must include a valid OAuth access token.
Authorization: Bearer <access_token>The access token identifies your application and authorizes access to the Lightcast MCP server.
Authentication Flow
Authenticating with Lightcast MCP consists of two steps:
Request an OAuth access token using your application credentials.
Include the access token when sending requests to the MCP server.
flowchart TD
A["Your Application<br/>(Python, LangChain, etc.)"]
B["OAuth Token Endpoint<br/>(Auth0)"]
C["OAuth Access Token<br/>(JWT)"]
D["Lightcast MCP Server"]
E["MCP Tool Execution"]
A -->|"Client ID<br/>Client Secret"| B
B -->|"Validate Credentials"| C
C -->|"Authorization: Bearer <access_token>"| D
D --> E
Credentials Provided by Lightcast
During onboarding, Lightcast provisions a dedicated Machine-to-Machine application for your organization.
| Credential | Description |
|---|---|
| Client ID | Public identifier for your application. |
| Client Secret | Confidential credential used to authenticate your application. |
| OAuth Domain | OAuth token endpoint. |
| Audience | Identifier of the Lightcast MCP API. |
| MCP Endpoint | URL of your hosted Lightcast MCP server. |
Treat your Client Secret as confidential. Never expose it in source code, client-side applications, or version control.
Obtaining an Access Token
Before connecting the MCP Server, your application must exchange its Client ID and Client Secret for an OAuth access token.
To request an access token, you'll need the following credentials provided during onboarding:
- Client ID
- Client Secret
- OAuth Domain
- Audience
After successful authentication, the authorization server returns a JWT access token.
Call the MCP Server
Include the access token in the Authorization header of every request.
POST /mcp
Authorization: Bearer <access_token>
Content-Type: application/jsonOnce authenticated, your application can discover and invoke the MCP tools available to your subscription.
Token Lifecycle
Access tokens are short-lived and should be cached and reused until they expire. When a token expires, request a new access token using the Client Credentials flow.
| Property | Value |
|---|---|
| Token Type | JWT Bearer Token |
| Token Lifetime | 1 Hour |
| Refresh Token | Not Used |
| Renewal Strategy | Request a new access token |
Applications should cache access tokens locally and request a new token only after the current token expires
flowchart TD
A[Application Starts] --> B[Request Access Token]
B --> C[Cache Access Token]
C --> D[Call MCP Server]
D --> E{Token Expired?}
E -->|No| F[Continue]
E -->|Yes| G[Request New Token]
G --> F
Security Best Practices
- Store credentials in a secure secret manager or environment variables.
- Never expose your Client Secret.
- Always use HTTPS.
- Cache access tokens until they expire.
- Rotate credentials if compromise is suspected.
Frequently Asked Questions
01/Why do access tokens expire?
Short-lived tokens reduce security risk.
02/Do I receive a Refresh Token?
No. Request a new access token when the current token expires.
03/Should I request a new token before every request?
No. Cache and reuse the token until it expires.
04/What happens if my token expires
Request a new access token and retry the MCP request.
05/Can multiple applications share the same credentials?
Lightcast recommends dedicated credentials per application whenever possible.
Updated 3 months ago

