Django 集成 Okta 的最佳实践：从 OIDC 协议到生产级部署

1. 项目概述：为什么 Django 开发者需要认真对待 Okta 集成

最近给一家做 SaaS 工具的客户做系统安全加固，他们内部有七八个 Django 应用，每个都自己维护一套用户表、密码策略和登录页。运维同事跟我说：“上周又有个实习生把测试环境的 admin 密码贴在了 Slack 公共频道里，我们花了三小时重置所有系统的权限。”这句话让我意识到，不是所有安全问题都出在代码漏洞上——更多时候，是身份认证体系本身太“轻”，轻到连基础的统一入口和强制多因素验证都做不到。这时候 Okta 就不是“可选项”，而是“必选项”。它本质上是一个企业级的身份中枢（Identity Hub），不是简单加个登录按钮的事。你把它看作公司数字大门的智能门禁系统：前台（Okta）统一登记所有人证件（用户生命周期）、核验指纹/人脸（MFA）、分发不同区域的门禁卡（细粒度权限），而你原来的 Django 应用只是楼里的某间办公室——它不再需要自己造锁、配钥匙、记谁来过，只管认准门禁卡开门就行。关键词Best Practices和Django在这里不是泛泛而谈的标签，而是指代一整套落地动作：怎么让 Django 不再当“安全孤岛”，而是成为 Okta 认证生态里一个可靠、低侵入、可审计的终端节点。这和写个@login_required装饰器有本质区别——前者是声明式权限控制，后者是协议级身份委托。我见过太多团队卡在第一步：花两天时间跑通本地登录，结果上线后发现生产环境 HTTPS 证书校验失败、回调地址 302 重定向被浏览器拦截、用户邮箱字段映射错位导致全员登录 403……这些坑文档里几乎不提，但每个都足以让集成周期从半天拖到一周。所以这篇不是教你怎么 pip install，而是告诉你：当 Okta 控制台弹出那个“Application created successfully”提示时，真正的工程才刚开始。

2. 整体设计思路与方案选型解析

2.1 为什么放弃原生 OIDC 手动实现，而选择 django-okta-auth 库

Okta 本身是标准 OIDC（OpenID Connect）提供商，理论上你可以直接用 Python 的requests库调用它的/authorize和/token端点，自己解析 JWT、校验签名、提取用户信息。我试过——第一版代码写了 387 行，覆盖了授权码流程、PKCE 挑战、token 刷新、JWT 解析、scope 校验、错误重试。但第三天就遇到个致命问题：Okta 的 JWKS 密钥轮换机制（key rotation）没在文档显眼位置说明，我们的 token 验证服务用了旧密钥，导致凌晨三点批量登录失败。手动实现看似“可控”，实则把所有协议细节、安全边界、异常分支都甩给了开发者。而django-okta-auth这个库的价值，恰恰在于它把 Okta 特定的最佳实践固化进了封装层。比如它默认启用 PKCE（Proof Key for Code Exchange），这是现代 OAuth 2.1 强制要求的防授权码劫持机制；它自动处理 JWKS 密钥缓存与刷新，避免硬编码密钥；它把 Okta 的preferred_username字段（通常是邮箱）和 Django 的User.username字段做了安全映射，防止用户名冲突。更重要的是，这个库的维护者 Six Feet Up 是 Okta 官方认证合作伙伴，他们的 GitHub Issues 里全是真实生产环境踩过的坑，比如 “Okta 返回的email_verified字段为 false 时如何跳过 Django 的邮箱激活检查”——这种细节，官方 SDK 文档根本不会写。所以选型逻辑很清晰：用成熟封装对抗协议复杂性，用社区经验替代文档盲区。当然，它不是银弹。我们后续必须修改它的用户同步逻辑，因为客户要求员工离职时 Okta 删除用户，Django 端要软删除而非硬删（保留历史订单关联）。但这属于业务适配，不是协议攻坚。

2.2 架构分层：明确 Django 在 Okta 生态中的角色边界

很多团队集成失败，根源在于角色认知错位。他们试图让 Django 同时扮演三个角色：身份提供者（IdP）、资源服务器（RS）、应用前端（Client）。这是危险的。Okta 集成的本质是职责剥离——Django 必须退守为纯粹的资源服务器。具体分层如下：

• Okta 层（IdP）：负责所有身份核心能力。包括：用户注册/注销生命周期管理（SCIM 同步）、多因素认证（SMS/邮件/Okta Verify App）、自定义登录页面、风险策略（异地登录触发 MFA）、会话管理（单点登出 SLO）。这一层你绝不该碰代码，只通过 Okta Admin UI 配置。

