Django-allauth: Add support for Google ID Token Auth

[lukeburden]

I've been using the current GoogleProvider for several years, and it's performed well for both web and API usage. It can happily resolve tokens from both the OAuth2 flow as well as the various mobile SDKs older get-token functions, letting it serve both web and API functions pretty well.

However, at some point Google changed their permissions to require the "contacts" scope in order to provide an access token that will work with the current GoogleProvider. Not a show-stopper, but it's definitely a bit of a turn-off for end-users to give this permission, especially when the app in question does not need it.

Now, Google sign-in has moved along a fair bit, and now provides some javascript to handle the auth flow for the web. This produces a JWT ID Token which needs to be passed along to your backend which can verify the token locally or hit a tokeninfo endpoint for account data. Similarly on the mobile SDK side, there are new calls to make, without the contacts permission, to get an equivalent JWT ID token. Some info here: https://developers.google.com/identity/sign-in/android/migration-guide

My current approach (working, in production) is to accept an extra parameter, "id_token", and if it is present my subclassed GoogleProvider automatically hits the tokeninfo endpoint rather than the profile URL. This is a feasible approach for me, as the account IDs returned by the tokeninfo endpoint seem to correspond to those from the equivalent call to the profile url - so as we upgrade our clients they should continue to directly access their existing accounts.

How do you see this fitting into this library?

Regards,

L

[niravhjoshi]

My 👍 to Luke's request as most of android and iOS apps are relying on social logins and with Django as API backend. Is there way that if google is my oauth provider i can connect /create user /session using Google auth and it does save Auth_token and refresh_token in DB "Social Token". Now using django-allauth can we use that auth_token as Authorization Header for subsequent api request and upon expiring auth_token it should be automatic refresh so we don't have to much dig deeper into session when we are working on front end like Android and iOS.

Can you please provide any update on this.

[pennersr]

@lukeburden Could you please point me to a commit of the changes you made?

[lukeburden]

@pennersr I ended up subclassing the Google provider locally in a project, not in an allauth fork, so will need to extract it if you'd like a PR.

But before I do that, I'd need some design direction; where should this fit into the Google provider, in your opinion? Most provider and some adapter methods vary if it's in doing ID token auth, so there are a lot of if/else chunks, which is unfortunate. But we're forced to keep this all within the one Google provider "namespace" if we want users who previously auth'd with an access token to find their account when they auth with an ID token.

I found it hard to pass the fact that an id_token was supplied from the entry point through to the provider's logic, on anything other than the request. This felt hacky.

How would you recommend cleanly getting the fact that we're dealing with an ID token through to the provider/adapter layer, such that it can customise it's behaviour appropriately?

Happy to submit a PR if you can tell me what you're thinking. Here's an example of the adapter I ended up using:

class GoogleDualAdapter(GoogleOAuth2Adapter):

    provider_id = GoogleDualProvider.id
    tokeninfo_url = 'https://www.googleapis.com/oauth2/v3/tokeninfo'

    def complete_login(self, request, app, token, **kwargs):
        provider = self.get_provider()
        if provider.id_token_mode:
            resp = requests.get(
                self.tokeninfo_url,
                params={'id_token': token.token}
            )
        else:
            resp = requests.get(
                self.profile_url,
                params={
                    'access_token': token.token,
                    'alt': 'json'
                }
            )
        resp.raise_for_status()
        extra_data = resp.json()
        return provider.sociallogin_from_response(
            request, extra_data
        )

Perhaps by tagging the token, or passing a kwarg all the way through to the complete_login method?

[gonzafirewall]

I made this custom change to fit my django rest auth need may be this need to be expanded to support the actual access_token implementation.
https://medium.com/@gonzafirewall/google-oauth2-and-django-rest-auth-92b0d8f70575
Maybe this is useful.

[moonstruck]

@gonzafirewall Do you consider sending a pull request?