Ensure access tokens with a PPID `sub` are unable to access user's email address or userid

[data-sync-user]

Follow on from #1679.

PPIDs are meant to protect a user's privacy by giving a pseudonymous userid to resource servers. Resource servers can currently present the access token to the /verify or /introspect to learn both of these.

If an access token is presented for an RP with PPIDs enabled, we could update these endpoints to:

• Return the real uid and email if the profile scope is present.
• Return the PPID and scrub the email if the profile scope is not present.

There is a follow on here that PPIDs should not be based on client_id, but rather the resource server ID because we have this strange system where a valid access token meant for the profile server can contain a PPID because the only way we have to determine whether PPIDs should be used is based on client_id. Really what we want is to enable PPIDs based on the resource server id the access token is meant to go to.

┆Issue is synchronized with this Jira Task

[data-sync-user]

➤ Shane Tomlinson commented:

This could be made more robust by supporting the Resource Indicators OAuth draft spec ( https://github.com/mozilla/fxa/issues/1817 ). The JWT access token will contain an aud claim with the target resource indicator. If the resource indicator is on the list of resources that require PPIDs, then make the alterations mentioned in the description.

[cknowles-admin]

FxA is no longer synchronizing all issues between Jira and Github. We are closing open issues and will selectively synchronize in the future.