Oauth2 failing to get new token

[YisusChrist]

See report in #22.

The request sent to retrieve the authentication token fails returning a 400 Bad Request error:

• Request: https://myanimelist.net/v1/oauth2/authorize?response_type=code&client_id=3a53b...&state=RequestID42&code_challenge=nSakl1Ls...&code_challenge_method=plain&redirect_uri=...

• Response:

  {
  "error": "invalid_grant",
  "message": "The provided authorization grant (e.g., authorization code, resource owner credentials) or refresh token is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client.",
  "hint": "Failed to verify `code_verifier`."
  }

Everything seems to be correct in the request according to the API specification and the unofficial guide.

Adding the redirect_uri parameter does not solve the problem.

[ModerNews]

Hi! I will need some additional info, since it seems like I cannot quickly reproduce the issue. Let's start with a few simple things:

• Do you use the classmethod generate_new_token, or do you use the generate_authorization_url/fetch_token_schema_2
• Do you use autogenerated code_verifier?
• What OS are you working on?

Maybe any of those will let me reproduce the issue.

[YisusChrist]

Thank you for reaching me here and taking your time to review this.

I am using the generate_new_token class method to get the authentication token for 1st time, as it is needed for some API calls. Calling that function with my personal Client Id and Client Secret automatically opens a website in my browser to generate the code to be used in the next authorization request.

The code_verifier that I use (the one used by the generate_new_token function) is the one obtained from the generate_authorization_url. I don't modify anything of that code_verifier on my side. So yes, I am using the autogenerated code_verifier.

I am performing the tests on Windows 11 23H2 Build 22631.2861. Tbh, I haven't tried in Linux but I don't think there is any difference, because the issue is related to a possibly malformed request and MAL server refusing the authorization.

FYI, I share here the same screenshot posted in the MAL API Discord forum, in case it helps.

P.D. Juts like I mentioned in the forum, you can ignore the trailing &grant_type=&22authorization_code%22 in the picture. That was a test modified manually by me. The real data sent in the payload actually ends with &grant_type=authorization_code