Understanding OAuth2 Authorization flows

Updated: October 17, 2025

October 17, 2025

Last updated: May 2026

OAuth 2.0 is an industry-standard protocol for authorization that lets applications request limited access to a user's data on an API service without sharing passwords. This overview highlights the core flows that Unified supports. OAuth itself has two major versions (1.0 and 2.0), and OAuth 2.0 defines several flows. Overall, Unified supports 70+ OAuth 2.0 variations across integrations, spanning integration-specific scope models, token formats, and authorization requirements.

We won't cover OAuth v1, which is no longer widely used and has largely been superseded by OAuth 2.0, published as RFC 6749 in October 2012. RFC 6749 states it "replaces" OAuth 1.0, though OAuth 1.0 (RFC 5849) remains published and is not formally deprecated.[1][2]

OAuth 2.1 is still in progress (as of Oct 2025). It consolidates best practices from OAuth 2.0—removing deprecated flows like implicit and password, and enforcing stronger security defaults such as PKCE—so it is not fully backwards-compatible with every 2.0 flow.

OAuth 2.0 Authorization Code Flow

The OAuth 2.0 Authorization Code flow (code flow) is designed for applications that need to access a user's data in a third-party service (e.g., Google, Salesforce, HubSpot) with the user's explicit consent. It's the standard behind options you see all over the internet like "Sign in with Google." This flow is used for delegated authorization—API access on behalf of a user—and can also support authentication when combined with OpenID Connect.

How it works:

• Your app redirects the user to the integration's authorization page. This URL contains your app's client ID from that integration, plus integration-specific permission scopes and a redirect URL. It can also contain additional information such as state, PKCE challenge, and many more integration-specific parameters.
• The end-user logs in to that integration (if not already logged in) and is shown what permissions your app is requesting. They can then approve or reject that access request.
• If approved, the integration redirects back to your app with a temporary code.
• Your backend exchanges the code for an access token (and optionally a refresh token). This step uses both the client ID and client secret, securing the transaction. The access token will have an expiry, which requires the use of the refresh token to obtain new access tokens.
• Your app uses the access token in the Authorization header to call that integration's API on behalf of the user.

Unified.to handles all aspects of this OAuth2 flow:

• creating the authorizing URL correctly
• unifying permission scopes (e.g. crm_contact_read, accounting_invoice_write, …)
• exchanging codes for access tokens
• automatically refreshing access tokens (and optionally refresh tokens)
• calling the end API with the access token in the correct header and format

This happens with our pre-built components, or directly through our Authorization API.

Our customers just input their application's OAuth2 client ID and client secret, obtained once from the integration. Unified also provides instructions on how to obtain those OAuth credentials.

Currently, Unified.to supports 176 integrations that use OAuth2 code flow.

OAuth 2.0 OpenID Connect (OIDC) Flow

The OpenID Connect flow is built on top of OAuth 2.0 and is used primarily for user authentication (identity), often alongside OAuth 2.0 authorization for API access.

It returns an id_token—a JWT (JSON Web Token) containing verified user identity claims, such as a name and email—and can also provide a /userinfo API endpoint to obtain the verified identity. Depending on the integration and the scopes requested (for example, offline_access), it can also issue access and refresh tokens.

When you see a "Sign in with Google" button, that is usually an OpenID Connect flow.

Unified.to hides this complexity in our Unified Authentication API, supporting OIDC along with integrations that only support OAuth2 code flow with non-standard User Info API endpoints.

OAuth 2.0 Client Credentials Flow

OAuth 2.0 client credentials flow is for server-to-server (machine-to-machine) authentication. No user is involved; your backend service authenticates as itself to access application-level or tenant-level data—not an individual user's data. The customer (or a tenant admin) obtains a client ID and client secret from their integration and provides it to your application.

How it works:

• The customer or tenant admin generates an OAuth2 client ID and client secret in their integration and gives it to your application. They usually set what permissions they're willing to grant to those credentials.
• Your backend sends the client ID and secret to the integration's token endpoint.
• The integration returns an access token.
• Your backend uses the token to call APIs.

With Unified.to, your end-user will be asked to fill out these credentials, plus any other required credentials to access that integration's API.

Currently, Unified.to supports 29 integrations that use OAuth2 client_credentials flow.

API Token / Key / Username & Password Authentication

APIs can also be authenticated with an API key, API token, or even a username and password. The keys and tokens consist of either random characters or an encoded JWT (JSON Web Token).

They can be sent in the Authorization header, in a custom header, or in the URL query as a parameter.

If an API uses username and password for authentication instead of an API key, that combination is sent in the Authorization header, base64-encoded as "username:password".

Because these credentials must be kept secret, they should only be used in backend environments. Using them in client-side code (e.g., a browser) would risk leaking them to the end-user.

Unified.to can ask the end-user for any number of API keys/tokens and additional required API credentials. Optionally, our customers can request this information from their end-users and create a connection manually.

If you're interested in reading about more complexities with OAuth2, read our blog post: "How We Normalize OAuth Across 460+ APIs at Unified.to".