ข้ามไปยังเนื้อหาหลัก

เพิ่มการยืนยันตัวตนให้กับแอป .NET Core (Blazor WASM) ของคุณ (Add authentication to your .NET Core (Blazor WASM) application)

เคล็ดลับ:
  • ตัวอย่างสาธิตต่อไปนี้สร้างขึ้นบน .NET Core 8.0 และ Blorc.OpenIdConnect
  • โปรเจกต์ตัวอย่าง .NET Core มีให้ใน GitHub repository

ข้อกำหนดเบื้องต้น​

การติดตั้ง​

เพิ่มแพ็กเกจ NuGet ลงในโปรเจกต์ของคุณ:

dotnet add package Blorc.OpenIdConnect

การผสานรวม​

เพิ่มการอ้างอิงสคริปต์​

เพิ่ม Blorc.Core/injector.js ลงในไฟล์ index.html:

index.html
<head>
<!-- ... -->
<script src="_content/Blorc.Core/injector.js"></script>
<!-- ... -->
</head>

ลงทะเบียนบริการ​

เพิ่มโค้ดต่อไปนี้ในไฟล์ Program.cs:

Program.cs
using Blorc.OpenIdConnect;
using Blorc.Services;

builder.Services.AddBlorcCore();
builder.Services.AddAuthorizationCore();
builder.Services.AddBlorcOpenIdConnect(
options =>
{
builder.Configuration.Bind("IdentityServer", options);
});

var webAssemblyHost = builder.Build();

await webAssemblyHost
.ConfigureDocumentAsync(async documentService =>
{
await documentService.InjectBlorcCoreJsAsync();
await documentService.InjectOpenIdConnectAsync();
});

await webAssemblyHost.RunAsync();
ข้อมูล:

ไม่จำเป็นต้องใช้แพ็กเกจ Microsoft.AspNetCore.Components.WebAssembly.Authentication แพ็กเกจ Blorc.OpenIdConnect จะดูแลกระบวนการยืนยันตัวตนให้เอง

กำหนดค่า redirect URI​

ก่อนที่เราจะลงลึกในรายละเอียด นี่คือภาพรวมประสบการณ์ของผู้ใช้ปลายทาง กระบวนการลงชื่อเข้าใช้สามารถสรุปได้ดังนี้:

  1. แอปของคุณเรียกใช้งานเมธอดลงชื่อเข้าใช้
  2. ผู้ใช้จะถูกเปลี่ยนเส้นทางไปยังหน้าลงชื่อเข้าใช้ของ Logto สำหรับแอปเนทีฟ ระบบจะเปิดเบราว์เซอร์ของระบบ
  3. ผู้ใช้ลงชื่อเข้าใช้และถูกเปลี่ยนเส้นทางกลับไปยังแอปของคุณ (ตามที่กำหนดไว้ใน redirect URI)

เกี่ยวกับการลงชื่อเข้าใช้แบบเปลี่ยนเส้นทาง (redirect-based sign-in)​

  1. กระบวนการยืนยันตัวตนนี้เป็นไปตามโปรโตคอล OpenID Connect (OIDC) และ Logto บังคับใช้มาตรการรักษาความปลอดภัยอย่างเข้มงวดเพื่อปกป้องการลงชื่อเข้าใช้ของผู้ใช้
  2. หากคุณมีหลายแอป คุณสามารถใช้ผู้ให้บริการข้อมูลระบุตัวตน (Logto) เดียวกันได้ เมื่อผู้ใช้ลงชื่อเข้าใช้แอปหนึ่งแล้ว Logto จะดำเนินการลงชื่อเข้าใช้โดยอัตโนมัติเมื่อผู้ใช้เข้าถึงแอปอื่น

หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับเหตุผลและประโยชน์ของการลงชื่อเข้าใช้แบบเปลี่ยนเส้นทาง โปรดดูที่ อธิบายประสบการณ์การลงชื่อเข้าใช้ของ Logto


บันทึก:

ในตัวอย่างโค้ดต่อไปนี้ เราถือว่าแอปของคุณกำลังทำงานอยู่ที่ http://localhost:3000/

กำหนดค่า Redirect URI​

ไปที่หน้ารายละเอียดแอปพลิเคชันใน Logto Console เพิ่ม redirect URI http://localhost:3000/callback

Redirect URI in Logto Console

