跳到主要内容

为你的 Chrome 扩展应用程序添加认证 (Authentication)

本指南将向你展示如何将 Logto 集成到你的 Chrome 扩展中。

提示:
  • 以下演示在 Chrome v123.0.6312.87 (arm64) 上进行了测试。其他版本也应该可以工作,只要它们支持 SDK 中使用的 chrome API。
  • 示例项目可在我们的 GitHub 仓库 中找到。

先决条件

  • 一个 Logto Cloud 账户或一个 自托管 Logto
  • 在 Logto Console 中创建的单页应用程序 (SPA)。
  • 一个 Chrome 扩展项目。

安装

npm i @logto/chrome-extension

集成

认证 (Authentication) 流程

假设你在 Chrome 扩展程序的弹出窗口中放置了一个“登录”按钮,认证 (Authentication) 流程将如下所示:

对于扩展程序中的其他交互页面,你只需将 Extension popup 参与者替换为页面的名称。在本教程中,我们将专注于弹出页面。

关于基于重定向的登录

  1. 此认证 (Authentication) 过程遵循 OpenID Connect (OIDC) 协议,Logto 强制执行严格的安全措施以保护用户登录。
  2. 如果你有多个应用程序,可以使用相同的身份提供商 (IdP)(日志 (Logto))。一旦用户登录到一个应用程序,当用户访问另一个应用程序时,Logto 将自动完成登录过程。

要了解有关基于重定向的登录的原理和好处的更多信息,请参阅 Logto 登录体验解释

更新 manifest.json

Logto SDK 需要在 manifest.json 中添加以下权限:

manifest.json
{
"permissions": ["identity", "storage"],
"host_permissions": ["https://*.logto.app/*"]
}
  • permissions.identity: Chrome Identity API 所需,用于登录和注销。
  • permissions.storage: 用于存储用户会话。
  • host_permissions: Logto SDK 与 Logto API 通信所需。
备注:

如果你在 Logto Cloud 上使用自定义域名,则需要更新 host_permissions 以匹配你的域名。

设置后台脚本(服务工作者)

在你的 Chrome 扩展程序的后台脚本中,初始化 Logto SDK:

service-worker.js
import LogtoClient from '@logto/chrome-extension';

export const logtoClient = new LogtoClient({
endpoint: '<your-logto-endpoint>'
appId: '<your-logto-app-id>',
});

<your-logto-endpoint><your-logto-app-id> 替换为实际值。你可以在 Logto Console 中刚创建的应用页面中找到这些值。

如果你没有后台脚本,可以按照 官方指南 创建一个。

信息:

为什么我们需要后台脚本?

像弹出窗口或选项页面这样的普通扩展页面无法在后台运行,并且在认证 (Authentication) 过程中可能会被关闭。后台脚本确保认证 (Authentication) 过程能够被正确处理。

然后,我们需要监听来自其他扩展页面的消息并处理认证 (Authentication) 过程:

service-worker.js
chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
// 在下面的代码中,由于我们为每个操作返回 `true`,我们需要调用 `sendResponse`
// 来通知发送者。你也可以在这里处理错误,或使用其他方式通知发送者。

if (message.action === 'signIn') {
const redirectUri = chrome.identity.getRedirectURL('/callback');
logtoClient.signIn(redirectUri).finally(sendResponse);
return true;
}

if (message.action === 'signOut') {
const redirectUri = chrome.identity.getRedirectURL();
logtoClient.signOut(redirectUri).finally(sendResponse);
return true;
}

return false;
});

你可能注意到上面的代码中使用了两个重定向 URI。它们都是由 chrome.identity.getRedirectURL 创建的,这是一个 内置 Chrome API,用于为认证 (Authentication) 流程生成重定向 URL。这两个 URI 将是:

  • https://<extension-id>.chromiumapp.org/callback 用于登录。
  • https://<extension-id>.chromiumapp.org/ 用于注销。

注意,这些 URI 是不可访问的,它们仅用于 Chrome 触发认证 (Authentication) 过程的特定操作。

更新 Logto 应用设置

现在我们需要更新 Logto 应用设置以允许我们刚创建的重定向 URI。

  1. 转到 Logto Console 中的应用页面。
  2. 在“重定向 URI”部分,添加 URI:https://<extension-id>.chromiumapp.org/callback
  3. 在“注销后重定向 URI”部分,添加 URI:https://<extension-id>.chromiumapp.org/
  4. 在“CORS 允许的来源”部分,添加 URI:chrome-extension://<extension-id>。Chrome 扩展中的 SDK 将使用此来源与 Logto API 通信。
  5. 点击 保存更改

