Glossary · 2 · Developer SDKs and APIs
Access token
Also known as: OAuth access token, OAuth 2.0 access token, Bearer token, access_token
German: Zugriffstoken
In software engineering, an access token is a credential issued by an authorization server that lets a client application call a protected resource on behalf of a resource owner or on its own behalf. In OAuth 2.0 it is a string denoting a specific scope, lifetime and other access attributes, which the client presents to the resource server instead of the resource owner's password. Most deployments issue short-lived bearer tokens, which any party holding the token can use, so the token has to be protected in storage and in transit; a separate refresh token may be used to obtain a new access token when the old one expires. Access tokens are the credential type that developer SDKs for HTTP and cloud APIs usually acquire, cache and renew on the caller's behalf.
- OAuth
- Authorization
- API security
- Developer SDK
- Credentials
In one sentence
Access token: short-lived credential from an authorization server that lets an SDK or client call a protected API within a granted scope.
Example
The SDK's client object exchanges a client ID and secret for an access token, caches it until the expires_in value elapses, and attaches it to every REST call in the Authorization: Bearer header.
How it applies
- Developer SDKs (APIs and cloud services). Client libraries for HTTP and cloud APIs typically wrap the whole token lifecycle: they run a grant flow against the authorization server, hold the access token in memory, attach it to each request and request a new one before or after expiry. Document which grant types the SDK supports, where the token is stored and whether renewal is automatic, because that determines what the calling application has to implement itself. See also authorization and authentication.
- Scopes in reference documentation. An access token carries a scope, a lifetime and further access attributes, so every API operation page should name the scope or permission the token must carry. Mapping operations to scopes is part of the interface contract and belongs in generated reference output, not only in a security chapter.
- Transport rules. RFC 6750 defines bearer token usage in HTTP requests; any party in possession of a bearer token can use it to reach the associated resources without proving possession of a key, which is why the specification requires protection in storage and in transport. Current IETF security guidance (RFC 9700, Best Current Practice for OAuth 2.0 Security) recommends restricting token privileges to the minimum needed and using sender-constraining mechanisms such as mutual TLS or DPoP against stolen or leaked tokens.
- Token formats. The core framework does not prescribe a format. RFC 9068 defines a profile for issuing access tokens as JSON Web Tokens so that authorization servers and resource servers from different vendors can issue and consume them interoperably; such tokens are self-contained JSON structures with registered claims. Resource servers that cannot validate a token locally may use an introspection endpoint instead.
- Platform SDKs. Host applications that expose extension points often hand the extension a token scoped to the current user and the current document or tenant rather than full application credentials, so an extension's manifest and its granted scopes should be documented together.
- Hardware and edge SDKs. Devices and gateways that report to a cloud backend act as OAuth clients without a user present; they obtain tokens through a client-credentials-style or device-oriented flow, which constrains clock accuracy, secure storage and the retry behavior described in device documentation.
- Diagnostics. Expiry, clock skew and missing scopes surface as 401 or 403 responses. Troubleshooting sections benefit from a table of error responses, and logging rules must forbid writing token values into logs or traces. Using OAuth 2.0 or naming these RFCs does not by itself make an integration secure or compliant; it only defines the mechanism.
Access token vs. refresh token
An access token is presented to the resource server and is normally short-lived and scope-limited. A refresh token is presented only to the authorization server to obtain a new access token without involving the resource owner again, and RFC 6749 already requires that refresh tokens issued to confidential clients be usable only by the client they were issued for. IETF security guidance recommends that refresh tokens be sender-constrained or rotated. Neither should be confused with an OpenID Connect ID token, which conveys authentication information about the end user to the client and is not intended as an API credential.