Skip to content
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

ParsedToken type does not support allowed value types in Firebase custom claims #6553

Closed
briandonahue opened this issue Aug 23, 2022 · 1 comment · Fixed by #6569
Closed

Comments

@briandonahue
Copy link

[REQUIRED] Describe your environment

  • Operating System version: MacOS
  • Browser version: n/a
  • Firebase SDK version: 9.9.2
  • Firebase Product: auth

[REQUIRED] Describe the problem

When receiving an IdTokenResult for a user, the claims property is of type ParsedToken. This only provides for custom claim fields with the following signature:
[key: string]: string | object | undefined

But Firebase (and firebase-admin) support other types such as boolean and number. This results in confusion if you try to use a ParsedToken object as argument to match against custom claims. For example, my user can have the claim admin: true but that is invalid in a ParsedToken, you can only set admin: 'true' which does not match the boolean value.

I noticed this while using the reactfire library, as they use a ParsedToken to validate required claims.

Steps to reproduce:

1 - attempt to create a ParsedToken object with a boolean or numeric value.

Relevant Code:

const invalidClaims: ParsedToken = {
  admin: true, // not valid
  score: 500 // not valid
}
@sam-gc
Copy link
Contributor

sam-gc commented Aug 26, 2022

Thanks for filing this. The more accurate type is unknown here. The linked PR will update the type

@sam-gc sam-gc added the bug label Aug 26, 2022
@firebase firebase locked and limited conversation to collaborators Oct 8, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants