TL;DR
An API token is a credential that an application sends with an API request to prove identity or permission. The server validates the token before granting access. Tokens may be short-lived, scoped to specific actions, and revocable, making them more suitable than permanent credentials for user-specific access.
Most APIs receive tokens through the HTTP Authorization header. However, not every token is a JSON Web Token (JWT): some are structured and signed, while others are opaque strings whose meaning is stored only on the server.
Understanding API Tokens
An API token is a machine-readable credential used to control access to an application programming interface. It is usually a string issued after a user, application, or service successfully authenticates.
When a client sends the token to an API, the server uses it to answer questions such as:
- Who or what is making this request?
- Is the token still valid?
- Which resources may the requester access?
- Which actions may the requester perform?
For example, a video application might issue a token that allows one user to enter room 4582 as a participant for the next hour. The same token should not automatically permit that user to enter every room, change account settings, or access administrative APIs.
How Token-Based Authentication Works
API token authentication follows a request-and-validation flow:
- The user or application first proves its identity, such as by signing in.
- An authorization server or application backend issues a token.
- The client stores the token temporarily and sends it with an API request.
- The API verifies the token's signature or looks up the opaque token.
- The API checks expiration, audience, issuer, and permissions where applicable.
- The server approves or rejects the requested operation.
A typical authenticated HTTP request looks like this:
GET /v1/rooms/4582
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...The Bearer scheme means possession of the token is enough to use it. Anyone who steals it may be able to act as the token holder until it expires or is revoked. Applications should therefore use HTTPS, avoid logging tokens, keep lifetimes short, and store tokens more carefully than ordinary application data.
What an API Token Contains
People often describe an API token as having a header, payload, and signature. That anatomy specifically applies to structured tokens such as JWTs.
A JWT uses three Base64URL-encoded segments separated by periods:
header.payload.signatureOpaque access tokens do not expose this structure. They may look like random strings, with the corresponding identity and permissions stored on the authorization server.
Token Header
A JWT header identifies how the token is represented and signed. It commonly declares a token type and cryptographic algorithm:
{
"typ": "JWT",
"alg": "RS256"
}This token header is different from the HTTP Authorization header. The JWT header is part of the token itself; the authorization header is the request field used to transport it.
Servers must enforce an approved algorithm rather than blindly accepting whichever algorithm the token declares.
Token Payload
The payload contains claims: statements about the token and its subject. Common registered claims include:
sub: The user or service represented by the tokeniss: The system that issued itaud: The API intended to accept itexp: The expiration timeiat: The issuance time
Applications can add claims for roles, room IDs, or permissions. These claims help the API make authorization decisions without retrieving a full session record for every request.
A JWT payload is encoded, not encrypted by default. Developers should not place passwords, private keys, or unnecessary personal information inside it because anyone holding the token can usually decode the payload.
Token Signature
The signature lets the recipient detect unauthorized changes to a signed token. The issuer signs the encoded header and payload with a secret or private key. The API validates that signature using the expected key before trusting any claims.
A signature does not conceal token contents, prevent theft, or guarantee that the token should still be accepted. The server must also validate expiration, issuer, audience, and relevant permissions. The JWT standard, RFC 7519, defines the core format and claims.
API Tokens Compared with API Keys
API keys and API tokens can both appear in HTTP headers, but they generally identify different things.
An API key commonly identifies the calling project, developer account, or integration. An API token more often represents a specific user, application session, or delegated set of permissions.
Their exact meaning depends on the provider, so developers should verify the API's documentation rather than relying on the credential's name.
When an API Key Is Appropriate
An API key is usually:
- Long-lived until manually rotated or revoked
- Associated with a project or application
- Simpler to issue and validate
- Used for metering, quotas, and application identification
- Less suitable as proof of an individual user's identity
Because an API key may unlock broad project access, it should not be embedded in public client code when the provider treats it as secret. Browser bundles and mobile applications can be inspected.
When an API Token Is Appropriate
An API token is usually better when access must be:
- Associated with a user, service, or session
- Limited to specific resources or actions
- Automatically expired
- Revoked or refreshed independently
- Issued after a verified authentication event
For example, an RTC application can give a participant temporary permission to join one room without revealing the application's server-side signing secret. This sharply reduces the impact of an exposed client credential.
Common API Token Types
The two most familiar categories are JWTs and tokens issued through OAuth authorization flows.
These categories can overlap: an OAuth access token may be a JWT, but it may also be an opaque string. JWT describes a token format; OAuth describes an authorization framework.
JSON Web Tokens
A JSON Web Token is a compact, URL-safe format that carries claims in a signed structure. Because the token is self-contained, an API can often validate it locally instead of querying a central session database on every request.
JWT implementations should use short expiration periods, strict algorithm validation, key rotation, and narrow claims. Developers should also avoid placing JWTs in URLs, which can leak through browser history, analytics, proxy logs, and referrer headers.
OAuth Access Tokens
OAuth tokens support delegated authorization. They allow a user to grant an application limited access to a service without giving that application the user's password.
An OAuth access token represents the authorization granted to a client. It may include scopes such as reading a profile or creating a meeting, and it normally expires. A refresh token may let an approved client obtain a new access token without asking the user to sign in again.
OAuth is not merely a token format. The OAuth 2.0 security best practices explain current safeguards for authorization deployments.
How to Build an App Like This with Tencent RTC
In a custom calling or conferencing application, token authentication should protect the control plane while Tencent RTC Engine handles the real-time media plane. Tencent RTC Engine provides cross-platform audio and video transport, publishing, subscription, weak-network resilience, and operational monitoring.
A practical architecture uses four components:
- The client signs in to your application and receives your normal API access token.
- The client calls a protected backend endpoint with that token.
- The backend verifies the user, room membership, and role, then generates a short-lived Tencent RTC
userSigusing the server-held secret key. - The client uses the returned values to enter the room and publish or subscribe to media.
Never generate userSig with the secret key in browser or mobile client code. Your API token and Tencent RTC userSig also serve different trust boundaries: the first protects your backend; the second authorizes room access to Tencent RTC.
The browser can request a room credential through an authorization header:
const session = await fetch("/api/rtc/session", {
method: "POST",
headers: {
"Content-Type": "application/json",
"Authorization": `Bearer ${appAccessToken}`
},
body: JSON.stringify({ roomId: 4582 })
}).then((response) => {
if (!response.ok) throw new Error("RTC authorization failed");
return response.json();
});After the backend returns sdkAppId, userId, userSig, and the approved roomId, use trtc-sdk-v5 to enter and publish:
import TRTC from "trtc-sdk-v5";
const trtc = TRTC.create();
trtc.on(TRTC.EVENT.REMOTE_VIDEO_AVAILABLE, ({ userId, streamType }) => {
trtc.startRemoteVideo({
userId,
streamType,
view: `remote-${userId}`
});
});
await trtc.enterRoom({
sdkAppId: session.sdkAppId,
userId: session.userId,
userSig: session.userSig,
roomId: session.roomId
});
await trtc.startLocalAudio();
await trtc.startLocalVideo({ view: "local-video" });Follow the Tencent RTC Engine integration overview when selecting the Web, iOS, Android, Flutter, or native SDK. In production, issue short-lived credentials, authorize every requested room server-side, reject mismatched user IDs, and refresh credentials without exposing signing secrets.
FAQ
Is an API token the same as an access token?
An access token is a type of API token specifically issued to authorize access to protected resources. “API token” is the broader term.
Where should an API token be sent?
Most APIs expect it in the HTTP Authorization header using Bearer <token>. Follow the API provider's specification and avoid placing tokens in URLs.
Can an API token replace a password?
It can replace sending a password with each API request, but the user or application still needs a secure initial authentication method. Tokens must also be protected against theft, expiration failures, and excessive permissions.