12-15-2020 09:23 - last edited on 12-15-2020 09:30 by GordonFitbit
12-15-2020 09:23 - last edited on 12-15-2020 09:30 by GordonFitbit
From one day to the next (around December 14) my app users can't get a token anymore, because of the following error when calling https://api.fitbit.com/oauth2/token:
{"errors":[{"errorType":"invalid_grant","message":"Authorization code verifier invalid: <auth_code> Visit https://dev.fitbit.com/docs/oauth2 for more information on the Fitbit Web API authorization process."}],"success":false}
Nothing changed in the app (no update), I checked manually for the code verifier shown in this example error, the challenge used was <challenge> and that's the correct challenge with the code verifier <verifier>
I get many reports starting around the December 14, 22:00 UTC (although the problem may exists already a few hours, not every user reports a problem).
I have no idea what is wrong, because it worked for a long time. Did something change at the Fitbit checking mechanism for code challenge/code verifier?
Answered! Go to the Best Answer.
12-17-2020 19:54 - edited 12-19-2020 17:34
12-17-2020 19:54 - edited 12-19-2020 17:34
After further investigation, it was determined there was a typo in the authorization URL's code_challenge_method parameter name which defaulted the code_challenge_method value to "plain" instead of user specified "S256".
12-15-2020 12:54
12-15-2020 12:54
Hi @Hielko
Please don't provide sensitive data in the public forums, such as your challenge and verifier. We made a change recently where the applications using PKCE need to specify the application type = "client". Would you please verify what your application type is?
GOrdon
12-15-2020 13:12
12-15-2020 13:12
Hi @GordonFitbit,
Thanks for your reply. I'm sorry for the sensitive data.
The OAuth 2.0 application type is 'client', I'm sure it already was since the beginning.
Please let me know what additional information you need. I am collecting complaints from users currently 😞
Best regards,
Hielko
12-17-2020 19:54 - edited 12-19-2020 17:34
12-17-2020 19:54 - edited 12-19-2020 17:34
After further investigation, it was determined there was a typo in the authorization URL's code_challenge_method parameter name which defaulted the code_challenge_method value to "plain" instead of user specified "S256".