เช่นเดียวกับการลงชื่อเข้าใช้ ผู้ใช้ควรถูกเปลี่ยนเส้นทางไปที่ Logto เพื่อออกจากเซสชันที่ใช้ร่วมกัน เมื่อเสร็จสิ้นแล้ว ควรเปลี่ยนเส้นทางผู้ใช้กลับไปยังเว็บไซต์ของคุณ ตัวอย่างเช่น เพิ่ม http://localhost:3000/ ในส่วน post sign-out redirect URI

จากนั้นคลิก "Save" เพื่อบันทึกการเปลี่ยนแปลง

กำหนดค่าแอปพลิเคชัน​

เพิ่มโค้ดต่อไปนี้ในไฟล์ appsettings.json:

appsettings.json
{
// ...
IdentityServer: {
Authority: 'https://<your-logto-endpoint>/oidc',
ClientId: '<your-logto-app-id>',
PostLogoutRedirectUri: 'http://localhost:3000/',
RedirectUri: 'http://localhost:3000/callback',
ResponseType: 'code',
Scope: 'openid profile', // เพิ่มขอบเขต (scopes) เพิ่มเติมหากต้องการ
},
}

อย่าลืมเพิ่ม RedirectUri และ PostLogoutRedirectUri ลงในรายการ redirect URI ที่อนุญาตในหน้าตั้งค่าแอป Logto ทั้งสองคือ URL ของแอป WASM ของคุณ

เพิ่มคอมโพเนนต์ AuthorizeView​

ในหน้า Razor ที่ต้องการการยืนยันตัวตน ให้เพิ่มคอมโพเนนต์ AuthorizeView สมมติว่าเป็นหน้า Home.razor:

Pages/Home.razor
@using Microsoft.AspNetCore.Components.Authorization
@page "/"

<AuthorizeView>
<Authorized>
@* มุมมองเมื่อเข้าสู่ระบบแล้ว *@
<button @onclick="OnLogoutButtonClickAsync">
Sign out
</button>
</Authorized>
<NotAuthorized>
@* มุมมองเมื่อยังไม่ได้เข้าสู่ระบบ *@
<button @onclick="OnLoginButtonClickAsync">
Sign in
</button>
</NotAuthorized>
</AuthorizeView>

ตั้งค่าการยืนยันตัวตน​

ในไฟล์ Home.razor.cs (สร้างไฟล์นี้หากยังไม่มี) เพิ่มโค้ดต่อไปนี้:

Pages/Home.razor.cs
// using ต่าง ๆ เหมือนเดิม

[Authorize]
public partial class Home : ComponentBase
{
[Inject]
public required IUserManager UserManager { get; set; }

public User<Profile>? User { get; set; }

[CascadingParameter]
protected Task<AuthenticationState>? AuthenticationStateTask { get; set; }

protected override async Task OnInitializedAsync()
{
User = await UserManager.GetUserAsync<User<Profile>>(AuthenticationStateTask!);
}

private async Task OnLoginButtonClickAsync(MouseEventArgs obj)
{
await UserManager.SignInRedirectAsync();
}

private async Task OnLogoutButtonClickAsync(MouseEventArgs obj)
{
await UserManager.SignOutRedirectAsync();
}
}

เมื่อผู้ใช้ได้รับการยืนยันตัวตนแล้ว property User จะถูกเติมข้อมูลผู้ใช้โดยอัตโนมัติ

จุดตรวจสอบ: ทดสอบแอปพลิเคชันของคุณ​

ตอนนี้คุณสามารถทดสอบแอปพลิเคชันของคุณได้แล้ว:

  1. รันแอปพลิเคชันของคุณ คุณจะเห็นปุ่มลงชื่อเข้าใช้
  2. คลิกปุ่มลงชื่อเข้าใช้ SDK จะเริ่มกระบวนการลงชื่อเข้าใช้และเปลี่ยนเส้นทางคุณไปยังหน้าลงชื่อเข้าใช้ของ Logto
  3. หลังจากที่คุณลงชื่อเข้าใช้แล้ว คุณจะถูกเปลี่ยนเส้นทางกลับไปยังแอปพลิเคชันของคุณและเห็นปุ่มลงชื่อออก
  4. คลิกปุ่มลงชื่อออกเพื่อเคลียร์ที่เก็บโทเค็นและออกจากระบบ

รับข้อมูลผู้ใช้​

แสดงข้อมูลผู้ใช้​

ตัวอย่างต่อไปนี้แสดงวิธีแสดงข้อมูลผู้ใช้ในหน้า Home.razor:

