Unified.to
All articles

Understanding OAuth2 Authorization flows

October 20, 2025

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 exposing passwords. This overview highlights the core flows that Unified supports. OAuth2 has 2 versions, and v2 has several flows. Overall, Unified seamlessly supports over 70 variants of just OAuth2.

We will not bother with OAuth v1 as it was formally obsoleted when the OAuth 2.0 spec was published as RFC 6749 in October 2012. The RFC explicitly states it "replaces and obsoletes" OAuth 1.0 (RFC 5849).[1][2]

OAuth 2.1 is still in-progress (as of Oct 2025) and will be backwards-compatible to v2.0, but make the flows more restricted to add additional security.

OAuth2 Code Flow

OAuth2 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 for options you see all over the Internet like "Sign in with Google" and gain delegated access. This flow can be used to grant access to data and/or to retrieve the identity of the authenticated user.

How it works:

  • Your app redirects the user to the provider's authorization page. This URL contains your app's client ID from that provider, plus provider-specific permission scopes and a redirect URL. It can also contain additional information such as state , PKCE challenge, and many more provider-specific parameters.
  • The end-user logs in to that provider (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 provider redirects back to your app with a temporary code.
  • Your backend exchanges the code for an access token (and optionally refresh token). This step uses both the client ID and client secret, essentially securing the transaction. The access token will have an expiry which will require the use of the refresh token to obtain new access tokens.
  • Your app uses the access token in the Authorization header to call that provider's APIs on behalf of the user.

Unified.to handles all aspects of this OAuth2 flow;

  • creating the authorizing URL correctly
  • unifying permission scopes (eg. 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 provider. Unified also provides instructions on how to obtain those OAuth credentials.

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

OAuth2 OpenID Connect (OIDC) Flow

The OAuth2 OpenID Connect flow is very similar to OAuth2 code flow, except that it is only used for user authentication.

It differs from the code flow with not supporting long-servicing access tokens and refresh tokens, since it is meant to be an instant identity verification service.

It will either return an id_token that is a JWT-encoded object contained the verified user identity, such as a name and email. Or it will support a /userinfo API endpoint to obtain the verified user identity.

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 providers that only support OAuth2 code flow with non-standard User Info API endpoints.

OAuth2 Client Credentials Flow

OAuth2 client credentials flow is for server-to-server (machine-to-machine) authentication. No user is involved; your backend service authenticates as itself to access APIs without the involvement of a human. To access a end-user's data, they have to obtain a client ID and client secret from their provider and give it to your application.

How it works:

  • Your end-user generates an OAuth2 client ID and client secret in their provider/application and gives it to your application. They usually will set what permissions they are willing to grant to those credentials.
  • Your backend sends the client ID and secret to the provider's token endpoint.
  • The provider 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 support OAuth2 client_credentials flow.

API Token / Key / Username & Password Authentication

Additionally, APIs can also be authenticated with a 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 instead of an API Key, an API uses username and password for authentication, that combination is sent in the Authorization header but base64-encoded as "username:password".

Since these values are sent in the clear for an API request, they should only be sent by a backend as they would be leaked to the end-user if used in a browser.

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.

Currently, Unified.to supports 226 integrations that support API keys/tokens.

If you are interested in reading about more complexities with OAuth2, read our blog post about "How we normalize Oauth across all of our API integrations"

All articles