Ability to remove PII from api (/oauth2/userinfo, /api/user)

[awoodobvio]

Ability to remove PII from api (/oauth2/userinfo, /api/user)

Problem

At the moment, Fusion Auth leaks a lot of personal data into tokens and on endpoints that may not be relevant to the calling applications. This happens in the /oauth2/userinfo and /api/user endpoints. There is no lambda function that can remove the data (only add to it via a JWT lambda).

Solution

Add a lambda for user profile return data (profile reconcile?) that takes in the jwt, user, registration and profile json object. Allow modifications to the profile json object in the same way that a JWT reconcile lambda allows.

Alternatives/workarounds

None found without a reverse proxy and modification, which still leaves the raw fusion auth api open to abuse. I've found no way to stop data that is present in the user record from leaking to the applications.

Additional context

This can be used maliciously by an app that is using our Fusion Auth instance. I want to be able to control which applications can see details about the user in both the token and the user profile.

Related

• https://github.com/FusionAuth/fusionauth-issues/issues/1474

Community guidelines

All issues filed in this repository must abide by the FusionAuth community guidelines.

How to vote

Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.

[awoodobvio]

Related to #1474

[awoodobvio]

An alternative would be to disallow certain id_token or access_tokens access to those endpoints entirely, but the lambda function is likely a better solution.

[awoodobvio]

Just tested setting claims "family_name", "given_name", etc. to "null" in the JWT lambda, but that didn't work either (unlike for email/email_verified). In addition, setting those values to something else like "test" doesn't end up in the profile data either.

[mooreds]

Hmm. Have a few questions about this

So the User API endpoint is only accessible via an API key, this is pretty privileged, and you can lock down an API key to disallow access (or only allow write access, not read access). Will this not do what you want w/r/t the User API? You could set up a proxy with the only API key that has access and run all your requests through there. The proxy could then modify the response JSON as needed. Or are you more concerned about the other places the user object is returned (Login response, etc)?

As for the userinfo endpoint, that seems pretty reasonable to put a lambda in front of that response. It looks like there are a few fields that are required by the spec: https://openid.net/specs/openid-connect-core-1_0.html#UserInfoResponse but we could simply disallow those from being modified.

[awoodobvio]

@mooreds The /api/user endpoint is accessible with the returned access token - see: Retrieve a User using a JWT in your docs here: https://fusionauth.io/docs/v1/tech/apis/users/#retrieve-a-user

I think that it shouldn't be accessible with the access token, but since you've allowed it it opens up that security issue.

[awoodobvio]

@mooreds The best thing would be to honor the open id "scopes" parameter in the access token (as per the spec) to limit the PII returned. Then if the access token's scope claim is modified the userinfo endpoint would behave correctly.

However, the lambda would also provide more flexibility (add claims from the user.data section) than what is currently offered.

[awoodobvio]

@mooreds The only required field as per the spec is "sub". Otherwise, all other fields are optional (although "iss" and "aud" are suggested)

[mooreds]

The desire to modify what was returned by the userinfo endpoint came up in a call with a prospect today as well.

[spwitt]

Internal

• https://github.com/FusionAuth/fusionauth-app/pull/400

[mooreds]

For anyone reading this, in the next release (1.50), we added a lambda to modify the userinfo response. You can use it to augment the userinfo response, but also to remove data you don't want, such as PII.

[spwitt]

In addition to customizing the response with a lambda, 1.50.0 also adds a new Scope handling policy to the application. Setting this to Strict populate the UserInfo response based on the scope claim of the provided access token rather than providing all available information about the user.

The Strict policy also removes PII (such as email address) from the access token and populates the Id token based on the OAuth scope parameter.

[andrewpai]

Shipping in 1.50.0.