• Django 层（RS）：只做三件事：1）接收 Okta 发来的 ID Token（含用户身份声明），2）校验 Token 签名和有效期，3）根据声明创建/更新本地 User 对象，并建立 session。它不生成 token，不存储密码，不处理 MFA 流程。所有权限判断（如user.is_staff）必须基于 Okta 返回的groups声明或自定义 claim，而不是 Django 数据库字段。

• 前端层（Client）：这是最容易被忽视的一环。Django 模板里的登录按钮，不能直接指向/login/，而必须重定向到 Okta 的/authorize端点。我们用django-okta-auth提供的{% url 'okta_login' %}模板标签，它会动态拼接state参数（防 CSRF）和code_challenge（PKCE）。前端 JS 代码里禁止出现 Okta 的client_id或org_url，这些必须由后端注入，否则会被爬虫抓取。

这种分层带来的直接好处是：当 Okta 因合规要求升级 TLS 版本或更换密钥时，Django 代码零修改；当客户要求增加 Azure AD 作为备用 IdP 时，你只需新增一个django-allauth的 provider 配置，核心认证逻辑不变。我见过最惨的案例是某团队把 Okta 的 access_token 存进 Django Session，然后用它去调用 Okta API 获取用户信息——这完全违背了无状态原则，一旦 token 过期，整个登录流程就崩了。

2.3 关键决策：为什么坚持使用 Authorization Code Flow 而非 Implicit Flow

Okta 文档里两种流程都支持，但 Implicit Flow（隐式流）已被 OAuth 2.1 废弃，且存在严重安全隐患：access_token 直接通过 URL Fragment 传回前端，可能被浏览器历史记录、Referer 头、代理服务器日志泄露。Authorization Code Flow（授权码流）虽然步骤多一步（需后端交换 code 为 token），但安全性高得多：code 是短期有效的单次凭证，且交换过程走后端直连，token 永远不经过浏览器。django-okta-auth默认启用的就是 Code Flow，但你需要确认几个关键配置：

1. Redirect URI 必须精确匹配：Okta Admin UI 中配置的 Redirect URI（如https://app.example.com/accounts/oauth2/callback）必须和 Django 设置里的OKTA_AUTH['REDIRECT_URI']完全一致，包括协议、域名、端口、路径，绝对不能有 trailing slash。Okta 会自动在 redirect_uri 后添加/，如果你配置成https://app.example.com/callback/，它实际会调用https://app.example.com/callback//，导致 400 错误。这是文档里最隐蔽的坑。

2. PKCE 必须启用：django-okta-auth0.5+ 版本默认开启 PKCE，但你要检查settings.py中是否意外设置了OKTA_AUTH['PKCE_ENABLED'] = False。PKCE 的核心是生成code_verifier（随机字符串）和code_challenge（其 SHA256 哈希值），前者存在后端 session，后者传给 Okta。回调时 Okta 用code_verifier验证code_challenge，防止中间人截获 code 后伪造请求。没有 PKCE，Code Flow 的安全性大打折扣。

3. State 参数不可省略：state是一个随机生成的、带时间戳的字符串，存于 Django session，同时传给 Okta。Okta 在回调时原样返回state，Django 校验一致性后才继续流程。这是防 CSRF 的关键，绝不能为了“简化”而硬编码state='fixed'。

3. 核心细节解析与实操要点

3.1 Okta 控制台配置：五个必须死磕的细节

Okta Admin UI 的配置界面看似简单，但五个关键字段的微小偏差会导致整个流程静默失败。我建议你打开 Okta 控制台，跟着以下步骤逐项核对，而不是凭记忆操作：

1. Applications → Add Application → Create New App Integration

   • Platform:Web Application（不是 SPA！SPA 会禁用coderesponse type）
   • Sign-in method:OIDC - OpenID Connect
   • Why not SPA?因为 SPA 模式下 Okta 默认只允许response_type=token id_token（Implicit Flow），而我们要的是response_type=code（Authorization Code Flow）。Web Application 才支持完整的 Code Flow + PKCE。

2. General Settings → Application Login URL

   • 填写你的 Django 应用首页，如https://app.example.com/
   • Why this matters?这是 Okta 登录成功后跳转的默认地址，也是你后续配置 Single Logout URL 的基础。