<AuthorizeView>
<Authorized>
@* มุมมองเมื่อเข้าสู่ระบบแล้ว *@
@* ... *@
<p>คุณได้เข้าสู่ระบบในชื่อ @(@User?.Profile?.Name ?? "(ไม่ทราบชื่อ)").</p>
</Authorized>
@* ... *@
</AuthorizeView>

สำหรับพร็อพเพอร์ตี้และการอ้างสิทธิ์ (claims) อื่น ๆ เพิ่มเติม โปรดตรวจสอบคลาส User และ Profile ในแพ็กเกจ Blorc.OpenIdConnect

ขอการอ้างสิทธิ์เพิ่มเติม​

คุณอาจพบว่าข้อมูลผู้ใช้บางอย่างหายไปในอ็อบเจกต์ที่ส่งคืนจาก User สาเหตุเนื่องจาก OAuth 2.0 และ OpenID Connect (OIDC) ถูกออกแบบมาให้สอดคล้องกับหลักการสิทธิ์น้อยที่สุด (principle of least privilege; PoLP) และ Logto ถูกสร้างขึ้นบนมาตรฐานเหล่านี้

โดยปกติแล้ว จะมีการส่งคืนการอ้างสิทธิ์ (claim) แบบจำกัด หากคุณต้องการข้อมูลเพิ่มเติม คุณสามารถร้องขอขอบเขต (scope) เพิ่มเติมเพื่อเข้าถึงการอ้างสิทธิ์ (claim) ที่มากขึ้นได้

ข้อมูล:

"การอ้างสิทธิ์ (Claim)" คือการยืนยันข้อมูลบางอย่างเกี่ยวกับผู้ถูกอ้างถึง (subject); "ขอบเขต (Scope)" คือกลุ่มของการอ้างสิทธิ์ (claim) ในกรณีนี้ การอ้างสิทธิ์ (claim) คือข้อมูลบางอย่างเกี่ยวกับผู้ใช้

ตัวอย่างที่ไม่เป็นทางการของความสัมพันธ์ระหว่างขอบเขต (scope) กับการอ้างสิทธิ์ (claim) มีดังนี้:

เคล็ดลับ:

การอ้างสิทธิ์ (claim) "sub" หมายถึง "ผู้ถูกอ้างถึง (subject)" ซึ่งคือตัวระบุที่ไม่ซ้ำของผู้ใช้ (เช่น user ID)

Logto SDK จะร้องขอขอบเขต (scope) สามรายการเสมอ ได้แก่ openid, profile และ offline_access

หากต้องการขอขอบเขต (scopes) เพิ่มเติม คุณสามารถเพิ่ม scopes ที่ถูกต้องลงในพร็อพเพอร์ตี้ IdentityServer.Scope ในไฟล์ appsettings.json

{
// ...
"IdentityServer": {
// ...
"Scope": "openid profile email phone"
}
}

การอ้างสิทธิ์ที่ต้องร้องขอผ่านเครือข่าย​

เพื่อป้องกันไม่ให้วัตถุผู้ใช้มีขนาดใหญ่เกินไป การอ้างสิทธิ์บางอย่างจำเป็นต้องร้องขอผ่านเครือข่าย เช่น การอ้างสิทธิ์ custom_data จะไม่ถูกรวมอยู่ในวัตถุผู้ใช้ แม้ว่าจะร้องขอไว้ใน scopes ก็ตาม หากต้องการดึงการอ้างสิทธิ์เหล่านี้ คุณสามารถตั้งค่า IdentityServer.LoadUserInfo เป็น true ในไฟล์ appsettings.json

ตัวอย่างเช่น หากต้องการดึงที่อยู่อีเมลและ custom data ของผู้ใช้ สามารถใช้การตั้งค่าดังนี้:

{
// ...
"IdentityServer": {
// ...
"Scope": "openid profile email custom_data",
"LoadUserInfo": true
}
}

ขอบเขตและการอ้างสิทธิ์​

Logto ใช้มาตรฐาน ขอบเขต (scopes) และ การอ้างสิทธิ์ (claims) ของ OIDC เพื่อกำหนดขอบเขตและการอ้างสิทธิ์สำหรับดึงข้อมูลผู้ใช้จากโทเค็น ID (ID token) และ OIDC userinfo endpoint ทั้ง "ขอบเขต (scope)" และ "การอ้างสิทธิ์ (claim)" เป็นคำศัพท์จากข้อกำหนดของ OAuth 2.0 และ OpenID Connect (OIDC)

