2
votes

I just came across a problem, where Grant, an OAuth middleware was sometimes throwing an error redirecting back from google oauth endpoint to the middleware endpoint, although the authentication was successful.

After some research i realized, that if there is no active google session in the browser (not logged in with google.com), the query string of the redirect url is properly encoded and everything is working fine.

http://localhost:1337/connect/google/callback?code=4%2FpAD2TUmE0hgckmSwkxxx&scope=openid%20email%20https://www.googleapis.com/auth/userinfo.email%20https://www.googleapis.com/auth/plus.me

But if there is already a user logged in, the code parameter of the querystring is unencoded, which is throwing an malformed_auth_token error on my oauth middleware.

http://localhost:1337/connect/google/callback?code=4/pAD2TUmE0hgckmSwkxxx&scope=openid%20email%20https://www.googleapis.com/auth/userinfo.email%20https://www.googleapis.com/auth/plus.me

I further tested with different accounts, and every code token returned by google endpoint contained a forward slash as 2nd character.

So i would like to know, if google is bugged and incorrectly returning unencoded parameters, or if the oauth middleware should handle both cases, encoded and unencoded parameters?

1

1 Answers

1
votes

Google does not have a bug.

It is OK to include slash characters in query pamarameters. Slashes in query parameters do not need to be encoded. Apache has a directive that you must enable to support query parameters with encoded slash characters (AllowEncodedSlashes). Your backend will need to handle this situation.

However, I do find your example strange where Google sometimes encodes slash characters in the code parameter. I know that in Google OAuth 2.0 sometimes the code parameters is meant to be copied manually into an input field to complete the OAuth flow. For this case I always see the slash character raw (not encoded). This is for the redirect_uri being redirect_uri=urn:ietf:wg:oauth:2.0:oob