OAuth

OAuth is an open authorization standard that allows an application to obtain limited access to data or functionality provided by another service. Access may be granted on behalf of a user or without a user when two systems communicate directly.

OAuth can allow an application to read selected account data, publish content, synchronize a calendar, or manage a specific part of an external platform. The user does not need to give the application their password. Instead, the application receives a token representing the access it has been granted.

OAuth is commonly used to connect websites, mobile applications, CRM systems, e-commerce platforms, and SaaS products with an external API.

Is OAuth used for login?

OAuth is an authorization standard, not a user authentication protocol. It primarily answers the question: “Which resources may this application access?” OAuth alone does not define a standard way to verify a person’s identity.

Features described as “Sign in with Google,” “Sign in with Microsoft,” or “Sign in with Apple” commonly use OpenID Connect. OpenID Connect is an authentication layer built on OAuth 2.0. It enables an application to verify a user’s identity and receive information about the authentication event.

Using an OAuth access token alone as proof of a user’s identity can create security vulnerabilities. If an application requires login functionality, it should use OpenID Connect or another protocol designed for authentication.

An example of how OAuth works

Suppose a user wants to connect a social media scheduling application to their account. The application needs permission to read selected profile information and publish posts, but it should not receive the user’s password.

The process may work as follows:

1. the user selects an option to connect their account;
2. the application redirects the user to the social media service;
3. the service authenticates the user if they are not already signed in;
4. the service presents the access requested by the application;
5. the user approves or rejects the request;
6. the application receives an authorization code;
7. the code is exchanged for an access token;
8. the application uses the token when making API requests.

The password remains with the service that manages the user’s account. The application receives only the permissions represented by the issued token.

The main roles in OAuth

The OAuth 2.0 model defines four primary roles:

• resource owner – the entity capable of granting access to a protected resource, often the user;
• client – the application requesting access to the resource;
• authorization server – the system that manages authorization and issues tokens;
• resource server – the API that hosts protected data or operations.

The authorization server and resource server may be parts of the same platform or separate services.

What is an OAuth client?

An OAuth client is an application that uses a protected API. It may be a website, mobile application, desktop program, single-page application, device, server-side script, or another system.

The client is generally registered with the OAuth provider. During registration, it receives a client_id. A confidential client may also receive credentials used to authenticate the application.

OAuth distinguishes between two main types of clients:

• confidential client – can protect its credentials because it runs in a controlled server environment;
• public client – cannot securely protect a secret because its code is available on a user’s device or in a browser.

A mobile application or browser-based JavaScript application should not contain a permanent client_secret. Anyone with access to the application package or website code could extract it, so it would not provide meaningful client authentication.

What is an access token?

An access token is a credential used by an application to call a protected API. It tells the resource server that the client has been granted particular permissions.

An access token may have:

• a limited lifetime;
• a defined set of permissions;
• an intended audience;
• an association with a particular user or application;
• a restriction to a specific API or resource.

An access token does not have to be a JWT. It may be an opaque random string whose meaning is known only to the authorization server. It may also be a structured token containing signed information.

Many implementations use bearer tokens. This means that the party possessing the token can use it. If such a token is stolen, an attacker may be able to access the protected resources until the token expires or is revoked.

What is a refresh token?

A refresh token allows a client to obtain a new access token without repeating the complete authorization process. It can maintain access over a longer period even when an access token is valid for only a few minutes or hours.

A refresh token is generally more sensitive than a short-lived access token. It should be securely stored, sent only to the authorization server, and protected against disclosure.

An authorization server may use refresh token rotation. Each successful use returns a new refresh token and invalidates the previous one. Reuse of an older token may indicate that it has been compromised.

Not every application needs to receive a refresh token. The decision depends on the client type, requested access, security risk, and provider policy.

Authorization codes, access tokens, and ID tokens

OAuth and OpenID Connect use several credentials for different purposes:

• authorization code – a short-lived, usually single-use code returned after authorization; the application exchanges it directly with the authorization server;
• access token – used to call a protected API;
• refresh token – used to obtain a new access token;
• ID token – used by OpenID Connect to communicate information about user authentication.

An ID token should not be sent to an API in place of an access token. Similarly, an access token should not automatically be treated as proof of a user’s identity.

What are OAuth scopes?

A scope describes the access requested by an application. Instead of exposing an entire account, a provider can define separate permissions for reading data, modifying records, sending messages, or performing other actions.

Example scopes may allow an application to:

• read basic profile information;
• read a list of orders;
• create calendar events;
• publish content;
• read files;
• update product information;
• access data while the user is offline.

