Skip to content

/oauth2/userinfo should not be dependent on the claims in token #1582

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
awoodobvio opened this issue Feb 3, 2022 · 2 comments
Closed

/oauth2/userinfo should not be dependent on the claims in token #1582

awoodobvio opened this issue Feb 3, 2022 · 2 comments
Assignees
Labels
enhancement New feature or request standards Issues that refer to IETF, W3C or other standards
Milestone

Comments

@awoodobvio
Copy link

awoodobvio commented Feb 3, 2022

/oauth2/userinfo should not be dependent on the claims in token

Description

In our access token lambda we are stripping out the "email" and "email_verified" claims to avoid exposing PII. The intent was to let the code use the access token to call /oauth2/userinfo as per the spec to get the profile data. Unfortunately, the email claim is not being exposed on that endpoint if the token itself doesn't have it. This held us up for quite some time and required us to push the PII back into the access token for now, which is not a great solution.

Affects versions

1.32.1

Steps to reproduce

Steps to reproduce the behavior:

  1. Get an access token without an email claim in it (lambda should strip it out)
  2. Call /oauth2/userinfo
  3. Notice that while all the other profile data is returned, email is not

Expected behavior

I expect the data from the user profile (including the email) to be provided in the returned userinfo record.

Platform

Hosted with FusionAuth

Related

Community guidelines

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

Additional context

n/a

@spwitt spwitt added enhancement New feature or request standards Issues that refer to IETF, W3C or other standards labels Apr 18, 2024
@spwitt spwitt added this to the 1.50.0 milestone Apr 18, 2024
@spwitt spwitt self-assigned this Apr 18, 2024
@spwitt
Copy link

spwitt commented Apr 18, 2024

@andrewpai
Copy link

This behavior will be supported using the scope handling policy added in 1.50.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request standards Issues that refer to IETF, W3C or other standards
Projects
Status: Delivered
Development

No branches or pull requests

3 participants