ต่อไปนี้คือรายการขอบเขต (Scopes) ที่รองรับและการอ้างสิทธิ์ (Claims) ที่เกี่ยวข้อง:

openid

ชื่อการอ้างสิทธิ์ประเภทคำอธิบายต้องใช้ userinfo หรือไม่?
substringตัวระบุที่ไม่ซ้ำของผู้ใช้ไม่

profile

ชื่อการอ้างสิทธิ์ประเภทคำอธิบายต้องใช้ userinfo หรือไม่?
namestringชื่อเต็มของผู้ใช้ไม่
usernamestringชื่อผู้ใช้ของผู้ใช้ไม่
picturestringURL ของรูปโปรไฟล์ของผู้ใช้ปลายทาง URL นี้ ต้อง อ้างอิงถึงไฟล์รูปภาพ (เช่น ไฟล์ PNG, JPEG หรือ GIF) ไม่ใช่หน้าเว็บที่มีรูปภาพ โปรดทราบว่า URL นี้ ควร อ้างอิงถึงรูปโปรไฟล์ของผู้ใช้ปลายทางที่เหมาะสมสำหรับการแสดงผลเมื่ออธิบายผู้ใช้ปลายทาง ไม่ใช่รูปภาพใด ๆ ที่ผู้ใช้ถ่ายเองไม่
created_atnumberเวลาที่สร้างผู้ใช้ปลายทาง เวลานี้แสดงเป็นจำนวนมิลลิวินาทีตั้งแต่ Unix epoch (1970-01-01T00:00:00Z)ไม่
updated_atnumberเวลาที่ข้อมูลของผู้ใช้ปลายทางถูกอัปเดตล่าสุด เวลานี้แสดงเป็นจำนวนมิลลิวินาทีตั้งแต่ Unix epoch (1970-01-01T00:00:00Z)ไม่

การอ้างสิทธิ์มาตรฐาน อื่น ๆ เช่น family_name, given_name, middle_name, nickname, preferred_username, profile, website, gender, birthdate, zoneinfo, และ locale จะถูกรวมอยู่ในขอบเขต profile ด้วยโดยไม่ต้องร้องขอ endpoint userinfo ความแตกต่างเมื่อเทียบกับการอ้างสิทธิ์ข้างต้นคือ การอ้างสิทธิ์เหล่านี้จะถูกส่งกลับมาเฉพาะเมื่อค่าของมันไม่ว่างเปล่า ในขณะที่การอ้างสิทธิ์ข้างต้นจะส่งกลับ null หากค่าเป็นค่าว่าง

บันทึก:

ต่างจากการอ้างสิทธิ์มาตรฐาน การอ้างสิทธิ์ created_at และ updated_at ใช้หน่วยเป็นมิลลิวินาทีแทนที่จะเป็นวินาที

email

ชื่อการอ้างสิทธิ์ประเภทคำอธิบายต้องใช้ userinfo หรือไม่?
emailstringอีเมลของผู้ใช้ไม่
email_verifiedbooleanอีเมลได้รับการยืนยันแล้วหรือไม่ไม่

phone

ชื่อการอ้างสิทธิ์ประเภทคำอธิบายต้องใช้ userinfo หรือไม่?
phone_numberstringหมายเลขโทรศัพท์ของผู้ใช้ไม่
phone_number_verifiedbooleanหมายเลขโทรศัพท์ได้รับการยืนยันแล้วหรือไม่ไม่

address

โปรดดูรายละเอียดของการอ้างสิทธิ์ที่อยู่ได้ที่ OpenID Connect Core 1.0

custom_data

ชื่อการอ้างสิทธิ์ประเภทคำอธิบายต้องใช้ userinfo หรือไม่?
custom_dataobjectข้อมูลกำหนดเองของผู้ใช้ใช่

identities

ชื่อการอ้างสิทธิ์ประเภทคำอธิบายต้องใช้ userinfo หรือไม่?
identitiesobjectข้อมูลตัวตนที่เชื่อมโยงของผู้ใช้ใช่
sso_identitiesarrayข้อมูล SSO ที่เชื่อมโยงของผู้ใช้ใช่

roles

ชื่อการอ้างสิทธิ์ประเภทคำอธิบายต้องใช้ userinfo หรือไม่?
rolesstring[]บทบาทของผู้ใช้ไม่

urn:logto:scope:organizations

