ramosbugs
Change the scopes for the google example
The google integration example currently uses a couple of exotic scopes. I changed those scopes to make it easier to try the example. The scopes I chose are likely to be needed for most integrations that use Google OAuth for authentication. Those scope are the following:
- openid
- https://www.googleapis.com/auth/userinfo.email
FWIW, this can be cut down to only the openid scope if you think that makes better sense for the example.
Hey, thanks for the PR. I'd prefer not to add openid to the examples in this crate since the openidconnect crate is specifically intended for this use case and already has a Google example: https://github.com/ramosbugs/openidconnect-rs/blob/c67ffe94af24b65dbb596a68b6623baecf080eb8/examples/google.rs#L155-L156 (that crate always adds the openid scope; it doesn't need to be requested explicitly by apps)
The use case for this crate over openidconnect would be for apps that primarily need to make Google API requests on behalf of a user, which is the original purpose of OAuth2. OpenID Connect adds an identity layer on top of OAuth2 that's better designed for authenticating users to log in to third party apps. See https://stackoverflow.com/questions/1087031/whats-the-difference-between-openid-and-oauth.
Thanks for the tip on the openidconnect crate. I just found and switched to that.
The email scope still seems more relevant likely to be in someone's OAuth 2.0 project permissions than the calendar one. Maybe not though.
Having said that, documenting that one needs to create a OAuth2 client id in a project with certain scopes would probably help a lot to make this examples work for folks. It took me a bit to figure out that's what was wrong.
Another option would be to create an OAuth2 client secret that is only good for http://localhost:8080 since that's what this example uses for the redirection url.
Yeah I agree. The examples should do a better job of documenting how to set up the corresponding provider to work with each example.