Autenticación con Google en Django

Proyecto educativo que muestra, de principio a fin, cómo integrar Google OpenID Connect con el sistema de usuarios y sesiones de Django mediante Authlib. Incluye una página pública de acceso, un dashboard protegido, cierre de sesión seguro, Django Admin, tests, Docker y configuración mediante variables de entorno.

• El recorrido URL → vista → autenticación → template → respuesta.
• Cómo login_required protege una vista y cómo Django conserva la sesión.
• Cómo Google autentica al visitante y Django crea o reutiliza su usuario local.
• Por qué OAuth usa una URL de callback y un valor state.
• Cómo aislar secretos, ejecutar migraciones, usar el Admin y probar código sin llamar a Google.

• Python 3.12 o superior y Django 6.0.
• Authlib y Requests para Google OpenID Connect.
• SQLite para mantener el laboratorio sencillo.
• HTML, CSS, Docker y GitHub Actions.

Requisitos: Git y Python 3.12 o superior.

git clone https://github.com/Blandskron/auth-google-django.git
cd auth-google-django/djago_auth
python -m venv .venv

Activa el entorno:

# Linux/macOS
source .venv/bin/activate

# Windows PowerShell
.venv\Scripts\Activate.ps1

Instala y prepara la base de datos:

python -m pip install -r requirements.txt
python manage.py migrate
python manage.py runserver

Sin credenciales de Google el proyecto inicia igualmente y explica qué configuración falta. Visita http://127.0.0.1:8000/; un usuario anónimo será enviado a /login/.

En Google Cloud Console crea un cliente OAuth 2.0 de tipo Aplicación web. Registra exactamente:

• Orígenes: http://127.0.0.1:8000 y, si lo usarás, http://localhost:8000.
• Callbacks: http://127.0.0.1:8000/auth/google/callback/ y, si corresponde, http://localhost:8000/auth/google/callback/.

Define las variables antes de iniciar Django. .env.example sirve como catálogo; Django no carga archivos .env automáticamente en la ejecución local.

# Linux/macOS
export GOOGLE_CLIENT_ID="tu-id.apps.googleusercontent.com"
export GOOGLE_CLIENT_SECRET="tu-secreto"
export OAUTH_ALLOW_INSECURE_HTTP=True

# Windows PowerShell
$env:GOOGLE_CLIENT_ID="tu-id.apps.googleusercontent.com"
$env:GOOGLE_CLIENT_SECRET="tu-secreto"
$env:OAUTH_ALLOW_INSECURE_HTTP="True"

OAUTH_ALLOW_INSECURE_HTTP=True permite HTTP únicamente para este laboratorio local. En producción se debe usar HTTPS, DEBUG=False, una SECRET_KEY fuerte y hosts explícitos.

Variables reconocidas:

El Admin está en http://127.0.0.1:8000/admin/. Allí puedes explorar usuarios, grupos y permisos incorporados por Django.

La opción interactiva es:

python manage.py createsuperuser

Para un laboratorio automatizado puedes usar el comando idempotente del proyecto:

# Linux/macOS
export DJANGO_SUPERUSER_USERNAME=admin
export DJANGO_SUPERUSER_EMAIL=admin@example.com
export DJANGO_SUPERUSER_PASSWORD='elige-una-clave-local'
python manage.py create_educational_superuser

En PowerShell usa $env:NOMBRE="valor". Si el nombre de usuario ya existe, el comando no crea duplicados ni cambia su contraseña.

Requisitos: Docker Engine o Docker Desktop con Compose v2.

cp .env.example .env       # En PowerShell: Copy-Item .env.example .env
# Edita .env y reemplaza credenciales y contraseñas de ejemplo.
docker compose up --build

El contenedor aplica migraciones al iniciar y, cuando DJANGO_CREATE_SUPERUSER=True, ejecuta el comando idempotente de superusuario. SQLite se guarda en el volumen sqlite_data.

docker compose down                 # detener y conservar datos
docker compose down --volumes       # reiniciar el laboratorio borrando su volumen

El segundo comando elimina los datos locales del laboratorio; úsalo solo si realmente quieres comenzar de cero.

Las pruebas simulan las respuestas de Authlib: no requieren internet ni credenciales reales.

cd djago_auth
python manage.py check
python manage.py makemigrations --check --dry-run
python manage.py test --verbosity 2

Para Docker:

docker compose config
docker compose build

GitHub Actions ejecuta las tres comprobaciones de Django en cada push y pull request.

auth-google-django/
├── .github/workflows/django.yml       # integración continua
├── docs/                              # arquitectura, estado y ayuda
├── djago_auth/
│   ├── autentication/                 # URLs, vistas, tests y comandos
│   ├── djago_auth/                    # settings y URL raíz
│   ├── static/css/styles.css
│   ├── templates/                     # base, login y dashboard
│   ├── manage.py
│   └── requirements.txt
├── .env.example                       # variables sin secretos reales
├── compose.yaml
├── docker-entrypoint.sh
└── Dockerfile

El nombre histórico autentication se conserva para no romper imports y migraciones. La app no define modelos propios: reutiliza el modelo User, las sesiones, los grupos y permisos incluidos en Django.

GET / → dashboard_page → @login_required
                         └─ anónimo → GET /login/
GET /login/google/ → Google → GET /auth/google/callback/
callback → valida token → crea/reutiliza User → django_login() → GET /
POST /logout/ + CSRF → django_logout() → GET /login/

Para cambiar una ruta revisa autentication/urls.py; para modificar el comportamiento, views.py; para la interfaz, templates/ y static/; para variables globales, djago_auth/settings.py.

• Arquitectura y conceptos
• Solución de problemas
• Estado y próximos pasos
• Reglas para agentes y colaboradores

Este repositorio enseña desarrollo local: runserver, SQLite y el valor por defecto de SECRET_KEY no son una arquitectura de producción. Con DEBUG=False, los settings activan redirección HTTPS, cookies seguras y HSTS; ajusta SECURE_HSTS_SECONDS con cuidado para tu dominio. Antes de desplegar, usa una clave secreta externa y fuerte, hosts explícitos, un servidor WSGI/ASGI apropiado, almacenamiento persistente gestionado y ejecuta python manage.py check --deploy con los settings finales.