The API provider defines the names and meaning of its scopes. A scope does not replace server-side access control. The API must still verify that a token was issued for the correct resource, operation, client, and user.

Under the principle of least privilege, an application should request only the access required for a specific feature.

Authorization Code Flow with PKCE

The Authorization Code Flow is the primary flow used when an application acts on behalf of a user. Modern implementations should combine it with PKCE.

A typical process works as follows:

1. the client generates a random code_verifier;
2. it derives a code_challenge from that value;
3. the application redirects the user to the authorization endpoint, including the client_id, redirect_uri, requested scopes, and code_challenge;
4. the authorization server handles user authentication and authorization;
5. the user is redirected to the registered application address with an authorization code;
6. the application sends the code and original code_verifier to the token endpoint;
7. the server checks whether the verifier matches the previously submitted challenge;
8. after successful verification, the server issues an access token and optionally a refresh token.

The access token is not returned directly in the browser redirect URL in this flow.

What is PKCE?

PKCE (Proof Key for Code Exchange) prevents an intercepted authorization code from being used by an unauthorized party. Even if an attacker obtains the code, they should not be able to exchange it for a token without the previously generated code_verifier.

PKCE was originally designed primarily for public clients such as mobile applications. Current security guidance applies it much more broadly, including to server-side applications.

The S256 method should be used to create the code_challenge whenever it is supported by the authorization server.

Main OAuth flows and grant types

OAuth supports different ways of obtaining tokens depending on the application and use case.

• Authorization Code with PKCE – appropriate for applications acting on behalf of a user, including web, mobile, and single-page applications;
• Client Credentials – used for server-to-server communication when an application acts on its own behalf rather than on behalf of a particular user;
• Device Authorization Flow – designed for devices with limited input capabilities, such as televisions, consoles, and some command-line tools;
• Refresh Token – allows access to be renewed without involving the user again.

New implementations must not use the Resource Owner Password Credentials Grant. This grant requires the user to provide their username and password directly to the client application, expands the attack surface, and interferes with modern login and multifactor authentication methods.

The Implicit Flow is also not recommended for new implementations. Authorization Code with PKCE is safer because tokens are issued by the token endpoint rather than returned directly through the browser-based authorization response.

OAuth vs. OpenID Connect

OAuth 2.0 and OpenID Connect solve related but different problems:

• OAuth 2.0 grants an application access to protected resources;
• OpenID Connect authenticates a user and communicates information about their identity.

OpenID Connect extends OAuth 2.0 with features including the openid scope, ID tokens, standardized user information, and rules for validating responses from an identity provider.

A single integration can use both. An application may verify the user’s identity through OpenID Connect and then use an OAuth access token to retrieve information from an API.

OAuth vs. JWT

OAuth and JWT are not competing solutions of the same type. OAuth is an authorization framework, while JWT is a format for representing and signing a set of statements known as claims.

An OAuth access token may be a JWT, but it does not have to be. An authorization server may also issue opaque tokens whose contents the client cannot inspect.

Receiving a correctly structured JWT does not automatically make its contents trustworthy. An application may need to verify its signature, issuer, audience, expiration time, and intended use.

OAuth vs. an API key

An API key is usually a long-lived credential identifying an application, project, or technical account. It may be appropriate for simple integrations, but it does not provide a complete mechanism for users to delegate access.

OAuth is particularly useful when:

• a user must explicitly authorize an application;
• different applications require different permission scopes;
• access should expire or be renewable;
• access must be revocable without changing the user’s password;
• an API is available to multiple independent clients;
• access for users, applications, and resources must be separated.

API keys also require protection. They should not be placed in public repositories, browser-based JavaScript, mobile application packages, or URLs.

OAuth 1.0, OAuth 2.0, and OAuth 2.1

OAuth 1.0 and OAuth 2.0 are not directly compatible. OAuth 1.0 required cryptographic signing of requests. OAuth 2.0 relies on TLS-protected connections and tokens, while its detailed security properties depend on the selected profile and extensions.

OAuth 2.0 is an authorization framework defined in RFC 6749 and extended by subsequent specifications. A modern implementation should not be designed solely from the original 2012 document. Current security guidance, particularly RFC 9700, must also be considered.

OAuth 2.1 is being developed to consolidate OAuth 2.0 and later security recommendations. The draft promotes Authorization Code with PKCE, removes older mechanisms considered unsuitable for new implementations, and strengthens redirect URI requirements. Its current IETF status should be checked before describing OAuth 2.1 as a finalized standard.

How should OAuth be secured?

