Glossary · 2 · Developer SDKs and APIs

OAuth 2.0

Also known as: OAuth2, OAuth 2.0 Authorization Framework, RFC 6749

In software engineering, OAuth 2.0 is an authorization framework, specified in IETF RFC 6749 (October 2012), that lets an application obtain limited access to a protected resource on behalf of a resource owner without ever handling that owner's password. RFC 6749 defines four roles — resource owner, client, authorization server and resource server — and a set of grant types through which a client obtains an access token whose permissions are bounded by requested scopes. OAuth 2.0 decides what a client may do, not who the end user is; identity assertions are added by the separate OpenID Connect layer built on top of it. Most cloud and developer SDKs wrap these flows in a credential or token-provider class so that application code never assembles the token requests by hand.

OAuth
API security
Authorization
Developer SDK
IETF

In one sentence

OAuth 2.0 (RFC 6749) is the IETF framework for delegated authorization: roles, grant types, scopes and access tokens behind most cloud SDKs.

Example

A cloud storage SDK is configured with a service-account client ID and secret, uses the client credentials grant to obtain an access token limited to a read-only storage scope, and attaches that token as a bearer credential to every REST request until it expires.

How it applies

Developer SDKs. Cloud and platform SDKs are the main place technical writers and developers meet OAuth 2.0. The SDK usually hides the token endpoint behind a credential object: the caller supplies a client ID, a secret or a key file, and a list of scopes, and the library fetches, caches and refreshes the access token before each call to a REST API. Document which grant type the SDK uses per credential type, because that determines what the operator must configure in the identity provider.
Scopes belong in the reference documentation. Every SDK method that calls a protected endpoint should name the scope or permission it requires. Scope strings are provider-defined; they are part of the interface contract between client and resource server even though RFC 6749 leaves their vocabulary open.
Grant type per client type. RFC 6749 distinguishes confidential clients (able to keep a secret, e.g. server-side code) from public clients (single-page apps, mobile apps, CLI tools). Server-to-server integrations typically use the client credentials grant; user-facing apps use the authorization code grant, extended with PKCE (RFC 7636) for public clients. IETF RFC 9700, the OAuth 2.0 Security Best Current Practice published in 2025, advises against the implicit grant and the resource owner password credentials grant; where an SDK still offers them, say so plainly in the documentation.
Hardware SDKs and input-constrained devices. Devices without a browser or keyboard — set-top boxes, printers, headsets, industrial panels — commonly use the device authorization grant (RFC 8628), where the user completes the approval on a phone or laptop while the device polls the token endpoint. Documentation for embedded software should cover the user code display, the polling interval and what happens when a refresh token is revoked in the field.
Platform SDKs. Host applications that let third-party extensions reach cloud services usually broker tokens for the extension rather than letting it store user credentials. Note in the extension guide which scopes the host requests, which it forwards, and how consent is revoked.
Publishing SDKs and content pipelines. Build agents that pull content or push output through a service API also need tokens. Prefer short-lived tokens from a non-interactive grant over long-lived static keys, and keep secrets out of the repository and out of build logs.
Code generation and clients. Generated clients from an interface definition often contain only a placeholder security scheme; the actual token acquisition is supplied by hand or by a shared library. When you describe automatic code generation, state where the security configuration is injected.
Operations. Access tokens expire, refresh tokens can be revoked, and clock skew or a rotated client secret produces 401 responses that look like application bugs. Token lifetime, refresh behavior and retry guidance belong in the troubleshooting section, and token identifiers should be treated as secrets in observability data.
Status note. RFC 6749, together with the bearer token usage specification RFC 6750, remains the published standard. "OAuth 2.1" consolidates RFC 6749 and current security practice but is, as of 2026-09-30, an IETF Internet-Draft (draft-ietf-oauth-v2-1) and remains a draft until published as an RFC; it should be cited as such.
Implementing OAuth 2.0 or naming RFC 6749 in a manual does not by itself make a system secure or compliant with any regulation; it is one building block whose security depends on configuration, token handling and the wider deployment.

OAuth 2.0 vs. OpenID Connect

OAuth 2.0 is about delegated authorization: the access token tells the resource server that some client may perform certain operations, and the token is deliberately opaque to the client. OpenID Connect Core 1.0, published by the OpenID Foundation, adds an identity layer on top of OAuth 2.0: the authorization server also issues an ID token — a signed JSON Web Token with claims about the end user — so the client can perform authentication and learn who signed in. Using an access token as proof of identity is a recurring design error; if your SDK documentation says "login with OAuth," check whether the flow actually returns an ID token and whether the client validates it.

In one sentence

Example

How it applies

OAuth 2.0 vs. OpenID Connect

External references