为你的 .NET Core (Razor Pages) 应用添加认证
- 以下演示基于 .NET Core 8.0 构建。该 SDK 兼容 .NET 6.0 或更高版本。
- .NET Core 示例项目可在 GitHub 仓库 中找到。
前提条件
- 一个 Logto Cloud 账户或一个 自托管 Logto。
- 一个 Logto 传统 Web 应用已创建。
安装
将 NuGet 包添加到你的项目中:
dotnet add package Logto.AspNetCore.Authentication
集成
添加 Logto 认证
打开 Startup.cs
(或 Program.cs
)并添加以下代码以注册 Logto 认证服务:
using Logto.AspNetCore.Authentication;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddLogtoAuthentication(options =>
{
options.Endpoint = builder.Configuration["Logto:Endpoint"]!;
options.AppId = builder.Configuration["Logto:AppId"]!;
options.AppSecret = builder.Configuration["Logto:AppSecret"];
});
AddLogtoAuthentication
方法将执行以下操作:
- 将默认认证方案设置为
LogtoDefaults.CookieScheme
。 - 将默认挑战方案设置为
LogtoDefaults.AuthenticationScheme
。 - 将默认注销方案设置为
LogtoDefaults.AuthenticationScheme
。 - 将 cookie 和 OpenID Connect 认证处理程序添加到认证方案中。
登录和登出流程
在我们继续之前,需要澄清 .NET Core 认证中间件中的两个容易混淆的术语:
- CallbackPath:用户登录后,Logto 将用户重定向回来的 URI(在 Logto 中称为“重定向 URI”)
- RedirectUri:在 Logto 认证中间件中完成必要操作后,将重定向到的 URI。
登录过程可以如下图所示:
类似地,.NET Core 也有用于注销流程的 SignedOutCallbackPath 和 RedirectUri。
为了清晰起见,我们将它们称为:
我们使用的术语 | .NET Core 术语 |
---|---|
Logto 重定向 URI | CallbackPath |
Logto 注销后重定向 URI | SignedOutCallbackPath |
应用程序重定向 URI | RedirectUri |
关于基于重定向的登录
- 此认证 (Authentication) 过程遵循 OpenID Connect (OIDC) 协议,Logto 强制执行严格的安全措施以保护用户登录。
- 如果你有多个应用程序,可以使用相同的身份提供商 (IdP)(日志 (Logto))。一旦用户登录到一个应用程序,当用户访问另一个应用程序时,Logto 将自动完成登录过程。
要了解有关基于重定向的登录的原理和好处的更多信息,请参阅 Logto 登录体验解释。
配置重定向 URI
在以下代码片段中,我们假设你的应用程序运行在 http://localhost:3000/
。
首先,让我们配置 Logto 重定向 URI。将以下 URI 添加到 Logto 应用详情页面的“重定向 URI”列表中:
http://http://localhost:3000//Callback
要配置 Logto 签出后重定向 URI,请将以下 URI 添加到 Logto 应用详情页面的“签出后重定向 URI”列表中:
http://http://localhost:3000//SignedOutCallback
更改默认路径
Logto 重定向 URI 的默认路径是 /Callback
,而 Logto 签出后重定向 URI 的默认路径是 /SignedOutCallback
。
如果没有特殊要求,你可 以保持原样。如果你想更改它,可以为 LogtoOptions
设置 CallbackPath
和 SignedOutCallbackPath
属性:
builder.Services.AddLogtoAuthentication(options =>
{
// 其他配置...
options.CallbackPath = "/Foo";
options.SignedOutCallbackPath = "/Bar";
});
记得在 Logto 应用详情页面中相应地更新值。
实现登录和登出按钮
首先,将处理程序方法添加到你的 PageModel
中,例如:
public class IndexModel : PageModel
{
public async Task OnPostSignInAsync()
{
await HttpContext.ChallengeAsync(new AuthenticationProperties
{
RedirectUri = "/"
});
}
public async Task OnPostSignOutAsync()
{
await HttpContext.SignOutAsync(new AuthenticationProperties
{
RedirectUri = "/"
});
}
}
然后,将按钮添加到你的 Razor 页面:
<p>是否已认证:@User.Identity?.IsAuthenticated</p>
<form method="post">
@if (User.Identity?.IsAuthenticated == true) {
<button type="submit" asp-page-handler="SignOut">登出</button>
} else {
<button type="submit" asp-page-handler="SignIn">登录</button>
}
</form>
如果用户未认证,它将显示“登录”按钮;如果用户已认证,则显示“登出”按钮。
检查点:测试你的应用程序
现在,你可以测试你的应用程序:
- 运行你的应用程序,你将看到登录按钮。
- 点击登录按钮,SDK 将初始化登录过程并将你重定向到 Logto 登录页面。
- 登录后,你将被重定向回你的应用程序,并看到登出按钮。
- 点击登出按钮以清除本地存储并登出。
获取用户信息
显示用户信息
要知道用户是否已认证 (Authenticated),你可以检查 User.Identity?.IsAuthenticated
属性。
要获取用户资料声明 (Claims),你可以使用 User.Claims
属性:
var claims = User.Claims;
// 获取用户 ID
var userId = claims.FirstOrDefault(c => c.Type == LogtoParameters.Claims.Subject)?.Value;
查看 LogtoParameters.Claims
以获取声明名称及其含义的列表。
请求额外的声明
你可能会发现从 User.Claims
返回的对象中缺少一些用户信息。这是因为 OAuth 2.0 和 OpenID Connect (OIDC) 的设计遵循最小权限原则 (PoLP),而 Logto 是基于这些标准构建的。
默认情况下,返回的声明(Claim)是有限的。如果你需要更多信息,可以请求额外的权限(Scope)以访问更多的声明(Claim)。
“声明(Claim)”是关于主体的断言;“权限(Scope)”是一组声明。在当前情况下,声明是关于用户的一条信息。
以下是权限(Scope)与声明(Claim)关系的非规范性示例:
“sub” 声明(Claim)表示“主体(Subject)”,即用户的唯一标识符(例如用户 ID)。
Logto SDK 将始终请求三个权限(Scope):openid
、profile
和 offline_access
。
要请求额外的权限 (Scopes),你可以在 options
对象中配置 Scopes
属性:
builder.Services.AddLogtoAuthentication(options =>
{
// ...
options.Scopes = new string[] {
LogtoParameters.Scopes.Email,
LogtoParameters.Scopes.Phone
}
});
然后你可以通过 User.Claims
访问额外的声明:
var claims = User.Claims;
// 获取用户邮箱
var email = claims.FirstOrDefault(c => c.Type == LogtoParameters.Claims.Email)?.Value;
需要网络请求的声明
为了防止用户对象膨胀,某些声明需要网络请求来获取。例如,即使在权限中请求了 custom_data 声明,它也不会包含在用户对象中。要获取这些声明,你可以在 options
对象中将 GetClaimsFromUserInfoEndpoint
设置为 true
:
builder.Services.AddLogtoAuthentication(options =>
{
// ...
options.GetClaimsFromUserInfoEndpoint = true;
});
权限和声明
Logto 使用 OIDC 权限和声明约定 来定义从 ID 令牌和 OIDC 用户信息端点检索用户信息的权限和声明。“权限”和“声明”都是 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 纪元(1970-01-01T00:00:00Z)以来的毫秒数。 | 否 |
updated_at | number | 终端用户信息最后更新的时间。时间表示为自 Unix 纪元(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 身份 | 是 |
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),以了解 Logto RBAC 的基本概念以及如何正确设置 API 资源。
在你的应用中配置 API 资源
一旦你设置了 API 资源,就可以在应用中配置 Logto 时添加它们:
builder.Services.AddLogtoAuthentication(options =>
{
// ...
options.Resource = "https://<your-api-resource-indicator>";
});
每个 API 资源都有其自己的权限(权限)。
例如,https://shopping.your-app.com/api
资源具有 shopping:read
和 shopping:write
权限,而 https://store.your-app.com/api
资源具有 store:read
和 store:write
权限。
要请求这些权限,你可以在应用中配置 Logto 时添加它们:
builder.Services.AddLogtoAuthentication(options =>
{
// ...
options.Resource = "https://shopping.your-app.com/api";
options.Scopes = new string[] {
"openid",
"profile",
"offline_access",
"read",
"write"
};
});
你可能会注意到权限是与 API 资源分开定义的。这是因为 OAuth 2.0 的资源指示器 指定请求的最终权限将是所有目标服务中所有权限的笛卡尔积。
请求 API 资源中未定义的权限是可以的。例如,即使 API 资源没有可用的 email
权限,你也可以请求 email
权限。不可用的权限将被安全地忽略。
成功登录后,Logto 将根据用户的角色向 API 资源发布适当的权限。
获取令牌
有时你可能需要获取访问令牌 (access token) 或 ID 令牌 (ID token) 以进行 API 调用。你可以使用 GetTokenAsync
方法来获取这些令牌:
var accessToken = await HttpContext.GetTokenAsync(LogtoParameters.Tokens.AccessToken);
var idToken = await HttpContext.GetTokenAsync(LogtoParameters.Tokens.IdToken);
无需担心令牌过期,认证 (Authentication) 中间件会在必要时自动刷新令牌。
虽然认证 (Authentication) 中间件会自动刷新令牌,但由于底层 OpenID Connect 认证处理程序的限制,用户对象中的声明 (Claims) 不会更新。 一旦我们编写自己的认证处理程序,这个问题就可以解决。
注意,上述访问令牌 (access token) 是用于 OpenID Connect 中 userinfo 端点的不透明令牌 (Opaque token),而不是 JWT 令牌。如果你指定了 API 资源 (API resource),需要使用 LogtoParameters.Tokens.AccessTokenForResource
来获取 API 资源的访问令牌 (access token):
var accessToken = await HttpContext.GetTokenAsync(LogtoParameters.Tokens.AccessTokenForResource);
此令牌将是一个以 API 资源 (API resource) 为受众 (Audience) 的 JWT 令牌。