3. General Settings → Redirect URIs

   • 添加你的回调地址，格式：https://app.example.com/accounts/oauth2/callback
   • 必须确保：
     • 协议为https（生产环境）或http（开发环境，仅限 localhost）
     • 域名和端口与 DjangoALLOWED_HOSTS完全一致
     • 路径结尾绝对不能有/（如callback/是错的，callback才对）
     • 如果用 Nginx 反向代理，此处填 Nginx 暴露的域名，不是 Django 的127.0.0.1:8000

4. Sign-On → OpenID Connect ID Token → Groups Claim Type

   • 选择"Groups"（不是 Expression）
   • Group filter:.*（匹配所有组）或按需填写正则，如^dev-.*$
   • Why critical?这决定了 Okta 是否在 ID Token 的groups字段中包含用户所属 Okta 组。Django 后续要用这个字段做权限控制（如user.groups.filter(name__startswith='dev-')）。如果这里没开，groups字段永远为空。

5. Sign-On → OpenID Connect ID Token → Include in ID Token

   • 勾选"Email","First Name","Last Name","Groups"
   • Why?Okta 默认只返回sub（用户唯一标识）和email。但 Django 的User模型需要first_name,last_name，groups用于权限。必须手动勾选，否则这些字段不会出现在 ID Token 的 payload 里。

提示：每次修改 Okta 配置后，务必点击右上角"Save"按钮。Okta 的 UI 有缓存，有时看起来保存了，实际没生效。最简单的验证方法：在 Okta 的API → Authorization Servers → default → Scopes页面，确认openid,profile,email,offline_access这些 scope 都已启用。如果profile没启用，first_name/last_name就不会返回。

3.2 Django 设置深度解析：每个参数背后的实战含义

OKTA_AUTH字典不是配置清单，而是 Okta 与 Django 之间的“外交协议”。每个键值对都对应一个安全契约，理解其背后意图比记住语法更重要：