记得将 <extension-id> 替换为你的实际扩展 ID。你可以在 chrome://extensions 页面中找到扩展 ID。

向弹出窗口添加登录和注销按钮

我们快完成了!让我们向弹出页面添加登录和注销按钮以及其他必要的逻辑。

popup.html 文件中:

popup.html
<button id="sign-in">Sign in</button> <button id="sign-out">Sign out</button>

popup.js 文件中(假设 popup.js 已包含在 popup.html 中):

popup.js
document.getElementById('sign-in').addEventListener('click', async () => {
await chrome.runtime.sendMessage({ action: 'signIn' });
// 登录完成(或失败),你可以在这里更新 UI。
});

document.getElementById('sign-out').addEventListener('click', async () => {
await chrome.runtime.sendMessage({ action: 'signOut' });
// 注销完成(或失败),你可以在这里更新 UI。
});

检查点:测试认证 (Authentication) 流程

现在你可以在 Chrome 扩展程序中测试认证 (Authentication) 流程:

  1. 打开扩展程序弹出窗口。
  2. 点击“登录”按钮。
  3. 你将被重定向到 Logto 登录页面。
  4. 使用你的 Logto 账户登录。
  5. 你将被重定向回 Chrome。

检查认证 (Authentication) 状态

由于 Chrome 提供统一的存储 API,除了登录和注销流程之外,所有其他 Logto SDK 方法都可以直接在弹出页面中使用。

在你的 popup.js 中,你可以重用在后台脚本中创建的 LogtoClient 实例,或者使用相同的配置创建一个新实例:

popup.js
import LogtoClient from '@logto/chrome-extension';

const logtoClient = new LogtoClient({
endpoint: '<your-logto-endpoint>'
appId: '<your-logto-app-id>',
});

// 或重用在后台脚本中创建的 logtoClient 实例
import { logtoClient } from './service-worker.js';

然后你可以创建一个函数来加载认证 (Authentication) 状态和用户的个人资料:

popup.js
const loadAuthenticationState = async () => {
const isAuthenticated = await logtoClient.isAuthenticated();
// 根据认证 (Authentication) 状态更新 UI

if (isAuthenticated) {
const user = await logtoClient.getIdTokenClaims(); // { sub: '...', email: '...', ... }
// 使用用户的个人资料更新 UI
}
};

你还可以将 loadAuthenticationState 函数与登录和注销逻辑结合起来:

popup.js
document.getElementById('sign-in').addEventListener('click', async () => {
await chrome.runtime.sendMessage({ action: 'signIn' });
await loadAuthenticationState();
});

document.getElementById('sign-out').addEventListener('click', async () => {
await chrome.runtime.sendMessage({ action: 'signOut' });
await loadAuthenticationState();
});

这是一个带有认证 (Authentication) 状态的弹出页面示例:

Popup page

其他注意事项

  • 服务工作者打包:如果你使用像 Webpack 或 Rollup 这样的打包工具,你需要显式将目标设置为 browser 或类似选项,以避免不必要的 Node.js 模块打包。
  • 模块解析:Logto Chrome 扩展 SDK 是一个仅支持 ESM 的模块。

查看我们的 示例项目,了解使用 TypeScript、Rollup 和其他配置的完整示例。

获取用户信息

显示用户信息

要显示用户的信息,你可以使用 logtoClient.getIdTokenClaims() 方法。例如,在你的主页中:

Home.js
const userInfo = await logtoClient.getIdTokenClaims();

// 为 ID 令牌 (ID token) 声明 (Claims) 生成显示表格
const table = document.createElement('table');
const thead = document.createElement('thead');
const tr = document.createElement('tr');
const thName = document.createElement('th');
const thValue = document.createElement('th');
thName.innerHTML = 'Name';
thValue.innerHTML = 'Value';
tr.append(thName, thValue);
thead.append(tr);
table.append(thead);

const tbody = document.createElement('tbody');

for (const [key, value] of Object.entries(userInfo)) {
const tr = document.createElement('tr');
const tdName = document.createElement('td');
const tdValue = document.createElement('td');
tdName.innerHTML = key;
tdValue.innerHTML = typeof value === 'string' ? value : JSON.stringify(value);
tr.append(tdName, tdValue);
tbody.append(tr);
}