OAuth security depends on the entire implementation, not merely on using the protocol’s name. Important safeguards include:

• using HTTPS for every endpoint;
• using Authorization Code with PKCE;
• applying exact validation to redirect_uri values;
• protecting the flow against CSRF;
• validating the state parameter when required by the selected mechanism;
• validating nonce in OpenID Connect flows;
• never placing access tokens in URL query parameters;
• granting the smallest practical set of permissions;
• limiting token lifetimes;
• securely storing refresh tokens;
• rotating or otherwise protecting refresh tokens;
• validating token issuers and audiences;
• protecting client credentials;
• using established libraries instead of implementing custom cryptography;
• logging failed attempts and suspicious events;
• providing a way to revoke access.

Tokens should be treated as confidential information. They should not be written to logs, included in error messages, or disclosed to analytics services.

Storing tokens in a browser

A token stored in localStorage or sessionStorage can be read by JavaScript running on the page. An XSS vulnerability or compromised third-party script may therefore expose it.

Depending on the architecture, safer approaches may include keeping tokens only in application memory or using a Backend for Frontend pattern. In the latter model, tokens remain on the server and the browser uses an appropriately protected session cookie with attributes such as HttpOnly, Secure, and a suitable SameSite setting.

The storage method must be selected in the context of the entire application. Protection against token theft should not result in inadequate safeguards against CSRF, XSS, or session hijacking.

Revoking access and user consent

A user should be able to disconnect an application and withdraw previously granted access. The provider may offer a connected applications panel and a token revocation endpoint.

Removing an integration from the client application does not always revoke the token at the provider. A well-designed process should delete locally stored credentials and, where possible, invoke the authorization server’s revocation mechanism.

Changing the user’s password may not automatically invalidate every OAuth token. This behavior depends on the provider’s security policy.

Where is OAuth used?

OAuth can be used to:

• connect an online store to a marketplace;
• synchronize products, prices, and inventory;
• publish content to social media;
• integrate with CRM or ERP software;
• retrieve data from analytics platforms;
• access cloud-based files;
• synchronize calendars and contacts;
• integrate with payment systems;
• authorize mobile applications;
• support communication between server-side services;
• give external partners limited access to an API.

OAuth is particularly useful when a user or administrator should deliberately connect independent systems and the resulting access needs to be limited, renewable, and revocable.

OAuth in API integrations

Implementing OAuth in an API integration may involve registering the client, configuring redirect addresses, handling user authorization, securely exchanging codes for tokens, renewing access, encrypting stored credentials, managing errors, and allowing accounts to be disconnected.

If you need to connect a website, online store, or application to an external system that uses OAuth, explore our API integration services. We design new connections, implement authorization flows, automate data synchronization, and improve or repair existing integrations.

Common OAuth implementation mistakes

Common mistakes include:

• treating OAuth as a login protocol;
• using an access token as an ID token;
• implementing the outdated Password Grant or Implicit Flow;
• omitting PKCE from the Authorization Code Flow;
• accepting imprecise or dynamically controlled redirect addresses;
• failing to validate state or nonce;
• placing tokens in URLs;
• writing tokens to logs;
• embedding a client_secret in a mobile application or JavaScript code;
• storing tokens without adequate protection;
• requesting unnecessarily broad scopes;
• failing to handle token expiration and renewal;
• providing no mechanism for disconnecting an account;
• assuming that every access token is a JWT;
• failing to validate the issuer, audience, and intended use of a token;
• creating custom cryptographic mechanisms without a valid reason;
• displaying a successful connection message before all security checks have completed.

Is OAuth always necessary?

OAuth is not required for every integration. If one controlled server communicates with a single internal API and there is no delegated access involving users or multiple clients, a simpler mechanism may be sufficient.

OAuth becomes valuable when an application needs different permission scopes, access on behalf of users, support for multiple clients, limited credential lifetimes, or independently revocable access.

The authorization mechanism should be selected according to the system’s threat model, architecture, and business requirements. A more elaborate standard does not improve security when it is implemented incorrectly.

Summary

OAuth allows applications to obtain limited access to protected resources without receiving a user’s password. In OAuth 2.0, access is commonly represented by an access token whose permissions may be restricted by scope, audience, lifetime, and other conditions.

OAuth is not a standalone login protocol. OpenID Connect, which is built on OAuth 2.0, is commonly used to verify a user’s identity.

New implementations should follow current security guidance, including Authorization Code with PKCE, strict redirect URI validation, limited permission scopes, and secure token storage. A correct implementation must cover not only the authorization flow itself but also the complete token lifecycle, error handling, access revocation, and security of every connected system.