為你的 Express 應用程式新增驗證 (Authentication)
- 範例專案可在我們的 SDK repository 中找到。
先決條件
- 一個 Logto Cloud 帳戶或 自行架設的 Logto。
- 一個已建立的 Logto 傳統應用程式。
安裝
透過你喜愛的套件管理器安裝 Logto SDK:
- npm
- pnpm
- yarn
npm i @logto/express cookie-parser express-session
pnpm add @logto/express cookie-parser express-session
yarn add @logto/express cookie-parser express-session
整合
準備配置和所需的中介軟體
為 Logto 客戶端準備配置:
import { LogtoExpressConfig } from '@logto/express';
const config: LogtoExpressConfig = {
appId: '<your-application-id>',
appSecret: '<your-application-secret>',
endpoint: '<your-logto-endpoint>', // 例如 http://localhost:3001
baseUrl: '<your-express-app-base-url>', // 例如 http://localhost:3000
};
SDK 需要事先配置 express-session。
import cookieParser from 'cookie-parser';
import session from 'express-session';
app.use(cookieParser());
app.use(
session({
secret: 'random_session_key', // 替換為你自己的密鑰
cookie: { maxAge: 14 * 24 * 60 * 60 * 1000 }, // 毫秒
})
);
配置重定向 URI
在深入細節之前,以下是終端使用者體驗的快速概覽。登入流程可簡化如下:
- 你的應用程式呼叫登入方法。
- 使用者被重定向至 Logto 登入頁面。對於原生應用程式,系統瀏覽器會被開啟。
- 使用者登入後被重定向回你的應用程式(配置為重定向 URI)。
關於基於重導的登入
- 此驗證流程遵循 OpenID Connect (OIDC) 協議,Logto 強制執行嚴格的安全措施以保護使用者登入。
- 如果你有多個應用程式,可以使用相同的身分提供者 (IdP, Identity provider)(Logto)。一旦使用者登入其中一個應用程式,Logto 將在使用者訪問另一個應用程式時自動完成登入流程。
欲了解更多關於基於重導登入的原理和優勢,請參閱 Logto 登入體驗解析。
在以下的程式碼片段中,我們假設你的應用程式運行在 http://localhost:3000/
。
配置重定向 URI
切換到 Logto Console 的應用程式詳細資訊頁面。新增一個重定向 URI http://localhost:3000/callback
。
就像登入一樣,使用者應被重定向到 Logto 以登出共享會話。完成後,將使用者重定向回你的網站會很不錯。例如,將 http://localhost:3000/
新增為登出後重定向 URI 區段。
然後點擊「儲存」以保存更改。
註冊路由
SDK 提供了一個輔助函數 handleAuthRoutes
來註冊 3 個路由:
/logto/sign-in
:使用 Logto 登入。/logto/sign-in-callback
:處理登入回調。/logto/sign-out
:使用 Logto 登出。
將以下代碼添加到你的應用程式中:
import { handleAuthRoutes } from '@logto/express';
app.use(handleAuthRoutes(config));
實現登入和登出
註冊路由後,現在讓我們在首頁實現登入和登出按鈕。我們需要在需要時將使用者重定向到登入或登出路由。為此,使用 withLogto
將驗證狀態注入到 req.user
。
import { withLogto } from '@logto/express';
app.get('/', withLogto(config), (req, res) => {
res.setHeader('content-type', 'text/html');
if (req.user.isAuthenticated) {
res.end(`<div>Hello ${req.user.claims?.sub}, <a href="/logto/sign-out">Sign Out</a></div>`);
} else {
res.end('<div><a href="/logto/sign-in">Sign In</a></div>');
}
});
檢查點:測試你的應用程式
現在,你可以測試你的應用程式:
- 執行你的應用程式,你會看到登入按鈕。
- 點擊登入按鈕,SDK 會初始化登入流程並將你重定向到 Logto 登入頁面。
- 登入後,你將被重定向回應用程式並看到登出按鈕。
- 點擊登出按鈕以清除權杖存儲並登出。
獲取使用者資訊
顯示使用者資訊
當使用者登入後,req.user
的值將是一個包含使用者資訊的物件。你可以在應用程式中顯示這些資訊:
import { withLogto } from '@logto/express';
app.get('/', withLogto(config), (req, res) => {
response.json(request.user.claims);
});
請求額外的宣告 (Claims)
你可能會發現從 req.user
返回的物件中缺少一些使用者資訊。這是因為 OAuth 2.0 和 OpenID Connect (OIDC) 的設計遵循最小權限原則 (PoLP, Principle of Least Privilege),而 Logto 是基於這些標準構建的。
預設情況下,僅返回有限的宣告 (Claims)。如果你需要更多資訊,可以請求額外的權限範圍 (Scopes) 以存取更多宣告。
「宣告 (Claim)」是對主體所做的斷言;「權限範圍 (Scope)」是一組宣告。在目前的情況下,宣告是關於使用者的一部分資訊。
以下是權限範圍與宣告關係的非規範性範例:
「sub」宣告表示「主體 (Subject)」,即使用者的唯一識別符(例如使用者 ID)。
Logto SDK 將始終請求三個權限範圍:openid
、profile
和 offline_access
。
若要請求額外的權限範圍 (Scopes),可以在配置中新增權限範圍:
import { LogtoExpressConfig, UserScope } from '@logto/express';
const config: LogtoExpressConfig = {
scopes: [UserScope.Email, UserScope.Phone], // 如有需要可新增更多權限範圍
// ...其他配置
};
然後你可以在 req.user
物件中存取額外的宣告 (Claims):
import { withLogto } from '@logto/express';
app.get('/', withLogto(config), (req, res) => {
response.end(`User email: ${req.user.claims.email}`);
});
需要網路請求的宣告 (Claims)
為了防止 ID 權杖 (ID token) 膨脹,某些宣告 (Claims) 需要透過網路請求來獲取。例如,即使在權限範圍 (Scopes) 中請求了 custom_data
宣告,它也不會包含在使用者物件中。要存取這些宣告,你可以配置 fetchUserInfo
選項:
const config: LogtoExpressConfig = {
fetchUserInfo: true,
// ...其他配置
};
fetchUserInfo
,SDK 將在使用者登入後透過請求 userinfo 端點 來獲取使用者資訊,並且一旦請求完成,user.custom_data
將可用。
權限範圍 (Scopes) 與宣告 (Claims)
Logto 使用 OIDC 權限範圍 (Scopes) 和宣告 (Claims) 慣例 來定義從 ID 權杖 (ID token) 和 OIDC 使用者資訊端點 (userinfo endpoint) 獲取使用者資訊的權限範圍和宣告。無論是「權限範圍 (Scope)」還是「宣告 (Claim)」,都是 OAuth 2.0 和 OpenID Connect (OIDC) 規範中的術語。
以下是支援的權限範圍 (Scopes) 及其對應的宣告 (Claims):
openid
宣告名稱 | 類型 | 描述 | 需要使用者資訊嗎? |
---|---|---|---|
sub | string | 使用者的唯一識別符 | 否 |
profile
宣告名稱 | 類型 | 描述 | 需要使用者資訊嗎? |
---|---|---|---|
name | string | 使用者的全名 | 否 |
username | string | 使用者的用戶名 | 否 |
picture | string | 使用者個人資料圖片的 URL。此 URL 必須指向圖像文件(例如 PNG、JPEG 或 GIF 圖像文件),而不是包含圖像的網頁。請注意,此 URL 應特別參考適合在描述使用者時顯示的個人資料照片,而不是使用者拍攝的任意照片。 | 否 |
created_at | number | 使用者創建的時間。時間以自 Unix epoch(1970-01-01T00:00:00Z)以來的毫秒數表示。 | 否 |
updated_at | number | 使用者資訊最後更新的時間。時間以自 Unix epoch(1970-01-01T00:00:00Z)以來的毫秒數表示。 | 否 |
其他 標準宣告 包括 family_name
、given_name
、middle_name
、nickname
、preferred_username
、profile
、website
、gender
、birthdate
、zoneinfo
和 locale
也將包含在 profile
權限範圍中,無需請求使用者資訊端點。與上述宣告的不同之處在於,這些宣告僅在其值不為空時返回,而上述宣告在值為空時將返回 null
。
與標準宣告不同,created_at
和 updated_at
宣告使用毫秒而非秒。
email
宣告名稱 | 類型 | 描述 | 需要使用者資訊嗎? |
---|---|---|---|
string | 使用者的電子郵件地址 | 否 | |
email_verified | boolean | 電子郵件地址是否已驗證 | 否 |
phone
宣告名稱 | 類型 | 描述 | 需要使用者資訊嗎? |
---|---|---|---|
phone_number | string | 使用者的電話號碼 | 否 |
phone_number_verified | boolean | 電話號碼是否已驗證 | 否 |
address
請參閱 OpenID Connect Core 1.0 以獲取地址宣告的詳細資訊。
custom_data
宣告名稱 | 類型 | 描述 | 需要使用者資訊嗎? |
---|---|---|---|
custom_data | object | 使用者的自訂資料 | 是 |
identities
宣告名稱 | 類型 | 描述 | 需要使用者資訊嗎? |
---|---|---|---|
identities | object | 使用者的連結身分 | 是 |
sso_identities | array | 使用者的連結 SSO 身分 | 是 |
roles
宣告名稱 | 類型 | 描述 | 需要使用者資訊嗎? |
---|---|---|---|
roles | string[] | 使用者的角色 | 否 |
urn:logto:scope:organizations
宣告名稱 | 類型 | 描述 | 需要使用者資訊嗎? |
---|---|---|---|
organizations | string[] | 使用者所屬的組織 ID | 否 |
organization_data | object[] | 使用者所屬的組織資料 | 是 |
urn:logto:scope:organization_roles
宣告名稱 | 類型 | 描述 | 需要使用者資訊嗎? |
---|---|---|---|
organization_roles | string[] | 使用者所屬的組織角色,格式為 <organization_id>:<role_name> | 否 |
考慮到效能和資料大小,如果「需要使用者資訊嗎?」為「是」,則表示該宣告不會顯示在 ID 權杖中,而會在 使用者資訊端點 回應中返回。
API 資源與組織
我們建議先閱讀 🔐 角色型存取控制 (RBAC, Role-Based Access Control),以瞭解 Logto RBAC 的基本概念以及如何正確設定 API 資源。
配置 Logto 用戶端
一旦你設定了 API 資源,就可以在應用程式中配置 Logto 時新增它們:
import { UserScope } from '@logto/express';
const config: LogtoExpressConfig = {
// ...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:read
和 shopping:write
權限,而 https://store.your-app.com/api
資源具有 store:read
和 store:write
權限。
要請求這些權限,你可以在應用程式中配置 Logto 時新增它們:
import { UserScope } from '@logto/express';
const config: LogtoExpressConfig = {
// ...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 資源定義的。這是因為 OAuth 2.0 的資源標示符 (Resource Indicators) 指定請求的最終權限範圍將是所有目標服務中所有權限範圍的笛卡兒積。
因此,在上述情況中,權限範圍可以從 Logto 的定義中簡化,兩個 API 資源都可以擁有 read
和 write
權限範圍而不需要前綴。然後,在 Logto 配置中:
import { UserScope } from '@logto/express';
const config: LogtoExpressConfig = {
// ...other configs
scopes: ['read', 'write'],
resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'],
};
對於每個 API 資源,它將請求 read
和 write
權限範圍。
請求未在 API 資源中定義的權限範圍是可以的。例如,即使 API 資源中沒有可用的 email
權限範圍,你也可以請求 email
權限範圍。不可用的權限範圍將被安全地忽略。
成功登入後,Logto 將根據使用者的角色向 API 資源發出適當的權限範圍。
取得 API 資源的存取權杖 (Access token)
要獲取特定 API 資源的存取權杖 (Access token),你可以使用 getAccessToken
方法:
app.get(
'/fetch-access-token',
withLogto({
...config,
getAccessToken: true,
resource: 'https://shopping.your-app.com/api',
}),
(request, response) => {
console.log(request.user.accessToken);
response.json(request.user);
}
);
此方法將返回一個 JWT 存取權杖 (Access token),當使用者擁有相關權限時,可以用來存取 API 資源。如果當前快取的存取權杖 (Access token) 已過期,此方法將自動嘗試使用重新整理權杖 (Refresh token) 獲取新的存取權杖 (Access token)。
取得組織權杖 (Organization tokens)
如果你對組織 (Organization) 不熟悉,請閱讀 🏢 組織(多租戶,Multi-tenancy) 以開始了解。
在配置 Logto client 時,你需要新增 UserScope.Organizations
權限範圍 (scope):
import { UserScope } from '@logto/express';
const config: LogtoExpressConfig = {
// ...other configs
scopes: [UserScope.Organizations],
};
使用者登入後,你可以為使用者獲取組織權杖 (organization token):
app.get(
'/fetch-organization-token',
withLogto({
...config,
getOrganizationToken: true,
}),
(request, response) => {
response.json(request.user.organizationTokens);
}
);