本文详解 LTI 1.3 工具中获取用户信息的两种标准方式（JWT 声明解析与 Names and Role Provisioning Service 调用），明确 auth.php 与 token.php 的职责边界，并提供 scope 配置、JWT 解析示例及关键注意事项，助开发者合规对接 Moodle 等主流 LMS。
本文详解 lti 1.3 工具中获取用户信息的两种标准方式（jwt 声明解析与 names and role provisioning service 调用），明确 `auth.php` 与 `token.php` 的职责边界，并提供 scope 配置、jwt 解析示例及关键注意事项，助开发者合规对接 moodle 等主流 lms。
在构建符合 IMS Global LTI 1.3 标准的学习工具时，准确、安全地获取用户身份是实现个性化体验（如自动填充姓名/角色、同步成绩、创建 OneNote 笔记本）的前提。许多开发者（尤其在本地调试 Moodle 时）会困惑于：为何调用 /mod/lti/token.php 获得了 Bearer Token，却无法直接从中提取用户邮箱或角色？这本质上源于对 LTI 1.3 安全架构与服务分层的误解。下面我们将从核心流程、关键端点、标准实践三方面系统梳理。
? 一、两个关键端点的职责不可混淆
/mod/lti/auth.php（OpenID Connect 认证端点）
这是 LTI 1.3 启动流程的第一道门，严格遵循 OpenID Connect Authorization Code Flow。当 LMS（如 Moodle）发起资源链接（Resource Link）启动时，会重定向至该地址，携带client_id、login_hint、target_link_uri等参数。其核心作用是：
✅ 验证 LMS 的 JWT ID Token 签名与声明（如iss,aud,exp）；
✅ 生成授权码（authorization code），供后续换取访问令牌（Access Token）；
❌ 它不返回用户数据本身，也不处理 scope——它只负责身份认证与授权流转。/mod/lti/token.php（OAuth 2.0 Token 端点）
工具后端用上一步获得的code，向此端点发起POST请求（含client_id,client_secret,redirect_uri,grant_type=authorization_code），换取：
✅ 一个短期有效的 Bearer Access Token（用于调用 LTI Advantage 服务）；
✅ 一个 ID Token（JWT 格式，含基础用户身份声明）。
⚠️ 注意：你手动构造 JWT 并调用此接口绕过auth.php是非标准且不安全的调试行为，生产环境必须走完整 OIDC 流程。
? 二、获取用户信息的两种标准路径
LTI 1.3 明确区分“启动时的基础身份”与“运行时的扩展成员信息”，开发者需按需选择：
✅ 方式 1：解析 Launch JWT 中的 User Identity Claims（推荐首选）
每次 LMS 启动工具时，都会在 id_token 参数中附带一个已签名 JWT。解码后（无需验签即可查看 payload），你将获得标准化的用户声明，例如：
{
"sub": "user_12345",
"name": "Zhang San",
"given_name": "San",
"family_name": "Zhang",
"email": "zhangsan@school.edu",
"https://purl.imsglobal.org/spec/lti/claim/roles": [
"http://purl.imsglobal.org/vocab/lis/v2/membership#Instructor"
],
"https://purl.imsglobal.org/spec/lti/claim/custom": {
"canvas_user_id": "112233"
}
}
? 关键点：这些字段由 LMS 在启动时主动提供，无需额外 API 调用，零延迟、零 scope 依赖，适用于绝大多数场景（如显示用户名、判断教师/学生角色）。
✅ 方式 2：调用 Names and Role Provisioning Service（NRPS）获取上下文级成员列表
当你需要获取当前课程（Context）内所有成员（如全班学生邮箱列表、助教名单），或需确认用户在该课程中的精确角色（如 TeachingAssistant），则必须调用 NRPS 服务。其流程为：
-
确保 Token 请求包含正确 scope
在调用token.php换取 Access Token 时，scope参数必须显式声明：scope=https://purl.imsglobal.org/spec/lti-nrps/scope/contextmembership.readonly
若未声明，即使成功获取 Token，后续 NRPS 请求也会返回
403 Forbidden。 -
调用 NRPS Endpoint
从 Launch JWT 的https://purl.imsglobal.org/spec/lti/claim/tool_platform声明中提取nrps服务 URL（如https://moodle.example.com/mod/lti/services/nrps/v2/courses/course-123/memberships），然后发送带 Bearer Token 的 GET 请求：curl -X GET \ -H "Authorization: Bearer eyJhbGciOi..." \ "https://moodle.example.com/mod/lti/services/nrps/v2/courses/course-123/memberships"
响应示例（简化）：
{ "memberships": [ { "status": "Active", "user": { "user_id": "user_12345", "name": "Zhang San", "email": "zhangsan@school.edu", "picture": "https://..." }, "roles": ["http://purl.imsglobal.org/vocab/lis/v2/membership#Instructor"] } ] }
⚠️ 三、重要注意事项与避坑指南
-
永远不要注释或绕过
scope：token.php中的 scope 是 OAuth 2.0 授权的核心契约。删除它等于放弃权限声明，导致服务调用失败。开发时可先固定写死 scope 字符串，上线前再动态注入。 -
JWT 解析 ≠ Token 验证：调试阶段可用 jwt.io 快速解码
id_token查看内容，但生产环境必须验证 JWT 签名、iss（LMS 发行者）、aud（你的 client_id）、exp（有效期），否则存在严重安全风险。 - Moodle 特别提醒：确保 LMS 管理员已在站点管理 → 插件 → 外部工具 → LTI 工具设置中，为你的工具启用 "Names and Roles Provisioning Service"（NRPS）和 "Deep Linking"（深层链接）服务，否则相关 claim 和 endpoint 将不会出现在 Launch JWT 中。
-
时间戳敏感：LTI 1.3 对 JWT 的
iat（issued at）和exp（expires at）有严格校验（通常允许 ±5 分钟偏差）。确保服务器时间与 NTP 同步，否则频繁出现invalid_token错误。
通过严格遵循上述规范，你的 LTI 1.3 工具不仅能稳定获取用户身份，更能无缝适配 Canvas、Brightspace、Schoology、Blackboard 等所有 LTI 1.3 Advantage 平台——这也是 Microsoft 365 LTI 应用能在多 LMS 中统一部署的技术基石。
