Hi !
I recently tried the impersonation feature in dashboard, using client side link.
My SPA get the generated idToken and send it to my API, which check the token ‘kid’ against my remote jwks JSON file.
However, I get an error as the kid is not present, as well as many informations like email, first_name, updated_at … etc.
Is it intended ?
Thanks
Hey there @ValdoGhafoor, if you decode your JWT file do you see the kid prop come across? I have included a JWT decoder below, thanks!
I noticed that with scope at “profile email openid”, i have informations I was looking for like email, firstname …etc bust still get a missing kid
I was able to find some more details relating to the kid property via an older community post. It may not be needed for what you are trying to accomplish. I have put a link below to the topic. Please let me know if this helps in your quest, thanks!
I don’t understand your answer.
The answer your linked is just confirming that I need the kid in the token to validate it.
And my problem is that the kid is missing from the token
Let me try to explain this better, after looking at your endpoint with support, we were able to verify you only have one key associated with your account. When leveraging a kid property, it is used to identify one specific key identifier from within that list. Since you only have one, this should not be needed in your use-case. However if I am miss understanding your desired result, please let me know so I can better assist you. Thanks in advance.
Thanks for your answer.
For me it looks like a security issue.
I’m checking the kid of the token against the one on the endpoint to verify its signature.
Why wouldn’t it be needed in my case ?
Are you trying to say that checking the kid is useless because we have only one key on the endpoint ?
The kid from the JWKS (in fact, the JWKS itself) is only used to validate RS256 ID tokens. If you’re using HS256 (which your screenshot shows and my test using the Sign In as User in the Dashboard confirms) then the ID token is validated using the Client Secret for that application.
So, in this case, the kid is useless because it is not used in this context. In the case of RS256, though, a kid still is not required (RFC) since we would just use the first (or, in most cases, the only) key that was present in the JWKS. The token would still be validated using the JWKS but the key used would not be explicitly defined (leading to possible issues if the ID token was issued right when the key was being rotated).
If you want to go into a bit more depth here, we have a blog post on the topic:
Hope that helps and let me know if you have any other questions!
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.
