What Is a Bearer Token? API Access and Secret Handling

Scrapeless Web Unlocker uses a Scrapeless API key through its documented request authentication method, which is separate from a target service’s bearer credentials.

A Bearer Token Is a Possession-Based Credential

A bearer token is a credential that a party can use by presenting the token itself, without separately proving possession of a cryptographic key bound to that token. The OAuth bearer token usage standard defines this property for HTTP access to protected resources. Possession is therefore sensitive: someone who obtains a valid token may be able to exercise the access it conveys.

The word bearer does not mean unlimited access. The resource server still determines whether the token is valid for the requested resource, whether it has expired or been revoked, and whether the operation is allowed. A token can be constrained to a narrow scope and intended audience. Protecting the secret and enforcing those constraints are complementary controls, not interchangeable choices.

A familiar use is an API request whose Authorization field uses the Bearer scheme followed by the access credential. Follow the resource service’s exact contract for placement and validation. A token accepted by one service should not be assumed valid at another service, even if both belong to the same organization or both expose similar HTTP endpoints.

Bearer, OAuth, and JWT Describe Different Layers

Bearer describes how a credential is used, OAuth describes an authorization framework, and JWT describes a structured token format. These concepts often appear together but are not synonyms. OAuth can issue access tokens that are presented as bearer credentials, and those tokens can be opaque strings or structured values. The client should not infer an access token’s format from the fact that it came from OAuth.

A JWT carries claims in a defined representation, with security properties determined by the selected JOSE mechanism and validation rules. The JSON Web Token specification does not make every JWT an OAuth access token. An identity assertion, a short-lived application assertion, and an access credential can all require different validation even when their encodings look similar.

Decoding a token is not the same as validating it. Readable claims do not establish that the issuer is trusted, that the integrity protection is correct, or that the resource server is the intended audience. Never accept a token merely because its payload can be parsed as JSON. Token validation must follow the specific application profile and authorization server contract.

Issuance and Resource Access Are Separate Steps

Token issuance happens under an authorization system’s policy, while resource access happens when a service evaluates a request carrying the token. The OAuth token issuance framework defines roles and grants for obtaining access credentials. A provider can also use a separately documented issuance mechanism for its own credentials. The resource server’s acceptance policy must match whichever mechanism produced the credential.

An access token should go only to its intended resource service. A refresh token belongs at the authorization server’s token interface and should not be sent to ordinary business endpoints. A client secret authenticates a client in supported contexts and is not a substitute for the user’s resource access token. Keeping these values separate prevents a debugging session from turning into cross-service credential exposure.

The permission decision can also depend on the user or tenant represented by the token. A request for an object outside that scope must remain denied even when the credential itself is otherwise valid. Object-level authorization belongs on the server. The client’s ability to construct a URL or guess an object identifier is not proof that the caller may read that object.

Validate the Intended Issuer, Resource, and Permission

A resource server needs to establish the credential’s active status and relevance to the request. For a structured access token, this can involve checking integrity protection, trusted issuer, intended audience, validity time, and authorization claims. For an opaque token, the server can use its own lookup or a supported validation interface. Use the provider’s profile rather than assembling an incomplete generic checklist into a custom validator.

The OAuth token introspection mechanism defines a way for protected resource services to query information about a token, including whether it is active. Introspection is an authorized server interaction, not an invitation for arbitrary clients to send secrets to a public token-decoding website. Keep validation traffic within the trusted authorization architecture.

An active token still may not carry the permission required for a particular operation. Distinguish token validity from resource authorization in both code and diagnostics. A sanitized log can record the issuer identifier, route, status, and request correlation value without preserving the credential. That gives operators useful evidence while keeping log readers from inheriting access to protected APIs.

Protect Credentials Throughout Their Lifecycle

Bearer credentials need protection during transmission, storage, use, and disposal. Send them only over the intended secure connection and keep them out of URLs unless the service explicitly requires a protected connection parameter. URLs can appear in browser history, proxy logs, analytics, and shared screenshots. The fact that a credential is short-lived does not make careless disclosure harmless.

Keep secrets out of source repositories, example files, and ordinary application telemetry. A deployment secret store can inject a credential into the process that requires it. Limit who and what can read that value, and redact it before recording request diagnostics. An environment variable is a delivery mechanism, not a complete access-control or retention policy by itself.

Client-side applications require an explicit threat model because browser code cannot hold a permanent confidential secret from its user or from scripts running in that environment. A server component can reduce direct token exposure in some architectures, but it introduces its own session and request-protection requirements. Choose storage and session patterns from the application’s security design rather than treating one storage location as universally safe.

Interpret Rejected Credentials Without Guessing

A rejected authenticated request should be interpreted from the endpoint’s documented status and error fields. A missing or invalid credential differs from an accepted credential with insufficient scope. Keep those distinctions in the result state so an application does not present a permission denial as an empty collection. Check which service produced the response before deciding which credential needs attention.

Do not paste a live token into a support ticket to prove that it exists. Share sanitized request details and use the provider’s secure support process when investigation requires account access. If a credential is exposed, the owner should follow the issuer’s revocation or replacement procedure and review where the value was stored. Deleting one local copy does not remove copies retained in logs or shared artifacts.

Where possession-based access is insufficient for the threat model, sender-constrained mechanisms can add a proof requirement. OAuth DPoP binds supported token use to a cryptographic key and request proof. It is a distinct supported mechanism rather than an extra arbitrary header to attach to a normal bearer request. Both client and service must implement the corresponding contract.

Scrapeless Keys and Target Tokens Must Stay Separate

The Scrapeless API key requirements specify the authentication method for each product. Web Unlocker REST requests use the raw key in the documented x-api-token field rather than a guessed Bearer scheme. A key passed through a browser connection parameter is also a secret and needs redaction when a connection URL is logged or shared.

The API authentication concepts help distinguish these schemes, while Scrapeless pricing concerns service usage. A valid account credential, an enabled product, sufficient balance, and permission to access a target resource are separate conditions. Diagnose them separately rather than treating every failure as a malformed bearer string.

Build a Credential Inventory for the Workflow

A credential inventory should identify each secret’s issuer, intended receiver, permitted operations, storage location, and owner. Include expiry or revocation behavior where the provider defines it. Avoid copying raw values into the inventory; describe identifiers and secret-store references instead. The goal is to make the permission boundary visible without creating another store of sensitive material.

For a hypothetical reporting tool, one credential might authorize the tool’s own data-service account while another represents a user-approved resource grant. Those values need different audiences and disposal rules. Testing should confirm that the wrong credential is rejected and that logs remain sanitized. A clear inventory makes that separation easier to preserve as more providers are added to the workflow.

Conclusion

A bearer token is powerful because possession is enough to present its access. Keep the issuer, intended receiver, permission scope, and storage boundary explicit, and validate credentials using the service’s actual token contract. Separate target access tokens from platform API keys so one integration does not expose authority intended for another.