OAuth is an open standard for authorization: it lets an application access data or functions in another system on behalf of a user, without the user ever giving that application their password. When you connect your accounting software to your web shop and click "Allow" on a login screen of the accounting package, that is OAuth at work. The current version is OAuth 2.0 (RFC 6749, 2012); the older OAuth 1.0 is hardly used anymore, and OAuth 2.1 bundles today's security best practices into one specification.
How does OAuth 2.0 work?
OAuth involves four roles: the user (resource owner), the client (the application that wants access), the authorization server (which logs the user in and issues tokens) and the resource server (the API with the data). The most common flow, the authorization code flow, goes like this:
- The application redirects the user to the authorization server, stating which permissions (scopes) it wants, such as "read invoices".
- The user logs in there and approves the request. The application never sees the password.
- The authorization server sends the user back with a one-time authorization code.
- The application exchanges that code, server to server, for an access token and usually a refresh token.
- The application calls the API with the access token. When it expires, a new one is fetched with the refresh token, without bothering the user.
OAuth flows (grant types)
- Authorization code with PKCE: the standard for web apps, mobile apps and single-page apps. PKCE protects against intercepted codes.
- Client credentials: for server-to-server communication without a user, such as a background job calling an API.
- Device authorization: for devices without a proper keyboard, such as TVs and terminals.
- Refresh token: to get new access tokens without logging in again.
- Implicit and password grant: older flows that are now considered insecure and are dropped in OAuth 2.1.
OAuth vs. OpenID Connect and authentication
OAuth is about authorization (what an app may do), not about authentication (who the user is). For login, OpenID Connect (OIDC) adds an identity layer on top of OAuth 2.0: besides the access token, the app receives an ID token, a JWT with information about the logged-in user. "Log in with Google" or "Log in with Microsoft" is OpenID Connect. Identity platforms such as Auth0, Microsoft Entra ID and Keycloak implement both standards.
OAuth in integrations
Many business APIs use OAuth 2.0, including Exact Online, Twinfield, Salesforce, HubSpot and Shopify. In practice, most integration problems with OAuth are not in the first login but in what follows: access tokens that expire after minutes, refresh tokens that rotate with every use or expire after a period of inactivity, tokens that must be stored encrypted, and a connection that silently stops working when a user leaves the company. A robust integration refreshes tokens on time, handles every error case and alerts someone when re-authorization is needed. See our API integrations, API development and, for example, our Exact Online integration.
Frequently Asked Questions about OAuth
What is the difference between OAuth and OAuth 2.0?
OAuth 2.0 is the current version of OAuth and not backward compatible with OAuth 1.0. When people say OAuth today, they almost always mean OAuth 2.0.
Is OAuth secure?
OAuth 2.0 is secure when implemented according to current best practices: authorization code flow with PKCE, HTTPS everywhere, exact redirect URIs, short-lived access tokens and securely stored refresh tokens. Most incidents come from implementation mistakes, not from the standard itself.
What is an OAuth scope?
A scope is a permission the application requests, such as read-only access to contacts. The user sees which scopes are requested, and the token only grants those permissions.
Is OAuth the same as single sign-on (SSO)?
Not exactly. SSO means logging in once for several applications. It is often built with OpenID Connect (on top of OAuth 2.0) or SAML, but OAuth on its own is for authorization, not login.