Provide proxy-mail adress in JWT for external apps.

[botnyx]

Privacy-screen per application by setting proxy-email in JWT:email claim

Problem

Lets say i wanna play 'authprovider' for a bunch of public sites. but when i authorize for site A, i would like to pass a unique generated-email-adress for this user+ site A
If the user would authorize site B, it should give a new unique email-adress.

So a user has 'several' email-adresses, each for a specific authorized site.
The idea is to NOT disclose the users official email-adress to external sites, and have some table keeps track of what email should be used for the audience, for this specific user.

Solution

FusionAuth must be able to overwrite the email-claim for each app.
FusionAuth should be able to 'request a unique proxy-email adress' from a external service ( maybe via a 'intergration' )
FusionAuth should keep a administration for each application/user/proxy-email-adress

Alternatives/workarounds

At least an option to overwrite the jwt:email claim would be a good start. Currently its only possible when you manually generate the JWT because the email claim is considered reserved by FusionAuth and is not modifiable using a lambda function.

If FusionAuth allowed configuration of reserved claim, or removed this limitation all together then using a lambda function you could mangle or modify the email claim prior to the JWT being signed by FusionAuth.

Additional context

I just found out apple is implementing something like this in their 'signin with apple' thing.
Apple is taking a firm stance to protect user’s privacy with this new feature. Rather than letting apps see the user’s real email address, they will provide the app with a proxy email address unique to each app. App developers will still be able to send emails to the proxy addresses, it just means developers won’t be able to use the email addresses to correlate users between apps, and it also means users can shut off email forwarding per app.

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.

[botnyx]

For what its worth: i did some quick research on mailservers which have an administration-api, and 'Apache James' seems a perfect candidate, as it has a complete crud-api + jwt auth.
https://james.apache.org/server/manage-webadmin.html

[jerryhopper]

So, im still struggling with anonymizing the email-adress in the JWT.

As the lambda fuction doesnt change the email adress, ive been looking at 2 options.

1. Change the email adress in FA
This approach works ok, but a email-forward is needed to forward mail from the anonymized-Email, to the real email-address.
Also, logging in requires to use the 'anonimized' email adress - or the username to login.

Problem: people tend to forget their anonimized email address, and a external mailservice is required.

2. issue my own rolled jwt - this allows me to do whatever i want - but requires some sort of extra administration/logging needs.

Problem: splitting 'securityservices' in two parts creates more administration/logging tasks, and opens more security risks ( customjwt-generator / mailserver ). Also, the possibility to check a JWT against FusionAuth is not possible.

Question:
Is there a (temporary) workaround to make Lambda overwrite the EMAIL optional(?).

Why would FusionAuth benefit from this functionality?

In a perfect world the Login screen, claims should be visible for users, so they see them and are able to allow/deny what data is being transferred to the application you are logging in to.

The ability to anonimize your emailaddress, would be the good step forward in total control of a users privacy.

Sidenote:
Obviously, the openid ID-token eventually needs to reflect anonimized data.
But to avoid extra complexity in fusionauth, when this 'overwritable-email' option is enabled, just overwriting the email-claim in the oauth2 token would suffice, as a custom userinfo api-endpoint could cover the other anonimized information.

Disabling openID/id token When 'email-cloak' is enabled, would prevent leaking the 'real' information.

[jerryhopper]

In Addition to email-cloak, the 'Birthday' of a user is 'personal' information according to GDPR.
GDPR recommends displaying a Age-range/groups instead of the actual birthday.

So, if lambda's could overwrite the email & birthday - fusionauth would be even more GDPR compatible. Age groups would look like: UNDER_16, UNDER_21, OVER_50

Example:

In my usecase, a external application (like a job-board) uses a public idp service (fusionauth)
In order to keep this public idp GDPR compliant, ideally i dont want to display the real email adress and the exact birthdate.
Fusionauth doesnt allow overwriting of email & birthdate.
Initially - i solved the email problem by issueing a email adress via signup of the idpservice.
so:
The real emailaddres me@gmail.com becomes me@someidp.ext ( where me@someidp.ext forwards to me@gmail.com )
This solves the email-cloaking problem.
The age however becomes a more challenging problem. GDPR suggests using ageranges over exact birthdates in many cases.
So, ideally, fusionauth should output agegroup like: UNDER_16 UNDER_21 OVER_40
Is there anyone here thats facing a similar challenge?? - or uses a different approach?
feedback is appreceated.

[jerryhopper]

According to Robotdan, overwriting the birthdate should be possible already. Unfortunatly there's a bug with that. A overwrite attempt on the birthdate field results in a array result.

see : #398

Overwriting the email is a feature that is further discussed in #387