oauth2l says result of `oauth2l fetch --scope userinfo.email` is invalid

[nfelt]

The following behavior is unexpected and contrary to the README's example

$ oauth2l info --token $(oauth2l fetch --scope userinfo.email)
{
 "error_description": "Invalid Value"
}

I'm signed in using gcloud auth application-default login.

This is also the case for scopes email and openid. The token generated is considered valid if I fully specify the scope as shown:

$ oauth2l info --token $(oauth2l fetch --scope https://www.googleapis.com/auth/userinfo.email)
{
 ...
 "scope": "https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/cloud-platform https://www.googleapis.com/auth/accounts.reauth openid",
 ...
}

Glancing through the issue tracker, this looks related to https://github.com/google/oauth2l/issues/71, but I'm using the oauth2l downloaded from https://storage.googleapis.com/oauth2l/1.0.2/linux_amd64.tgz so it should include the change fixing that issue.

[andyrzhao]

Hi Nick, I took a quick look and it appears to be due to the fact that "userinfo.email" is not accepted by the oauth endpoint as a valid scope. The following 2 alternatives appear to work:

--scope email --scope https://www.googleapis.com/auth/userinfo.email

There is a lot of variation in the documentations for openid, so I need to spend some time to make sure all cases are handled correctly, and update the "regex" as appropriate.

Thanks! Andy

[nfelt]

Thanks for the quick response. However, email doesn't work for me:

$  oauth2l info --token $(oauth2l fetch --scope email)
{
 "error_description": "Invalid Value"
}

(I agree the fully qualified one does work, so there is at least a workaround there.)

[andyrzhao]

Can you let me know what error you get when you run "oauth2l fetch --scope email"? That should have been fixed by https://github.com/google/oauth2l/issues/71 (which broke --scope userinfo.email apparently) The command works fine for me using https://storage.googleapis.com/oauth2l/1.0.2/linux_amd64.tgz

Side note, I believe open ID scopes only work when using "client id" as your json credentials as opposed to "service account". That command should prompt you to follow a link to authenticate, and enter a verification code.

[andyrzhao]

Also, since the command for 3-legged OAuth is interactive, it would not work properly if you wrap the execution in oauth2l info --token $(...), UNLESS the oauth token has been previously cached for the same scope. This could be the reason the wrapped command is not working for you.

[nfelt]

Okay, so I was trying to reproduce this and no longer can :/ I'm certain that I was seeing the error above (in my previous comment that was a direct copy from my terminal) and also that I was using that most recent version of the prebuilt binary. But now rerunning that command works, and in fact the info call succeeds no matter what I pass to --scope including --scope foo or --scope userinfo.email.

I know that earlier I was seeing behavior that varied depending on the --scope argument and I thought that at the time I confirmed that the command was always printing out something that looked like an access token string (ya29...), but at this point my best guess is that you're right and somehow local or cached state (which I have since cleared in the course of doing other testing) was triggering an interactive prompt for some values of --scope and causing the info call to fail.

Anyway, if I can reproduce something again I'll follow up but for now, sorry for the noise.

[andyrzhao]

No problem - I do believe you discovered a corner case though:

"oauth2l fetch --scope userinfo.email" does not work for me, so if it is supposed to work, I'll fix this when I get the chance. Thanks!

[nfelt]

Okay, strange because that does work for me now, but as you said maybe it's a matter of which credentials are active? At any rate, if this issue is still useful for tracking feel free to re-open it.