Geeting OAuth token from redirect URL parameters after '#'
Hello,
As per Zendesk documentation for OAuth token (Using OAuth authentication with your application – Zendesk help), when requesting token directly, the token is included in the redirect URL as follows:
{redirect_url}#access_token=gErypPlm4dOVgGRvA1ZzMH5MQ3nLo8bo&token_type=bearerWhen trying to get the token from the URL, in a Python-based backend with Flask request, the request object does not capture any argument from above because the hash fragment in the URL (anything after a '#' character) is not passed by the browser to the request object as it is the case with all parameters that follow standard '?'.
Anyone idea on how get the token from the URL when the callback function is a backend Python function, as opposed to a JS function?
To Zendesk development team: is there any reason that the standard '?' character is not used and instead '#' (hash fragments) are used to form this URL redirect?
Thank you
-
FYI, we switched to 2-step process where we get a code first, which comes as a parameter after '?' and then calling the token API to get the token which returns a JSON object. This solved the token request problem though the one-step token request parsing still remains unresolved.
-
Hey H M,
The reasoning behind the redirect url variation ('?' vs '#') is because with the Authorization Code grant flow your application is defining the request, handling the user access decision and Zendesk's redirect response. We're also generating an authorization code then exchanging it for a token. For this reason, we see the '?' in the redirect url because we're querying for the response (the authorization code) based off of all of the parameters previously defined in the request. We need the request to hit server side to generate the authorization code.
With the Implicit grant flow, since we're not defining all of the parameters or setting the scope, all we're requesting is the token outright. The only question is whether or not the user grants access. Therefore, we see the '#' character for the path with the access token or error. We're using '#' here because this token generation happens on the client side.
Hope this helps!
Please sign in to leave a comment.
2 Comments