Skip to content

Consent

A club decides what your application may do in it. You cannot request access, and there is no pending state for anybody to approve out of habit — which also means there is nothing an attacker can create that looks like a request from you.

What you send the club

Your application identifier, and the scopes you need. Send the identifier the registration returned, not the client identifier: the client identifier is what you authenticate with, and it belongs in your configuration rather than in an email.

What the club does

  1. Switches the developer platform on, if it has not already.
  2. Looks your application up by that identifier, to see its name and which developer organization owns it.
  3. Grants it the scopes it agrees to, which may be fewer than you asked for.

A club can see which applications it has authorised and what each one may do, and can narrow or withdraw a grant at any time. Withdrawing takes effect on the very next request you make, with the token you already hold. Nothing is needed from you.

One club, one grant

A club has at most one grant to your application, so the answer to “what may this do here” is never ambiguous. Widening it is the club amending that grant, which is recorded as a fresh decision by whoever made it. A club that withdrew and later changes its mind authorises you again on the same grant.

What you can see

Which clubs have authorised you, and what each allowed. You cannot see which clubs exist, which have not authorised you, or anything about a club that has withdrawn beyond the fact that it did.

Note

A grant is not a subscription, an entitlement or a purchase. It is permission to act, and it says nothing about anybody having paid for anything.