What Is OAuth 2.0?

The problem OAuth solves

Before OAuth, sharing data between applications often meant handing over a username and password. That gave the receiving application unlimited, permanent access and no straightforward way to revoke it short of changing the password — which would break every other integration at the same time. It was an all-or-nothing arrangement that scaled badly and aged worse.

OAuth 2.0 replaced that pattern with delegated authorisation: a client receives a short-lived access token scoped to a specific set of permissions. The token can be narrowed, expired, and revoked independently of the user's credentials, so a leak is contained rather than catastrophic.

This is the foundation that secures the Merion API, where every request carries a token rather than a raw secret. You can read the high-level overview on the Merion developer portal before going deeper.

The four roles

Every OAuth 2.0 flow involves four parties, and naming them up front makes the rest of the framework far easier to follow. The resource owner is the user, or organisation, who owns the data being accessed. The client is the application requesting access on their behalf. The authorisation server issues tokens after verifying identity and capturing consent. The resource server is the API that accepts those tokens and serves the protected data.

In Merion's case, a single platform issues tokens and exposes the protected REST endpoints, but conceptually these remain distinct roles with distinct responsibilities. Keeping them separate in your mental model is the difference between OAuth feeling arbitrary and OAuth feeling logical. Almost every flow you will meet is simply a different choreography of these same four participants exchanging requests and tokens.

Authorisation, not authentication

OAuth 2.0 is fundamentally an authorisation framework: it answers the question "what is this client allowed to do?" It does not, on its own, prove who the user is in a standardised, interoperable way. That gap is filled by OpenID Connect, a thin identity layer built directly on top of OAuth that adds a verifiable identity token.

Confusing the two leads to insecure designs. The classic mistake is treating an access token as proof of login and reading identity out of it, when the access token was only ever meant to authorise API calls. The two concerns belong in separate lanes, even when they happen moments apart in the same flow.

Learn the distinction in What Is OpenID Connect before building any sign-in feature.

Grant types at a glance

OAuth defines several grant types, each suited to a different scenario, and choosing among them is the heart of using OAuth well. The authorisation code flow suits applications acting for an interactive user who can sign in through a browser. The client credentials flow suits server-to-server jobs where no user is present at all. Older grants such as the implicit and resource-owner-password flows are now discouraged because they expose tokens or passwords unnecessarily.

Choosing the right grant is the single most important security decision you will make, and it is largely settled by two questions: is a user present, and can your client keep a secret. Getting this right at the start saves painful rework later, which is why deciding deliberately between the user-facing and machine-to-machine grants is worth doing before any code is written.