OAuth 2.0 is the system behind the screen that says "This app wants to access your account. Allow?" Instead of typing your password into a third-party tool, you are sent to the service that holds your account, you approve a list of permissions, and the tool receives a limited pass. It never sees your password, and you can cancel the pass whenever you want.

It concerns anyone who connects business tools together. When you link a scheduling app to your Instagram account, let an accounting tool read your payment history, or give an analytics service access to your Google account, OAuth is almost always doing the work. Knowing how it behaves helps you grant the right access, spot risky requests and clean up after a freelancer or a tool you no longer use.

What is OAuth 2.0?

OAuth 2.0 is an open authorization standard, published in 2012 as RFC 6749 by the Internet Engineering Task Force. It defines how an application can obtain limited access to resources that you own on another service, with your approval, through a token instead of your credentials.

Four roles appear in every OAuth exchange:

  • Resource owner: you, the person who owns the account and the data.
  • Client: the app that wants access, such as a reporting tool.
  • Authorization server: the part of the service that asks for your consent and issues tokens.
  • Resource server: the API that holds your data and accepts the token.

The key word is authorization, not authentication. OAuth answers "what is this app allowed to do?", not "who is this person?". Logging in with Google or Apple on a website relies on OpenID Connect, a layer built on top of OAuth 2.0 that adds an identity token. People often say "OAuth login" for both, which is fine in conversation but worth knowing when you evaluate security. OAuth is also related to single sign-on, which uses similar mechanics to let one login open many tools inside a company.

Other terms you will see:

  • Access token: the pass the app presents with each request. It usually expires after minutes or hours.
  • Refresh token: a longer-lived token that lets the app get a new access token without asking you again.
  • Scope: a named permission, such as "read orders" or "manage posts".
  • Consent screen: the page where you see the requested scopes and approve or refuse.
  • Revocation: cancelling a token so the app loses access.

OAuth 1.0 existed before and is now mostly retired. When people say OAuth today, they mean version 2.0.

Why it matters

Before OAuth, the only way to connect two services was to give the second one your username and password. That tool then had full access to everything, forever, or until you changed your password and broke every other connection at the same time. OAuth replaced that with access that is limited, visible and reversible.

For a seller, this is a direct business risk question. Imagine a brand doing 800 orders a month at $45, about $36,000 in monthly sales. Over two years, the founder connected 12 apps to the payment account and the social accounts: a reporting tool tested for a week, two schedulers, a freelancer's automation, a review app. Three of those companies no longer exist. If any one of them is breached and its stored tokens leak, an attacker could read customer data or post from the brand's accounts. A 15-minute review that revokes 7 unused connections removes most of that exposure at no cost.

OAuth also matters when you work with people. When an agency needs access to your ad account or your email tool, a proper OAuth connection or a dedicated team seat means you never share the owner password, and you can end access on the day the contract ends.

How it works

The most common flow, used by web and mobile apps, is the authorization code flow. Step by step:

  • You click "Connect". Inside the client app, you choose to link your account on another service.
  • You are redirected. Your browser goes to the service's authorization server, over HTTPS. The address includes the app's ID, the scopes it wants and where to send you back.
  • You sign in there. You log in on the real service, ideally with multi-factor authentication. The client app never sees this step.
  • You review and consent. The consent screen lists the permissions. You approve or cancel.
  • The service sends back a code. Your browser returns to the client app with a short-lived, one-time authorization code.
  • The app swaps the code for tokens. Server to server, the app exchanges the code, plus its own secret or a PKCE proof, for an access token and often a refresh token.
  • The app calls the API. Each request carries the access token. The resource server checks it and only allows actions covered by the scopes.
  • Tokens expire and renew. When the access token expires, the app uses the refresh token to get a new one, until you revoke access.

Other flows exist for special cases. The client credentials flow connects two servers with no human involved. The device flow serves TVs and consoles, where you approve on your phone. The older implicit flow is now discouraged.

Benchmarks and examples

Useful reference points:

  • Access token lifetime. Commonly 15 minutes to 1 hour. Tokens valid for days carry more risk if stolen.
  • Refresh token lifetime. From a few weeks to indefinite until revoked. Many services now expire unused refresh tokens after 30 to 90 days.
  • Scopes requested. A reporting tool should ask for read-only scopes. A tool that only builds charts but asks to "manage payments" or "delete content" deserves a question.
  • Connected apps. Small businesses that have run for a few years often have 10 to 30 connected apps across Google, Meta, payment and email accounts. Many are forgotten.

Typical situations:

  • A creator connects a scheduling tool to Instagram and TikTok. Each platform shows an OAuth consent screen and lists the tool under connected apps.
  • A small brand connects its accounting software to its payment provider with read-only access to transactions.
  • A founder building a SaaS MVP adds "Sign in with Google", which relies on OpenID Connect on top of OAuth.

Common mistakes

  • Approving every scope without reading. The consent screen exists so you can say no to permissions a tool does not need.
  • Never reviewing connected apps. Old tokens keep working. Tools you stopped using years ago may still hold access.
  • Sharing passwords when OAuth is available. Giving a freelancer the owner password instead of a connection or a seat removes every limit and every trace.
  • Assuming OAuth means the app is safe. OAuth protects your password. It says nothing about how carefully the app stores your data.
  • Connecting with a personal account. If the owner leaves, the connection breaks. Use a shared business account where possible.

Best practices

  • Review connected apps each quarter. Check Google, Meta, TikTok, your payment provider and your email tool. Revoke anything unused.
  • Grant the smallest scope. Prefer read-only when the tool only reports. Refuse broad write access unless you understand why.
  • Protect the account behind the consent. OAuth is only as strong as the login it relies on. Turn on MFA for every account that approves connections.
  • Offboard properly. When a contractor or agency leaves, revoke their connections and tokens on the same day.
  • Check the vendor. Before connecting, look for a clear privacy policy, a real company behind the app and recent updates.
  • Ask developers for standard flows. If you commission an integration, ask for the authorization code flow with PKCE and secure storage of tokens on the server.

In Roctify

Roctify does not offer OAuth login or a public OAuth API for third-party apps today. You sign in to your Roctify account directly, and the platform handles the parts of the store that would otherwise need many connected apps: one catalog shared by the link-in-bio page and the storefront, built-in checkout, email marketing and analytics depending on your plan. Payments run through Stripe and PayPal, which you connect in your payment settings, and Roctify serves every page over HTTPS with a free SSL certificate.

Fewer tools connected to your business accounts means fewer tokens to track. On the Pro plan, team members get their own access, so you do not have to share the owner password with a helper or an agency. Integrations beyond the built-in features are discussed on the Enterprise plan.

FAQ

Is OAuth the same as "Sign in with Google"?

Not exactly. "Sign in with Google" uses OpenID Connect, which is built on OAuth 2.0 and adds a way to confirm who you are. Plain OAuth only grants an app permission to act on your data. In everyday talk, both are often called OAuth.

Can an app see my password with OAuth?

No. You type your password on the real service's page, not in the app. The app only receives a token with the scopes you approved, and you can revoke that token at any time without changing your password.

What should I do if a connected app is breached?

Revoke its access right away in the account settings of every service it was connected to. Then check recent activity, such as posts, exports or payment changes, and change your password if the app ever received it by other means. Turning on MFA adds another layer for the future.