Not a vulnerabilityNothing is bypassed. The access is asked for openly and granted by the person, in one action with the login, and the objection is to the bundling.
What it is
Signing in through an identity provider works through an authorisation request that states what is being asked for. Authentication needs an identifier and at most a verified address. The request as sent asks for more: a contact list, a calendar, a friend list, posted content, files, profile fields the service never displays. The person sees one screen and one button, so granting the login grants the rest in the same act. What was asked is readable in the address of the authorisation request itself.
Why it is a separate entry
Most of what is granted here concerns other people as well: a contact list is data about people who were never asked anything. The grant usually outlives the session and often the account, it renews itself silently, and declining the extra parts while keeping the login is rarely offered.
How it arises
a scope copied from an example in the provider's documentation
one scope string for the whole application, including features this person never uses
access that a removed feature needed, left in the request
the broadest scope chosen during development so that nothing would fail
Not to be confused with
An identity check that reads a document more fully than the question required is Identity document read beyond the check. This entry is about a delegated authorisation: the extra access is granted rather than read, it concerns a live account elsewhere, and it stays granted after the sign-in is over.
How to establish it
The scope of the authorisation request, readable in the address bar when the provider's screen appears, contains values granting access to records other than the person's identity, such as messages, contacts, calendar, files or posted content; and no control on that screen declines those values while still completing the sign-in. Both parts are read from the request and the screen as delivered.
method network-observedQoD 90
Requirements on the measurement
read the authorisation request as sent, from the address bar or the capture, not the summary the consent screen shows
record the provider, the application version and the date, because scope strings change per release
try declining a single item and record what happens to the sign-in
check the grant afterwards in the provider's own permissions overview, and whether it survives signing out
What would refute it
by handEvery value in the scope corresponds to a feature the person invoked, and the request is made at the moment they invoke it.Asking at the moment of use is the fix, and where it is done this entry does not apply.finding falls
by handThe extra items can be declined individually and the sign-in completes without them.finding falls
by handThe provider requires the value for authentication itself and offers no narrower one.The fault then sits with the party that defined the scope rather than with the application that had to pick one.reclassify
by handThe scope grants only fields the application displays back to the person immediately.weakens
Where this plugs into existing processes
The one question that surfaces itRead me the scope of your login request, and name the feature behind each item.
In a DPIA, verify this
Verify the scope string of the authorisation request against the features that actually exist, rather than the description of the login integration.
As a procurement clause
The authorisation request contains only what authentication requires; access for a feature is requested when the feature is used, and can be declined separately.
With a complaint, hand over
The authorisation request as sent with the scope values marked, a screenshot of the consent screen of the same date, and what happened when a single item was declined.
Reproduction
METHOD.md · by hand · no dedicated reproduction exists yet; follow the general method and the indicator above
Legal framing
eu-gdpr-5-1-c
eu-gdpr-6-1-a
eu-gdpr-25
Objections, and the answer
“The person consented on the provider's screen.”
Consent has to be specific. One button that grants a login and a contact list at once is specific for neither, and the people in that contact list were asked nothing at all.
“We request it but we do not use it.”
A grant is access. What counts is what the token permits, not what this release happens to call, and the next release does not have to ask again.
“The provider designed that screen.”
The application chose the scope string; the screen only renders it. Narrowing it is a change in one line.
“It is needed to make onboarding smooth.”
Convenience is a purpose of the operator. It can be offered as a step the person takes, at the moment they want it, rather than folded into the login.
What this does not establish
harm; the catalogue standardises a finding so it can be referred to, it does not weigh it
severity; there is no score here, by design. Weighing belongs to whoever applies the entry to a concrete case
unlawfulness; that is for a supervisory authority or a court
intent; a fault is usually a build decision, not a plan
absence: not finding it in one capture is not evidence that it is not there
DPE Catalogue. DPE-2026-0033: Sign-in requesting more than identity. Schema 2.0, entry status active. Retrieved from https://totaledigitalewaarborging.nl/register/DPE-2026-0033
Measurement
When you publish a finding, cite the method version alongside the entry: “DPE-2026-0033, established under DPE Measurement Method 1.0”
Identifiers are permanent and are never
reused. An entry that is deprecated keeps its number and its address, with the reason attached, because
references to it exist elsewhere.