為你的 Nuxt 3 應用程式新增驗證 (Authentication)
- 以下示範基於 Nuxt 3.10.2 構建。
- 範例專案可在 GitHub 儲存庫 中找到。
- Logto Nuxt SDK 需要伺服器端渲染 (SSR) 才能正常運作。對於單頁應用程式 (SPA),請參閱我們的 Vue SDK。
先決條件
- 一個 Logto Cloud 帳戶或 自行託管的 Logto。
- 已建立的 Logto 傳統網頁應用程式。
安裝
透過你喜愛的套件管理器安裝 Logto SDK:
- npm
- pnpm
- Yarn
npm i @logto/nuxt
pnpm add @logto/nuxt
yarn add @logto/nuxt
整合
註冊 Logto 模組
在你的 Nuxt 配置檔案中,新增 Logto 模組並進行配置:
export default defineNuxtConfig({
modules: ['@logto/nuxt'],
runtimeConfig: {
logto: {
endpoint: '<your-logto-endpoint>',
appId: '<your-logto-app-id>',
appSecret: '<your-logto-app-secret>',
cookieEncryptionKey: '<a-random-string>',
},
},
// ...其他配置
});
由於這些資訊較為敏感,建議使用環境變數(.env
):
NUXT_LOGTO_ENDPOINT="<your-logto-endpoint>"
NUXT_LOGTO_APP_ID="<your-logto-app-id>"
NUXT_LOGTO_APP_SECRET="<your-logto-app-secret>"
NUXT_LOGTO_COOKIE_ENCRYPTION_KEY="<a-random-string>"
更多資訊請參閱 runtime config。
配置重定向 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 區段。
然後點擊「儲存」以保存更改。
處理回呼
處理回呼路由不需要額外的設置。註冊 @logto/nuxt
模組時,會自動執行以下操作:
- 新增三個路由:登入 (
/sign-in
)、登出 (/sign-out
) 和回呼 (/callback
)。 - 匯入兩個 composable:
useLogtoClient
和useLogtoUser
。
這些路由可以透過模組選項中的 logto.pathnames
進行配置,例如:
export default defineNuxtConfig({
logto: {
pathnames: {
signIn: '/login',
signOut: '/logout',
callback: '/auth/callback',
},
},
// ...其他配置
});
查看 @logto/nuxt
套件中的 type definition file 以獲取更多資訊。
如果你將回呼路由配置為不同的路徑,則需要在 Logto 中相應更新重定向 URI。
實現登入和登出
由於 Nuxt 頁面在初始加載後會被加載成單頁應用程式 (SPA),我們需要在需要時將使用者重定向到登入或登出路由。為此,我們的 SDK 提供了 useLogtoUser()
composable,可在伺服器端和客戶端使用。
<script setup lang="ts">
import { useLogtoUser } from '#imports'; // 如果自動匯入被禁用,請新增此行
const user = useLogtoUser();
</script>
<template>
<!-- 簡化的登入和登出按鈕 -->
<nuxt-link :to="`/sign-${ user ? 'out' : 'in' }`"> Sign {{ user ? 'out' : 'in' }} </nuxt-link>
</template>
檢查點:測試你的應用程式
現在,你可以測試你的應用程式:
- 執行你的應用程式,你會看到登入按鈕。
- 點擊登入按鈕,SDK 會初始化登入流程並將你重定向到 Logto 登入頁面。
- 登入後,你將被重定向回應用程式並看到登出按鈕。
- 點擊登出按鈕以清除權杖存儲並登出。
獲取使用者資訊
顯示使用者資訊
當使用者登入時,useLogtoUser()
的返回值將是一個包含使用者資訊的物件。你可以在應用程式中顯示這些資訊:
<script setup lang="ts">
const user = useLogtoUser();
</script>
<template>
<!-- 當登入時顯示使用者資訊 -->
<ul v-if="Boolean(user)">
<li v-for="(value, key) in user"><b>{{ key }}:</b> {{ value }}</li>
</ul>
<!-- 簡化的登入和登出按鈕 -->
<nuxt-link :to="`/sign-${ user ? 'out' : 'in' }`"> Sign {{ user ? 'out' : 'in' }} </nuxt-link>
</template>
請求額外的宣告 (Claims)
你可能會發現從 useLogtoUser()
返回的物件中缺少一些使用者資訊。這是因為 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),你可以配置 logto
模組選項:
import { UserScope } from '@logto/nuxt';
export default defineNuxtConfig({
logto: {
scopes: [UserScope.Email, UserScope.Phone], // 如有需要可新增更多權限範圍
// ...其他配置
},
});
然後你可以在 user
物件中存取額外的宣告 (Claims):
<template>
<div v-if="user">
<p>Name: {{ user.name }}</p>
<p>Email: {{ user.email }}</p>
<p>Phone: {{ user.phone }}</p>
</div>
</template>
需要網路請求的宣告 (Claims)
為了防止 ID 權杖 (ID token) 膨脹,某些宣告 (Claims) 需要透過網路請求來獲取。例如,即使在權限範圍 (Scopes) 中請求了 custom_data
宣告,它也不會包含在使用者物件中。要存取這些宣告,你可以配置 fetchUserInfo
選項:
export default defineNuxtConfig({
logto: {
scopes: [UserScope.CustomData],
fetchUserInfo: true,
},
// ...其他配置
});
fetchUserInfo
,SDK 將在使用者登入後透過請求 userinfo 端點 來獲取使用者資訊,並且一旦請求完成,user.custom_data
將可用。
手動獲取使用者資訊
要存取 Logto 客戶端提供的所有方法,你可以使用 useLogtoClient()
組合函式:
const client = useLogtoClient();
Logto 客戶端僅在伺服器端可用。在客戶端,組合函式將返回 undefined
。
你可以使用這些 Logto 方法以程式化方式檢索使用者資訊:
client.getIdTokenClaims()
:透過解碼本地 ID 權杖 (ID token) 獲取使用者資訊。某些宣告 (Claims) 可能無法取得。client.fetchUserInfo()
:透過向 userinfo endpoint 發送請求來獲取使用者資訊。
需要注意的是,可以檢索的使用者資訊宣告 (Claims) 取決於使用者登入時使用的權限範圍 (Scopes)。考慮到效能和資料大小,ID 權杖 (ID token) 可能不包含所有使用者宣告 (Claims),某些使用者宣告 (Claims) 僅在 userinfo endpoint 中可用(請參閱下方相關列表)。
例如,要手動獲取使用者資訊:
import { useLogtoClient, useState, callOnce } from '#imports';
const client = useLogtoClient();
const userInfo = useState(null);
// 僅呼叫一次以防止在客戶端執行
await callOnce(async () => {
if (!client) {
throw new Error('Logto 客戶端不可用');
}
if (!(await client.isAuthenticated())) {
return;
}
try {
userInfo.value = await client.fetchUserInfo();
} catch (error) {
console.error('獲取使用者資訊失敗:', error);
}
});
權限範圍 (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 時新增它們:
export default defineNuxtConfig({
logto: {
resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'], // 新增 API 資源 (API resources)
// ...other configs
},
});
每個 API 資源都有其自身的權限(權限範圍)。
例如,https://shopping.your-app.com/api
資源具有 shopping:read
和 shopping:write
權限,而 https://store.your-app.com/api
資源具有 store:read
和 store:write
權限。
要請求這些權限,你可以在應用程式中配置 Logto 時新增它們:
export default defineNuxtConfig({
logto: {
scopes: ['shopping:read', 'shopping:write', 'store:read', 'store:write'],
resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'],
// ...other configs
},
});
你可能會注意到權限範圍是獨立於 API 資源定義的。這是因為 OAuth 2.0 的資源標示符 (Resource Indicators) 指定請求的最終權限範圍將是所有目標服務中所有權限範圍的笛卡兒積。
因此,在上述情況中,權限範圍可以從 Logto 的定義中簡化,兩個 API 資源都可以擁有 read
和 write
權限範圍而不需要前綴。然後,在 Logto 配置中:
export default defineNuxtConfig({
logto: {
scopes: ['read', 'write'],
resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'],
// ...other configs
},
});
對於每個 API 資源,它將請求 read
和 write
權限範圍。
請求未在 API 資源中定義的權限範圍是可以的。例如,即使 API 資源中沒有可用的 email
權限範圍,你也可以請求 email
權限範圍。不可用的權限範圍將被安全地忽略。
成功登入後,Logto 將根據使用者的角色向 API 資源發出適當的權限範圍。
取得 API 資源的存取權杖 (Access token)
要獲取特定 API 資源的存取權杖 (Access token),你可以使用 getAccessToken
方法:
<script setup lang="ts">
// 用於存取 Logto 客戶端的可組合函式
const client = useLogtoClient();
// 使權杖在全域可用
const accessToken = useState<string | undefined>('access-token');
// 在伺服器端呼叫一次
await callOnce(async () => {
if (!client) {
throw new Error('Logto client is not available');
}
if (!(await client.isAuthenticated())) {
return;
}
try {
accessToken.value = await client.getAccessToken('https://shopping.your-app.com/api');
} catch (error) {
console.error('Failed to get access token', error);
}
});
</script>
此方法將返回一個 JWT 存取權杖 (Access token),當使用者擁有相關權限時,可以用來存取 API 資源。如果當前快取的存取權杖 (Access token) 已過期,此方法將自動嘗試使用重新整理權杖 (Refresh token) 獲取新的存取權杖 (Access token)。
取得組織權杖 (Organization tokens)
如果你對組織 (Organization) 不熟悉,請閱讀 🏢 組織(多租戶,Multi-tenancy) 以開始了解。
在配置 Logto client 時,你需要新增 UserScope.Organizations
權限範圍 (scope):
import { UserScope } from '@logto/nuxt';
export default defineNuxtConfig({
logto: {
scopes: [UserScope.Organizations],
// ...other configs
},
});
使用者登入後,你可以為使用者獲取組織權杖 (organization token):
const token = await client.getOrganizationToken(organizationId);
組織 API 資源 (Organization API resources)
若要為組織中的 API 資源獲取存取權杖 (Access token),可以使用 getAccessToken
方法,並將 API 資源和組織 ID 作為參數:
const accessToken = await client.getAccessToken(
'https://shopping.your-app.com/api',
organizationId
);
在中介軟體或 API 路由中使用
可組合的 useLogtoClient()
和 useLogtoUser()
無法在中介軟體或 API 路由中使用。你可以使用 logtoEventHandler()
函數來獲取 Logto 客戶端和其他上下文:
import { logtoEventHandler } from '@logto/nuxt';
export default defineEventHandler(async (event) => {
const config = useRuntimeConfig(event);
await logtoEventHandler(event, config);
const accessToken = await event.context.logtoClient.getAccessToken();
return { accessToken };
});