Choosing an Auth Flow

The questions that decide

Choosing a flow can feel daunting, but two questions settle the overwhelming majority of cases between them. The first is simply: is a user present? If a human signs in interactively, you need a user-facing flow that can take them through a login and consent step; if there is no human at all, you need a machine-to-machine flow instead. The second question is: can the client keep a secret? A server-side backend can hold one confidentially; a mobile app or browser-based single-page app cannot, because anything shipped to the user can be extracted.

Answering these two questions honestly for your specific Merion API integration points you almost directly at the correct flow, before you have written a single line of code. Most apparent complexity in OAuth dissolves once these two facts about your situation are pinned down clearly.

Matching client to flow

With those two questions answered, the mapping to a concrete flow is refreshingly mechanical. A server-side web application serving a user uses the authorization code flow and may safely keep a client secret on the backend. A mobile or single-page application serving a user uses that same authorization code flow but with PKCE and no secret at all, since it has nowhere safe to keep one. A backend service with no user in the loop uses the client credentials flow, authenticating as itself.

These three patterns between them cover the large majority of integrations you are ever likely to build, which is why memorising them pays off. Each also has a dedicated guide that walks through its mechanics in detail, such as The Authorization Code Flow for the most common user-facing case.

Why avoid deprecated flows

It helps to understand why certain older flows are now actively steered away from, so the advice does not feel arbitrary. The implicit flow returned access tokens directly in the redirect URL, which exposed them to browser history, server logs, and referrer headers; it has accordingly been discouraged in favour of the authorization code flow combined with PKCE, which keeps tokens out of the URL entirely.

The resource owner password flow was worse still in one key respect: it required the user to hand their actual password directly to the application, which defeats much of the entire point of OAuth as a way to avoid sharing credentials. Avoid both of these without hesitation. Modern guidance has deliberately consolidated around the authorization code flow with PKCE and the client credentials flow as the two patterns that together cover nearly every legitimate scenario.

Deciding with confidence

If, after all of that, you are still genuinely unsure which way to go, there is a safe default that will rarely steer you wrong. For anything user-facing, default to the authorization code flow with PKCE; for anything that is machine-only with no user present, default to client credentials. These two flows between them cover the field and both represent current, well-supported best practice rather than legacy compromise.

Once you have settled on a flow with that confidence, the next step is simply to deepen your understanding of how it works in detail and how to implement it correctly. Read PKCE Explained if you are building a public client, then turn to your provider's own reference material for the integration specifics that apply to your particular case before you start wiring everything together.