title: How to setup python social auth for web app and for mobile app?
body: <p>We have</p>
  <ol>
  <li><p>An existing Django <strong>backend</strong> with <a href="https://python-social-auth.readthedocs.io/en/latest/" rel="nofollow noreferrer">Python social auth</a> for signing in with Google, providing web-based application and an API for the mobile app.</p>
  </li>
  <li><p>An iOS <strong>mobile app</strong> with <a href="https://developers.google.com/identity/sign-in/ios/" rel="nofollow noreferrer">GoogleSignIn pod</a>.</p>
  </li>
  </ol>
  <p>Now we would like to allow mobile app users to sign in with Google inside the app, and then authenticate them on the backend, so that they can access their personal data via the app.</p>
  <p>So my idea of the algorithm is:</p>
  <ol>
  <li><p><strong>App</strong> uses the GoogleSignIn and finally receives <code>access_token</code>.</p>
  </li>
  <li><p><strong>App</strong> sends this <code>access_token</code> to the <strong>Backend</strong>.</p>
  </li>
  <li><p><strong>Backend</strong> verifies this <code>access_token</code>, fetches/creates the user, returns some <code>sessionid</code> to the <strong>App</strong>.</p>
  </li>
  <li><p><strong>App</strong> uses this <code>sessionid</code> for further requests.</p>
  </li>
  </ol>
  <p>The problem is with the third step: token verification. I found two ways of verifying:</p>
  <h2>1. Python social auth flow</h2>
  <p>As described in the <a href="https://python-social-auth.readthedocs.io/en/latest/use_cases.html#signup-by-oauth-access-token" rel="nofollow noreferrer">docs</a>:</p>
  <pre class="lang-py prettyprint-override"><code>token = request.GET.get('access_token')
  user = request.backend.do_auth(token)
  if user:
      login(request, user)
      return 'OK'
  else:
      return 'ERROR'
  </code></pre>
  <p>This would be a preferred flow, since it already has all the required steps and is working perfectly with the web app (like, accounts creation, defaults for newly created users, analytics collection, etc.).</p>
  <p>But the problem is that the backend and the app use different CLIENT_IDs for the auth. This is due to the limitations in the Google Developers Console: when creating credentials, you need to select whether it will be a web app or an iOS app, and it cannot be both.</p>
  <p>I tried to use different client ids (then backend cannot verify), tried to use web id inside the app (then the pod does not work), and tried to use app id inside the web (then the backend cannot verify again).</p>
  <h2>2. Google API Client Library</h2>
  <p>Another option is to utilize the way from the <a href="https://developers.google.com/identity/sign-in/ios/backend-auth" rel="nofollow noreferrer">Google Sign-In for iOS documentation</a>:</p>
  <pre class="lang-py prettyprint-override"><code>from google.oauth2 import id_token
  from google.auth.transport import requests
  
  try:
      idinfo = id_token.verify_oauth2_token(token, requests.Request(), CLIENT_ID)
      userid = idinfo['sub']
  except ValueError:
      # Invalid token
      pass
  </code></pre>
  <p>It worked, but here we're missing all the pipeline provided by social auth (e.g. we need to create a user somehow), and I could not find a proper way of starting the pipeline from the middle, and I'm afraid it would be quite fragile and bug-prone code.</p>
  <p>Another problem with this solution is that in reality we also have Signed in with Apple and Sign in with Facebook, and this solution will demand ad-hoc coding for each of these backends, which also bring more mess and unreliability.</p>
  <h2>3. Webview</h2>
  <p>Third option would be not to use SDKs in the Swift and just use a web view with the web application, as in the browser.</p>
  <p>This solves the problem with the pipeline and client ids.</p>
  <p>But it doesn't look native, and some users may suspect phishing attempts (how does it differ from a malicious app trying to steal Google identity by crafting the same-looking form?). Also, I'm not sure it will play nicely with the accounts configured on the device. And it also will require us to open a browser even for signing in with Apple, which looks somewhat awkward. And we're not sure such an app will pass the review.</p>
  <p>But, maybe, these all are minor concerns?</p>
  <h2>⁂</h2>
  <p>So, what do you think? Is there a fourth option? Or maybe improvements to the options above? How is it solved in your app?</p>