ชื่อการอ้างสิทธิ์ประเภทคำอธิบายต้องใช้ userinfo หรือไม่?
organizationsstring[]รหัสองค์กรที่ผู้ใช้สังกัดไม่
organization_dataobject[]ข้อมูลขององค์กรที่ผู้ใช้สังกัดใช่

urn:logto:scope:organization_roles

ชื่อการอ้างสิทธิ์ประเภทคำอธิบายต้องใช้ userinfo หรือไม่?
organization_rolesstring[]บทบาทของผู้ใช้ในแต่ละองค์กรในรูปแบบ <organization_id>:<role_name>ไม่

เพื่อประสิทธิภาพและขนาดข้อมูล หาก "ต้องใช้ userinfo หรือไม่?" เป็น "ใช่" หมายความว่าการอ้างสิทธิ์นั้นจะไม่ปรากฏในโทเค็น ID แต่จะถูกส่งกลับใน response ของ userinfo endpoint

ทรัพยากร API​

เราแนะนำให้อ่าน 🔐 การควบคุมการเข้าถึงตามบทบาท (RBAC) ก่อน เพื่อทำความเข้าใจแนวคิดพื้นฐานของ RBAC ใน Logto และวิธีตั้งค่าทรัพยากร API อย่างถูกต้อง

โดยปกติ เมื่อคุณเข้าถึง User?.AccessToken คุณจะได้รับโทเค็นทึบ (Opaque token) ซึ่งมีความยาวสั้นและไม่ใช่ JWT (JSON Web Token) โทเค็นนี้ใช้สำหรับเข้าถึง userinfo endpoint

เพิ่มทรัพยากร API (API resource) ลงในการตั้งค่า​

หากต้องการรับ JWT ที่สามารถใช้เข้าถึงทรัพยากร API ที่กำหนดไว้ใน Logto ให้เพิ่มพารามิเตอร์ต่อไปนี้ลงในไฟล์ appsettings.json (โดยใช้ https://my-api-resource เป็นตัวอย่าง):

appsettings.json
{
// ...
"IdentityServer": {
// ...
"Scope": "openid profile email <your-api-scopes>", // เพิ่มขอบเขต API ของคุณที่นี่
"Resource": "https://my-api-resource",
"ExtraTokenParams": {
"resource": "https://my-api-resource" // ตรวจสอบให้แน่ใจว่า key "resource" เป็นตัวพิมพ์เล็กทั้งหมด
}
}
}

พร็อพเพอร์ตี้ Resource ใช้สำหรับเพิ่มทรัพยากร API ลงในคำขอการยืนยันตัวตน (auth request) ส่วนพร็อพเพอร์ตี้ ExtraTokenParams ใช้สำหรับเพิ่มทรัพยากร API ลงในคำขอโทเค็น (token request) เนื่องจาก Logto ปฏิบัติตาม RFC 8707 สำหรับทรัพยากร API จึงต้องกำหนดทั้งสองพร็อพเพอร์ตี้นี้

ข้อควรระวัง:

เนื่องจาก WebAssembly เป็นแอปพลิเคชันฝั่งไคลเอนต์ คำขอโทเค็นจะถูกส่งไปยังฝั่งเซิร์ฟเวอร์เพียงครั้งเดียว ด้วยเหตุนี้ LoadUserInfo จะขัดแย้งกับการดึงโทเค็นการเข้าถึง (Access token) สำหรับทรัพยากร API

ใช้โทเค็นการเข้าถึง (Access token)​

เมื่อผู้ใช้ได้รับการยืนยันตัวตนแล้ว คุณสามารถเข้าถึงทรัพยากร API ได้โดยใช้พร็อพเพอร์ตี้ User?.AccessToken ตัวอย่างเช่น คุณสามารถใช้ HttpClient เพื่อเข้าถึงทรัพยากร API ได้ดังนี้:

using Blorc.OpenIdConnect;

// เพิ่ม HttpClient สำหรับทรัพยากร API ของคุณ
builder.Services
.AddHttpClient("MyApiResource", client =>
{
client.BaseAddress = new Uri("https://my-api-resource");
})
.AddAccessToken(); // เพิ่มโทเค็นการเข้าถึงใน request header

อ่านเพิ่มเติม​

กระบวนการสำหรับผู้ใช้ปลายทาง: กระบวนการยืนยันตัวตน, กระบวนการบัญชี, และกระบวนการองค์กร ตั้งค่าตัวเชื่อมต่อ การอนุญาต (Authorization)