table.append(tbody);

请求额外的声明 (Claims)

你可能会发现从 getIdTokenClaims() 返回的对象中缺少一些用户信息。这是因为 OAuth 2.0 和 OpenID Connect (OIDC) 的设计遵循最小权限原则 (PoLP),而 Logto 是基于这些标准构建的。

默认情况下,返回的声明(Claim)是有限的。如果你需要更多信息,可以请求额外的权限(Scope)以访问更多的声明(Claim)。

信息:

“声明(Claim)”是关于主体的断言;“权限(Scope)”是一组声明。在当前情况下,声明是关于用户的一条信息。

以下是权限(Scope)与声明(Claim)关系的非规范性示例:

提示:

“sub” 声明(Claim)表示“主体(Subject)”,即用户的唯一标识符(例如用户 ID)。

Logto SDK 将始终请求三个权限(Scope):openidprofileoffline_access

要请求额外的权限 (Scopes),你可以配置 Logto 配置:

index.js
import LogtoClient, { UserScope } from '@logto/browser';

const logtoClient = new LogtoClient({
appId: '<your-application-id>',
endpoint: '<your-logto-endpoint>',
scopes: [UserScope.Email, UserScope.Phone],
});

然后你可以在 logtoClient.getIdTokenClaims() 的返回值中访问额外的声明 (Claims):

const claims = await getIdTokenClaims();
// 现在你可以访问额外的声明 (Claims) `claims.email`,`claims.phone`,等等。

需要网络请求的声明

为了防止 ID 令牌 (ID token) 过大,一些声明需要通过网络请求来获取。例如,即使在权限中请求了 custom_data 声明,它也不会包含在用户对象中。要访问这些声明,你可以使用 logtoClient.fetchUserInfo() 方法

const userInfo = await logtoClient.fetchUserInfo();
// 现在你可以访问声明 (Claim) `userInfo.custom_data`
该方法将通过请求 userinfo 端点来获取用户信息。要了解更多可用的权限和声明,请参阅 权限和声明部分。

权限 (Scopes) 和声明 (Claims)

Logto 使用 OIDC 权限和声明约定 来定义从 ID 令牌和 OIDC 用户信息端点检索用户信息的权限和声明。“权限”和“声明”都是 OAuth 2.0 和 OpenID Connect (OIDC) 规范中的术语。

以下是支持的权限(Scopes)及其对应的声明(Claims)列表:

openid

声明名称类型描述需要用户信息吗?
substring用户的唯一标识符

profile

声明名称类型描述需要用户信息吗?
namestring用户的全名
usernamestring用户名
picturestring终端用户的个人资料图片的 URL。此 URL 必须指向一个图像文件(例如,PNG、JPEG 或 GIF 图像文件),而不是包含图像的网页。请注意,此 URL 应特别引用适合在描述终端用户时显示的终端用户的个人资料照片,而不是终端用户拍摄的任意照片。
created_atnumber终端用户创建的时间。时间表示为自 Unix 纪元(1970-01-01T00:00:00Z)以来的毫秒数。
updated_atnumber终端用户信息最后更新的时间。时间表示为自 Unix 纪元(1970-01-01T00:00:00Z)以来的毫秒数。

其他 标准声明 包括 family_namegiven_namemiddle_namenicknamepreferred_usernameprofilewebsitegenderbirthdatezoneinfolocale 也将包含在 profile 权限中,而无需请求用户信息端点。与上述声明的区别在于,这些声明只有在其值不为空时才会返回,而上述声明在值为空时将返回 null

备注:

与标准声明不同,created_atupdated_at 声明使用毫秒而不是秒。

email

声明名称类型描述需要用户信息吗?
emailstring用户的电子邮件地址
email_verifiedboolean电子邮件地址是否已验证

phone

声明名称类型描述需要用户信息吗?
phone_numberstring用户的电话号码
phone_number_verifiedboolean电话号码是否已验证

address

请参阅 OpenID Connect Core 1.0 以获取地址声明的详细信息。

custom_data

声明名称类型描述需要用户信息吗?
custom_dataobject用户的自定义数据

identities

声明名称类型描述需要用户信息吗?
identitiesobject用户的关联身份
sso_identitiesarray用户的关联 SSO 身份

urn:logto:scope:organizations

声明名称类型描述需要用户信息吗?
organizationsstring[]用户所属的组织 ID
organization_dataobject[]用户所属的组织数据

