Consent and Authorization

What consent establishes

Consent is the point in a flow where the user explicitly agrees to let an application access specified data or perform specified actions on their behalf. It is what turns an abstract scope request into an informed, deliberate decision, ensuring that delegated access genuinely reflects the user's intent rather than an assumption the application has made for them.

In OAuth and OIDC flows, the consent screen is where the requested scopes are made visible to the person they concern, in terms they can ideally understand. On the Merion API, this step keeps every delegated grant transparent: the user can see what they are agreeing to before they agree to it. Consent is therefore not a bureaucratic hurdle but the mechanism that makes "acting on someone's behalf" honest, accountable, and grounded in a real choice the user actually made.

A good consent request

Good consent is specific and minimal above all else. A well-designed request asks only for the scopes the task at hand actually needs, describes each of them in plain, non-technical language, and avoids bundling unrelated permissions together into a single take-it-or-leave-it block. A user who can clearly understand exactly what they are granting is a user able to make a meaningful choice rather than a reflexive one.

Over-broad consent requests have real costs: they erode trust, and they may cause cautious users to abandon the flow entirely when the request looks disproportionate to what they were trying to do. Minimal, clearly explained scopes, by contrast, signal that the application respects the user's data and has thought carefully about what it truly needs. The scopes you choose to request are explored further in OAuth Scopes Explained.

Consent is not authentication

It is worth being precise about a distinction that is easy to blur. Consent answers the question "do you allow this application to do X on your behalf?" — which is a fundamentally different question from "who are you?" Authentication establishes identity; consent grants permission. They are two separate concerns that happen to sit close together in a typical sign-in journey.

A complete flow does both in sequence: the user first proves who they are through authentication, and then separately approves what the application may do through consent. Conflating the two leads to muddled, insecure designs, such as treating the fact that someone logged in as though it were blanket permission for everything an application might want. Keep identity and permission as distinct steps in your thinking, even when they appear on adjacent screens only moments apart.

Reviewing and revoking

Consent should never be permanent and silent, granted once and then forgotten. Users benefit greatly from being able to review what they have previously granted to which applications, and to revoke any access they no longer want or recognise. When access is revoked, the relevant tokens are invalidated, which cleanly cuts off the application's continued access to the user's data.

Designing for revocation from the very start, rather than bolting it on later, respects users and meaningfully limits the damage if an application is later found wanting or turns out to be misbehaving. An integration that assumes consent is forever is one that has no graceful answer when trust breaks down. This mindset pairs naturally with the least-privilege thinking that runs through these guides: grant little, make it visible, and make it easy to take back.