Reputation: 2134
I have been struggling for days now to find an answer to this, to no avail. When Google supported OpenId 2.0, there was a way to request only an opaque identifier. With this, a third party site could allow users to authenticate via Google, distinguish between the users via this opaque id.
With this lowest level of access, no personally identifiable information was made available from google, so the consent screen was as minimal as possible.
Since Google has now deprecated OpenId 2.0 in favor of OpenId Connect, I can't seem to figure out how (if it's even still possible) to achieve this. It seems that even at a minimum, the consent screen will claim that the third party site wants to "Know who you are on Google".
If opaque ids are no longer an option, does anyone have a source where Google confirms this? If they are possible, could someone point me in the right direction?
Upvotes: 2
Views: 209
Reputation: 2063
I can confirm. Directed identifiers (like in OpenID, where each relying party gets a different identifier) are not an option. We are working to make the approval page as simple as possible for your use case.. essentially not have it. A user will select from a list of account or click on the account (email, name and photo) and that is it (no scary consent page). This will give the id_token with an "id" but that is not directed. Look for more detailed info from us soon.
Upvotes: 1
Reputation: 54028
The amount of information returned in the id_token
is controlled by the requested (and granted) scopes in the authentication request. If the RP only asks for the openid
scope and not the email
and/or profile
scope (or the user grants only the minimal scope), the only user identifying information returned in the id_token
is the sub
claims, which contains a unique opaque identifier.
Upvotes: 0