urn:logto:scope:organization_roles

声明名称类型描述需要用户信息吗?
organization_rolesstring[]用户所属的组织角色,格式为 <organization_id>:<role_name>

考虑到性能和数据大小,如果“需要用户信息吗?”为“是”,则表示声明不会显示在 ID 令牌中,而会在 用户信息端点 响应中返回。

API 资源

我们建议首先阅读 🔐 基于角色的访问控制 (RBAC),以了解 Logto RBAC 的基本概念以及如何正确设置 API 资源。

配置 Logto 客户端

一旦你设置了 API 资源,就可以在应用中配置 Logto 时添加它们:

index.js
import LogtoClient from '@logto/browser';

const logtoClient = new LogtoClient({
// ...other configs
resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'], // 添加 API 资源 (API resources)
});

每个 API 资源都有其自己的权限(权限)。

例如,https://shopping.your-app.com/api 资源具有 shopping:readshopping:write 权限,而 https://store.your-app.com/api 资源具有 store:readstore:write 权限。

要请求这些权限,你可以在应用中配置 Logto 时添加它们:

index.js
import LogtoClient from '@logto/chrome-extension';

const logtoClient = new LogtoClient({
// ...other configs
scopes: ['shopping:read', 'shopping:write', 'store:read', 'store:write'],
resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'], // 添加 API 资源 (API resources)
});

你可能会注意到权限是与 API 资源分开定义的。这是因为 OAuth 2.0 的资源指示器 指定请求的最终权限将是所有目标服务中所有权限的笛卡尔积。

因此,在上述情况下,权限可以从 Logto 中的定义简化,两个 API 资源都可以拥有 read write 权限,而无需前缀。然后,在 Logto 配置中:

index.js
import LogtoClient, { UserScope } from '@logto/chrome-extension';

const logtoClient = new LogtoClient({
// ...other configs
scopes: ['read', 'write'],
resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'],
});

对于每个 API 资源,它将请求 readwrite 权限。

备注:

请求 API 资源中未定义的权限是可以的。例如,即使 API 资源没有可用的 email 权限,你也可以请求 email 权限。不可用的权限将被安全地忽略。

成功登录后,Logto 将根据用户的角色向 API 资源发布适当的权限。

获取 API 资源的访问令牌 (Access token)

要获取特定 API 资源的访问令牌 (access token),你可以使用 getAccessToken 方法:

const accessToken = await logtoClient.getAccessToken('https://store.your-app.com/api');
console.log('访问令牌 (Access token)', accessToken);

此方法将返回一个 JWT 访问令牌 (access token),当用户具有相关权限时,可以用来访问 API 资源。如果当前缓存的访问令牌 (access token) 已过期,此方法将自动尝试使用刷新令牌 (refresh token) 获取新的访问令牌 (access token)。

获取组织令牌 (Organization tokens)

如果你对组织不熟悉,请阅读 🏢 组织(多租户) 以开始了解。

在配置 Logto 客户端时,你需要添加 UserScope.Organizations 权限:

index.js
import LogtoClient, { UserScope } from '@logto/chrome-extension';

const logtoClient = new LogtoClient({
// ...other configs
scopes: [UserScope.Organizations],
});

用户登录后,你可以获取用户的组织令牌:

index.js
// 从 userInfo 获取 organizationIds

const claims = await logtoClient.getIdTokenClaims();
const organizationIds = claims.organizations;

/**
* 或者从 ID 令牌 (ID token) 声明 (claims) 中获取
*
* const claims = await logtoClient.getIdTokenClaims();
* const organizationIds = claims.organizations;
*/

// 获取组织令牌 (Organization token)
if (organizationIds.length > 0) {
const organizationId = organizationIds[0];
const organizationAccessToken = await logtoClient.getOrganizationToken(organizationId);
console.log('组织令牌 (Organization access token)', organizationAccessToken);
}

./code/_scopes-and-claims-code.mdx./code/_config-organization-code.mdx

将访问令牌 (Access token) 附加到请求头

将令牌放入 HTTP 头的 Authorization 字段中,使用 Bearer 格式(Bearer YOUR_TOKEN),然后你就可以开始了。

备注:

Bearer 令牌的集成流程可能会根据你使用的框架或请求者而有所不同。选择你自己的方式来应用请求 Authorization 头。

延伸阅读

终端用户流程:认证流程、账户流程和组织流程 配置连接器 保护你的 API