Disclose which information the provider will share

What it is

Consent for federated login happens on the provider’s grant screen and in the one sentence the product writes before the jump. Disclosing what will be obtained means that, before tapping Allow, someone can list the fields and permissions the local app will receive: public profile, email, friend graph, ability to post. The list is the scopes actually requested, not a brand slogan. This entry is only about whether disclosure is complete and matches the real request. It does not judge whether federation is worth using, and it does not cover how settings later show which method was used.

Why it happens

The grant screen is a scope negotiation that copy often hides behind “Continue.” People treat social login as “prove it is me,” while the provider may also hand over contacts, a public timeline, or a relay address that hides the real mailbox. If the product only says “quick login with WeChat” before the jump, the mental model stays at identity assertion; the data flow is discovered afterwards. Over-requesting gets denied on the provider page or rejected in store review; under-requesting forces a second permission ask after login, burning trust twice. The usual failure is not silence but an unverifiable collective noun such as “basic information.”

Studying it

Align three texts—the product’s preview, the provider grant screen, and the claims in the actual token—and test whether people can recap the shared items before consent.

Independent variables: field-level list before the jump, item-by-item match to requested scopes, separating “needed to sign in” from “extra profile.” Dependent variables: grant rate, recall accuracy of shared items after grant, later revocation and complaints, store or provider rejections for over-broad scope.

Labs often use test apps whose warning copy differs from production. Studies have to run on the target provider’s production grant screen, because WeChat, Apple, and Google differ in default copy and hide-my-email behavior. A higher grant rate paired with “I did not know the friend list was shared” is compliance, not informed consent.

Where it stops holding

When the provider forbids custom grant copy, the product can disclose only on its own pre-jump surface; skipping that surface is non-disclosure. Enterprise IdP scopes are pre-granted by an admin, so the audience for disclosure is review, not every click. Integrations that request only an OpenID identity assertion can keep the list as short as “to prove it is you”; a long field list would overclaim. Legally required minima cannot be replaced by “see clause 12 of the privacy policy” instead of an on-screen field list.

Applying it

• Before jumping to the provider, list requested items at field level and split “required to sign in” from optional profile; optional items must not be bundled as the default grant.
• Generate the list from the same source as the scopes in code; marketing copy and engineering config must not diverge.
• After return, echo in account settings what was obtained from that provider, with a path to the provider’s revocation page.
• Verify by stopping people uninvolved in the project before grant and asking them to write every item that will be shared; miss or extra against the token claims is failure. Sample a production request to confirm no scope sits outside the list.

Related

• Within the group: H6.02.1 Third-party login cuts typing but creates dependency · H6.02.3 People need to see which method they used to sign in
• Adjacent: H4.02 Purpose explanation · H6.08 Account deletion · H4.09 Contacts and photos permission
• Search terms: OAuth scopes · informed consent · federated identity disclosure