Important: the Google+ API no longer exists. Google+ shut down for consumers in April 2019 and the Google+ (Plus) APIs were decommissioned in March 2019. Any tutorial that calls
plus.google.comendpoints orgdatacontacts feeds is dead. This guide has been rewritten for the supported approach.
The modern way to add "Sign in with Google" to a Django app is OAuth 2.0 through Google Identity Services. You do not call the old Google+ API; instead you register an OAuth client in the Google Cloud Console and let a maintained library handle the redirect flow, token exchange, and user provisioning. The two libraries we recommend are django-allauth (batteries-included social login, accounts, and admin integration) and Authlib (a lightweight OAuth client when you want to own the flow). Both work with current Django 4.2 LTS and Django 5.x.
What changed: Google+ vs. Google OAuth 2.0
The old approach hit Google+ endpoints (/plus/v1/...) and the Contacts GData API to pull a profile and a friends list. None of that is reachable anymore:
- Google+ API β decommissioned March 2019.
- Google+ Sign-In β replaced by Google Identity Services / OAuth 2.0.
- Contacts GData feeds (
gdata.contacts) β retired; the People API exists but requires sensitive scopes and Google verification, and is rarely what a login feature needs.
For authentication you only need a verified identity: the user's Google account, their email, and basic profile (name, picture). The OpenID Connect scopes openid, email, and profile cover this without any restricted-scope review.
Step 1: Create OAuth credentials in Google Cloud Console
Before writing any Django code, register your application with Google:
Open the Google Cloud Console and create (or select) a project.
Go to APIs & Services -> OAuth consent screen, choose External, and fill in the app name, support email, and authorised domains. Add the scopes
openid,email, andprofile.Go to APIs & Services -> Credentials -> Create Credentials -> OAuth client ID, and pick Web application.
Under Authorised redirect URIs, add the callback URL your library expects. For django-allauth on local dev that is:
http://127.0.0.1:8000/accounts/google/login/callback/Save, then copy the Client ID and Client secret. Keep the secret out of source control (use environment variables).
Option A: django-allauth (recommended for most apps)
django-allauth is the most widely used social-auth package for Django. It handles the redirect flow, token exchange, account linking, email verification, and even renders a login page for you. Install it with the social-account extra:
pip install "django-allauth[socialaccount]"Add the required apps to INSTALLED_APPS. allauth depends on django.contrib.sites, so make sure that is present and set a SITE_ID:
# settings.py
INSTALLED_APPS = [
# ...
"django.contrib.auth",
"django.contrib.messages",
"django.contrib.sites", # required by allauth
"allauth",
"allauth.account",
"allauth.socialaccount",
"allauth.socialaccount.providers.google",
]
SITE_ID = 1
AUTHENTICATION_BACKENDS = [
# Needed to log in by username in Django admin
"django.contrib.auth.backends.ModelBackend",
# allauth-specific authentication methods, such as login by email
"allauth.account.auth_backends.AuthenticationBackend",
]Since version 0.56 (2023), allauth requires its account middleware and the request template context processor:
# settings.py
MIDDLEWARE = [
"django.contrib.sessions.middleware.SessionMiddleware",
"django.middleware.common.CommonMiddleware",
"django.middleware.csrf.CsrfViewMiddleware",
"django.contrib.auth.middleware.AuthenticationMiddleware",
"django.contrib.messages.middleware.MessageMiddleware",
# Required by allauth:
"allauth.account.middleware.AccountMiddleware",
]
TEMPLATES = [
{
"BACKEND": "django.template.backends.django.DjangoTemplates",
"APP_DIRS": True,
"OPTIONS": {
"context_processors": [
# ...
"django.template.context_processors.request", # required by allauth
],
},
},
]Configure the Google provider. You can list the client credentials directly in settings (read them from the environment), which avoids creating a SocialApp row in the admin:
# settings.py
import os
SOCIALACCOUNT_PROVIDERS = {
"google": {
"APPS": [
{
"client_id": os.environ["GOOGLE_CLIENT_ID"],
"secret": os.environ["GOOGLE_CLIENT_SECRET"],
"key": "",
},
],
"SCOPE": ["openid", "email", "profile"],
"AUTH_PARAMS": {"access_type": "online"},
# Recommended for public web clients:
"OAUTH_PKCE_ENABLED": True,
}
}Wire up the URLs and run migrations:
# project/urls.py
from django.urls import include, path
urlpatterns = [
# ...
path("accounts/", include("allauth.urls")),
]python manage.py migrateNow add a login link in any template. allauth provides the account_login view, and the provider login URL handles the Google redirect:
{% load socialaccount %}
<a href="{% provider_login_url 'google' %}">Sign in with Google</a>When a user clicks the link, allauth redirects to Google, handles the callback at /accounts/google/login/callback/, exchanges the authorization code for tokens, creates or links a Django User, logs them in, and stores the Google profile in a SocialAccount record. No manual token handling required.
Option B: Authlib (lightweight, when you own the flow)
If you do not want a full account framework and prefer to control the OAuth flow yourself, Authlib is a clean, well-maintained OAuth client. It works with Google's OpenID Connect discovery document, so you do not hard-code endpoints.
pip install authlib# auth/google.py
import os
from authlib.integrations.django_client import OAuth
oauth = OAuth()
oauth.register(
name="google",
client_id=os.environ["GOOGLE_CLIENT_ID"],
client_secret=os.environ["GOOGLE_CLIENT_SECRET"],
server_metadata_url="https://accounts.google.com/.well-known/openid-configuration",
client_kwargs={"scope": "openid email profile"},
)# auth/views.py
from django.contrib.auth import get_user_model, login
from django.shortcuts import redirect
from django.urls import reverse
from .google import oauth
User = get_user_model()
def google_login(request):
redirect_uri = request.build_absolute_uri(reverse("google_callback"))
return oauth.google.authorize_redirect(request, redirect_uri)
def google_callback(request):
token = oauth.google.authorize_access_token(request)
# OpenID Connect returns a verified ID token with the user's claims.
info = token["userinfo"]
user, _ = User.objects.get_or_create(
email=info["email"],
defaults={"username": info["email"], "first_name": info.get("given_name", "")},
)
login(request, user)
return redirect("/")# project/urls.py
from django.urls import path
from auth import views
urlpatterns = [
# ...
path("login/google/", views.google_login, name="google_login"),
path("login/google/callback/", views.google_callback, name="google_callback"),
]With Authlib, register http://127.0.0.1:8000/login/google/callback/ as the authorised redirect URI in the Google Cloud Console to match the reverse("google_callback") path above. Because the flow uses OpenID Connect, the verified profile claims arrive inside token["userinfo"] and you do not need a separate userinfo request.
django-allauth or Authlib: which to choose?
- Choose django-allauth if you want a complete account system out of the box: login/signup pages, email verification, multiple providers, account linking, and admin management. It is the right default for most product apps.
- Choose Authlib if you only need the Google OAuth handshake, want minimal dependencies, or are adding Google login to an existing custom auth setup or a DRF API.
If you are building a Django REST Framework backend, pair either library with token or JWT issuance after the OAuth callback. See our guide on API development with Django REST Framework for the API side, and creating a custom user model so your User can store the Google-derived fields cleanly from day one.
Security and production notes
- Never commit your client secret. Load
GOOGLE_CLIENT_IDandGOOGLE_CLIENT_SECRETfrom environment variables or a secrets manager. - Use HTTPS in production and register the exact
https://redirect URI; Google rejects mismatched URIs. - Keep scopes minimal.
openid email profileneeds no restricted-scope review; requesting Gmail, Drive, or Contacts triggers Google's verification process. - Publish your OAuth consent screen before going live, otherwise only test users can sign in.
- Enable PKCE for the authorization-code flow (allauth:
OAUTH_PKCE_ENABLED).
Frequently asked questions
Is the Google+ API still available?
No. The Google+ APIs were decommissioned in March 2019 and Google+ shut down for consumers in April 2019. Endpoints under plus.google.com and the old Contacts GData feeds no longer respond. Any integration that depended on them must migrate to Google Identity Services and OAuth 2.0.
Which library should I use for Google login in Django?
Use django-allauth for a full, batteries-included social-login and account system (login pages, email verification, account linking, admin). Use Authlib when you want a lightweight OAuth client and prefer to own the flow yourself, for example in a custom auth setup or a DRF API. Both support Django 4.2 LTS and 5.x.
What OAuth scopes do I need for Google sign-in?
For authentication you only need openid, email, and profile. These are non-sensitive and do not require Google's restricted-scope verification. Request additional scopes (Gmail, Drive, Contacts) only if a feature truly needs them, as they trigger a verification review.
How do I migrate an old Google+ login to OAuth 2.0?
Replace the deprecated Google+ calls with django-allauth or Authlib, create a fresh OAuth client ID in the Google Cloud Console, set the authorised redirect URI to your new callback path, and request openid email profile. Match existing users by their verified email so accounts created under the old flow continue to work.
Does this work with Django 4.2 and Django 5.x?
Yes. The setup shown here targets current Django (4.2 LTS and 5.x) and current library APIs, including allauth's required AccountMiddleware (added in allauth 0.56).
Need help with Google login or Django auth?
MicroPyramid has built and maintained Django applications for startups and enterprises for 12+ years across 50+ projects, including OAuth 2.0 single sign-on, custom user models, and secure API authentication. If you want a hand migrating a legacy social login or wiring up Sign in with Google correctly, explore our Django development services.