fix(google): get_avatar_url sometimes returns None

[arowley-ai]

Summary

The Google provider is configured to rely on data decoded from the JWT for populating the user details. This results in a situation where, for certain users, get_avatar_url returns None because the photo URL field is not always included in the JWT. An alternative approach is to hit the userinfo API, which consistently provides the user data across all accounts. The existing default scopes are sufficient to query this endpoint.

Detail

The provider is currently configured to rely on data decoded from the JWT used in the login process for populating the user photo URL and other user attributes.

User photos in Google

Google seems to maintain two types of user photos which we will call "public" and "private" even though both are technically publicly accessible given you have the right URL:

• Public user photo URLs contain ~100 characters. I found that my personal Gmail account had a public photo URL.
• Private user photo URLs are much longer and contain ~1000 characters. I think this is done to make them harder to discover. I found that my paid-for G Suite account had a private photo URL.

JWT return values

I was able to establish via the Google OAuth 2 playground that the information encoded in a JWT differs based on the type of photo URL that an account has, such that:

• For public user photos, the returned JWT includes the user photo URL.
• For private user photos, the returned JWT does not include the user photo URL. Presumably, that is done to keep the overall size of the JWT down.

Therefore, under the current approach, the user photo url is sometimes not populated into the backend as part of the "Extra data" json. Whether it is populated or not depends on what type of profile photo the user has. This is despite the fact that the default scopes are sufficient to access the photo url regardless of whether it is public or private. The relevant endpoint is just never used as part of the current approach.

Alternative approach to accessing user details

Given that the current default scopes for the Google provider are sufficient to actually access the photo URL of each user, doing so only requires hitting the relevant "user.info" endpoint, which is "https://www.googleapis.com/oauth2/v2/userinfo." My view is that any field that is reasonably needed by django-allauth can be gained by hitting this endpoint and so I have commented out the existing code entirely and all user details are now gained via this endpoint rather than decoding the JWT.

Custom scopes

If an existing codebase has used custom scopes, this should not be an issue. From what I can tell any scope at all is sufficient to query the userinfo endpoint, but what is returned will vary depending on whether you included email and profile scopes which are included by default.

Conclusion

This pull request changes the methodology used by the google provider to grab the user details to use the relevant endpoint rather than simply decoding the JWT. This was done in order to fix inconsistently populated user photo URLs. I welcome any debate or feedback on this issue that is needed before this PR can be merged.

Acknowledgement

Thank you so much for maintaining and providing such great open source software.

[pennersr]

Thanks for tracking this issue down and the detailed analysis. I would expect projects that are dependent on the avatar URL to be in the minority. That, and the fact that fetching userinfo introduces overhead as it results in an additional roundtrip, I would prefer to have this behavior configurable using a setting that is default off. How about:

SOCIALACCOUNT_PROVIDERS = {
    "google": {
        "FETCH_USERINFO": True,
        ...

[arowley-ai]

I would prefer to have this behavior configurable using a setting that is default off.

Thanks @pennersr for the reply. I'm ok with adding a setting that enables this.

Two questions, then:

1. If the setting is on but the original JWT includes the avatar URL should we skip the call to getinfo? I would think yes, since at that point it's unnecessary.
2. If the user isn't aware of this setting and has a situation where get_avatar_url returns None would you want any kind of warning that indicates that they should enable this setting in order to return the avatar URL properly?

Edit: Might be easier for you to just grok where I've now gotten to, and see if that's what you had in mind?

[coveralls]

coverage: 95.796% (-0.02%) from 95.819%
when pulling 5e58e75 on arowley-ai:main
into 4982485 on pennersr:main.

[pennersr]

Thanks! Merged via 89ebcc5