OKTA_AUTH = { "ORG_URL": "https://dev-123456.okta.com", # 你的 Okta 租户根域名 "ISSUER": "https://dev-123456.okta.com/oauth2/default", # ORG_URL + /oauth2/default "CLIENT_ID": "0oaabc123def456ghi789", # Okta App 的 Client ID "CLIENT_SECRET": "AbCdEfGhIjKlMnOpQrStUvWxYz", # Okta App 的 Client Secret "SCOPES": "openid profile email offline_access", # 请求的权限范围 "REDIRECT_URI": "https://app.example.com/accounts/oauth2/callback", # 必须与 Okta 配置完全一致 "LOGIN_REDIRECT_URL": "/dashboard/", # 登录成功后跳转的 Django 内部路径 "CACHE_PREFIX": "okta", # 缓存 key 前缀，避免与其他应用冲突 "CACHE_ALIAS": "default", # 使用 Django 的 default cache backend "PUBLIC_NAMED_URLS": ("password_reset", "password_reset_done"), # 白名单命名 URL "PUBLIC_URLS": (r"^/healthz/$", r"^/metrics/$"), # 白名单正则 URL "USE_USERNAME": False, # True 时用 username 登录，False 时用 email 登录 "DISABLE_HTTPS_CHECK": False, # 仅开发环境设为 True，生产必须为 False }

• ORG_URLvsISSUER：ORG_URL是租户标识，ISSUER是 OAuth 2.0 授权服务器的唯一标识符。Okta 的ISSUER格式固定为ORG_URL + /oauth2/default。如果你用的是自定义授权服务器（Custom Authorization Server），ISSUER会是ORG_URL + /oauth2/v1/aus-xxxxx。django-okta-auth会用ISSUER去获取.well-known/openid-configuration，从而拿到jwks_uri（密钥地址）和token_endpoint（令牌交换地址）。如果ISSUER错了，第一步/.well-known/...就 404，整个流程卡死。

• CLIENT_ID和CLIENT_SECRET：这两个值在 Okta App 的Client Credentials标签页下。CLIENT_SECRET是敏感信息，绝不能硬编码在 settings.py 里。生产环境必须用环境变量：

  import os OKTA_AUTH = { "CLIENT_ID": os.environ.get("OKTA_CLIENT_ID"), "CLIENT_SECRET": os.environ.get("OKTA_CLIENT_SECRET"), # ... 其他配置 }

  并在部署时通过export OKTA_CLIENT_SECRET="xxx"注入。我见过最蠢的错误是把CLIENT_SECRET提交到 Git，导致 Okta 控制台自动禁用该 App。

• SCOPES的取舍：openid（必需）、profile（获取姓名）、email（获取邮箱）是基础。offline_access是关键——它告诉 Okta 发放refresh_token，让 Django 能在用户长时间不操作后，用 refresh_token 换新 access_token，避免用户频繁重新登录。但注意：offline_access会延长用户会话，需配合 Okta 的会话超时策略（在 Okta Admin UI → Security → Sessions 中设置）。

• PUBLIC_NAMED_URLS和PUBLIC_URLS：这是白名单机制，指定哪些 URL 不需要 Okta 认证。PUBLIC_NAMED_URLS用 Django 的name参数（如url(r'^reset/$', auth_views.PasswordResetView.as_view(), name='password_reset')），PUBLIC_URLS用正则。必须把 Django 的密码重置、健康检查、静态文件 URL 加进去，否则访问/reset/会先跳 Okta 登录页，形成死循环。

• USE_USERNAME的陷阱：当设为True时，Django 登录页的输入框 label 是 “Username”，提交后 Okta 会把username字段（Okta 用户的 login）映射到 Django 的User.username。但 Okta 的username通常是邮箱格式（如john@example.com），而 Django 的username字段最大长度为 150，且不能包含@符号（Django 3.2+ 默认校验）。所以USE_USERNAME=False（默认）更安全，此时 Okta 的email映射到User.email，User.username自动生成为okta_{sub}（sub 是 Okta 用户唯一 ID），彻底规避字符限制。

3.3 用户同步与权限映射：如何让 Okta 组变成 Django 权限

Okta 的核心价值之一是集中管理用户组（Groups），但django-okta-auth默认只创建用户，不处理组同步。这意味着 Okta 里把用户加入dev-admins组，Django 里user.is_staff还是False。我们必须手动桥接这个 gap。方案不是写个 cron job 定期拉取，而是利用 Okta 的Group Push功能，在用户属性变更时实时通知 Django。

第一步：在 Okta Admin UI → Directory → Groups → 选择你的组（如dev-admins）→Push to Apps→ 选择你的 Django App →Edit Push Rules。在这里，你定义 Okta 组成员变化时，向 Django 的某个 endpoint 发送 webhook。但django-okta-auth不提供现成的 webhook endpoint，所以我们自己写一个轻量级视图：

# views.py from django.http import JsonResponse from django.views.decorators.csrf import csrf_exempt from django.contrib.auth.models import User, Group from django.contrib.auth import get_user_model import json import logging logger = logging.getLogger(__name__) @csrf_exempt def okta_group_webhook(request): if request.method != 'POST': return JsonResponse({'error': 'Method not allowed'}, status=405) try: payload = json.loads(request.body) # Okta webhook payload 结构示例： # { # "eventType": "GROUP_PUSH_TO_APP", # "target": {"id": "00gabc123def456ghi789"}, # "data": { # "groups": [{"id": "00gxyz789...", "name": "dev-admins"}], # "user": {"id": "00uabc123...", "profile": {"login": "john@example.com"}} # } # } event_type = payload.get('eventType') if event_type != 'GROUP_PUSH_TO_APP': return JsonResponse({'status': 'ignored'}, status=200) user_login = payload['data']['user']['profile']['login'] group_names = [g['name'] for g in payload['data']['groups']] # 查找 Django 用户（用 email 匹配） User = get_user_model() try: user = User.objects.get(email=user_login) except User.DoesNotExist: logger.warning(f"User {user_login} not found in Django DB") return JsonResponse({'status': 'user_not_found'}, status=200) # 同步组：只保留 Okta 里有的组，移除不在 Okta 的组 current_groups = set(user.groups.values_list('name', flat=True)) target_groups = set(group_names) # 移除不再属于的组 for group_name in current_groups - target_groups: group = Group.objects.get(name=group_name) user.groups.remove(group) # 添加新加入的组 for group_name in target_groups - current_groups: group, _ = Group.objects.get_or_create(name=group_name) user.groups.add(group) logger.info(f"Synced groups for {user_login}: {group_names}") return JsonResponse({'status': 'success'}, status=200) except Exception as e: logger.error(f"Webhook error: {e}", exc_info=True) return JsonResponse({'error': str(e)}, status=500)

第二步：在urls.py中暴露这个 endpoint，并用强认证保护（如 IP 白名单 + 签名验证）：

# urls.py from django.urls import path from . import views urlpatterns = [ # ... 其他 URL path('webhook/okta-group-sync/', views.okta_group_webhook, name='okta_group_webhook'), ]

第三步：在 Okta 的 Push Rules 中，将 Target URL 设为https://app.example.com/webhook/okta-group-sync/，并开启"Require authentication"，用 Okta 的 API Token 或 Basic Auth 保护。这样，每当 Okta 管理员把用户加入/移出组，Django 就实时同步，user.is_staff可以通过检查user.groups.filter(name='dev-admins').exists()来判断。

注意：这个 webhook 方案比轮询高效得多，但要注意幂等性。Okta 可能因网络原因重发 webhook，所以我们的视图必须能处理重复事件（上面的代码通过current_groups和target_groups的集合差集计算，天然幂等）。

4. 实操过程与核心环节实现

4.1 从零开始的完整集成流程（含命令行与代码）

现在，让我们把所有理论落地为可执行的步骤。假设你有一个全新的 Django 项目（Django 4.2+），目标是让https://app.example.com通过 Okta 登录。以下是我在客户现场手敲的完整流程，每一步都附带解释和避坑点：

Step 1：安装依赖与初始化

# 创建虚拟环境（推荐） python -m venv venv source venv/bin/activate # Linux/Mac # venv\Scripts\activate # Windows # 安装核心包 pip install django==4.2.11 pip install django-okta-auth==0.5.2 # 当前最新稳定版 # 创建 Django 项目 django-admin startproject myproject . python manage.py startapp accounts

为什么用django-okta-auth==0.5.2？因为 0.6.0 版本引入了对 Django 5.0 的支持，但破坏了对django.contrib.auth.backends.ModelBackend的兼容性，导致@login_required装饰器失效。0.5.2 是经过生产验证的版本。

Step 2：配置 Django Settings在myproject/settings.py中添加：

# 1. 添加 apps INSTALLED_APPS = [ # ... 其他 app 'django_okta_auth', 'accounts', ] # 2. 配置 Okta（生产环境务必用环境变量！） import os OKTA_AUTH = { "ORG_URL": os.environ.get("OKTA_ORG_URL", "https://dev-123456.okta.com"), "ISSUER": os.environ.get("OKTA_ISSUER", "https://dev-123456.okta.com/oauth2/default"), "CLIENT_ID": os.environ.get("OKTA_CLIENT_ID"), "CLIENT_SECRET": os.environ.get("OKTA_CLIENT_SECRET"), "SCOPES": "openid profile email offline_access", "REDIRECT_URI": os.environ.get("OKTA_REDIRECT_URI", "http://localhost:8000/accounts/oauth2/callback"), "LOGIN_REDIRECT_URL": "/dashboard/", "PUBLIC_NAMED_URLS": ("password_reset", "password_reset_done", "password_reset_complete"), "PUBLIC_URLS": (r"^/healthz/$", r"^/static/", r"^/media/"), "USE_USERNAME": False, "DISABLE_HTTPS_CHECK": os.environ.get("OKTA_DISABLE_HTTPS_CHECK", "False").lower() == "true", } # 3. 配置认证后端（关键！） AUTHENTICATION_BACKENDS = [ 'django_okta_auth.backend.OktaBackend', # Okta 认证 'django.contrib.auth.backends.ModelBackend', # 保留 Django 原生认证（用于管理后台） ] # 4. 配置登录 URL LOGIN_URL = '/accounts/login/' # 这会重定向到 Okta LOGOUT_URL = '/accounts/logout/' # 这会重定向到 Okta SLO # 5. 配置中间件（确保在 AuthenticationMiddleware 之后） MIDDLEWARE = [ # ... 其他 middleware 'django_okta_auth.middleware.OktaSessionMiddleware', # 必须在 AuthenticationMiddleware 之后 'django.contrib.auth.middleware.AuthenticationMiddleware', # ... 其他 middleware ]

Step 3：配置 URL 路由在myproject/urls.py中：

from django.contrib import admin from django.urls import path, include from django.views.generic import TemplateView urlpatterns = [ path('admin/', admin.site.urls), path('accounts/', include('django_okta_auth.urls')), # 必须包含！ path('accounts/', include('accounts.urls')), # 你的自定义账号逻辑 path('', TemplateView.as_view(template_name='home.html'), name='home'), ]

django_okta_auth.urls提供了/accounts/login/,/accounts/oauth2/callback/,/accounts/logout/这些关键 endpoint。漏掉这行，整个流程就断了。

Step 4：创建自定义登录模板（可选但强烈推荐）在templates/registration/login.html中：

<!-- 用 Okta 的登录按钮替换 Django 默认表单 --> <h2>Login</h2> <p>Please sign in with your company account.</p> <a href="{% url 'okta_login' %}" class="btn btn-primary"> <img src="https://global.oktacdn.com/okta-sign-in-widget/6.4.0/assets/images/logos/okta-logo-medium.png" alt="Okta Logo" width="20" height="20" style="vertical-align: middle; margin-right: 5px;"> Sign in with Okta </a> <!-- 如果你想保留 Django 原生登录（如管理员临时登录），可以加个链接 --> <p><small><a href="{% url 'admin:login' %}">Admin login (for staff only)</a></small></p>

这个模板的关键是{% url 'okta_login' %}，它会生成 Okta 的/authorizeURL，自动带上state,code_challenge,redirect_uri等参数。不要自己拼 URL！

Step 5：运行迁移并启动服务

# 创建数据库表（django-okta-auth 会创建自己的模型） python manage.py makemigrations python manage.py migrate # 创建超级用户（用于 Django admin） python manage.py createsuperuser # 启动开发服务器 python manage.py runserver 0.0.0.0:8000

现在访问http://localhost:8000，点击 “Sign in with Okta”，应该跳转到 Okta 的登录页。输入你在 Okta 中创建的测试用户（如testuser@yourdomain.com），登录成功后，会回调到http://localhost:8000/accounts/oauth2/callback，然后重定向到/dashboard/。此时，检查 Django Admin 的 Users 列表，应该能看到一个新用户，username是okta_00uabc123...，email是 Okta 用户的邮箱。

4.2 生产环境部署 checklist：十个必须验证的点

本地跑通只是万里长征第一步。生产环境有更多隐藏雷区，我整理了一份上线前必须逐项验证的 checklist，每一条都来自血泪教训：

最后一步：用真实 Okta 用户（非管理员）测试全流程。重点测：1）首次登录（创建用户），2）再次登录（复用用户），3）登出（SLO），4）访问/admin/（应重定向到 Okta），5）访问/healthz/（应直接返回 200）。只有这五步全部通过，才能上线。

5. 常见问题与排查技巧实录

5.1 登录流程卡在 Okta 页面，回调 400 错误

这是最常见也最让人抓狂的问题。现象是：点击登录按钮，跳转到 Okta，输入账号密码，点击 Sign In，然后 Okta 页面显示 “The redirect_uri is missing or does not match the configured redirect_uri.” 或类似 400 错误。90% 的情况，根源只有一个：REDIRECT_URI不匹配。

排查步骤：

1. 抓包看实际请求：在 Okta 登录页按 F12，打开 Network 标签页，点击 Sign In，找到POST /api/v1/authn请求，查看它的response里是否有sessionToken。如果有，说明认证成功，问题出在重定向。
2. 检查 Okta 的回调 URL：在 Okta Admin UI → Applications → Your App → General → Redirect URIs，确认列表里有一条完全精确的 URL，如https://app.example.com/accounts/oauth2/callback（注意：没有/结尾）。
3. 检查 Django 的OKTA_AUTH['REDIRECT_URI']：在 Django shell 里打印settings.OKTA_AUTH['REDIRECT_URI']，确认它和 Okta 配置一模一样。
4. 检查 Nginx 日志：tail -f /var/log/nginx/access.log，看 Okta 的回调请求是否到达 Nginx。如果没日志，说明 DNS 或防火墙问题；如果有日志且状态码是 400，说明是 Okta 配置问题。
5. 终极验证：在服务器上用 curl 模拟 Okta 回调：

   curl -v "https://app.example.com/accounts/oauth2/callback?code=abc123&state=xyz789"

   如果返回 400，说明 Django 的OKTA_AUTH['REDIRECT_URI']配置错误；如果返回 302，说明配置正确，问题在 Okta 端。

实操心得：我曾经在一个项目里耗了 6 小时，最后发现是 Okta 的 Redirect URIs 列表里，第一条是https://app.example.com/callback（少了个s），第二条才是正确的https://app.example.com/callbacks。Okta 会匹配第一条，导致失败。所以，确保 Okta 的 Redirect URIs 列表里只有一条，且绝对正确。

5.2 登录成功后，Django 用户没有first_name和last_name

现象：用户能登录，但在 Django Admin 里看到first_name和last_name为空。这是因为 Okta 默认不返回这些字段，需要手动开启。

解决方案：

1. 进入 Okta Admin