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

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

คู่มือนี้จะแสดงวิธีการผสาน Logto เข้ากับแอป React ของคุณ

เคล็ดลับ:
  • โปรเจกต์ตัวอย่างสามารถดูได้ที่ SDK repository ของเรา
  • วิดีโอแนะนำสามารถรับชมได้ที่ ช่อง YouTube ของเรา

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

การติดตั้ง

ติดตั้ง Logto SDK ผ่านตัวจัดการแพ็กเกจที่คุณชื่นชอบ:

npm i @logto/react

การผสานรวม

เริ่มต้น Logto provider

นำเข้าและใช้ LogtoProvider เพื่อให้บริบท Logto กับแอปของคุณ:

App.tsx
import { LogtoProvider, LogtoConfig } from '@logto/react';

const config: LogtoConfig = {
endpoint: '<your-logto-endpoint>', // เช่น http://localhost:3001
appId: '<your-application-id>',
};

const App = () => (
<LogtoProvider config={config}>
<YourAppContent />
</LogtoProvider>
);

กำหนดค่า Redirect URIs

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

  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" เพื่อบันทึกการเปลี่ยนแปลง

จัดการ Redirect

เนื่องจากเราใช้ http://localhost:3000/callback เป็น redirect URI ตอนนี้เราจำเป็นต้องจัดการเส้นทางนี้อย่างถูกต้อง

ก่อนอื่น มาสร้างหน้าคอลแบ็กกันก่อน:

pages/Callback/index.tsx
import { useHandleSignInCallback } from '@logto/react';

const Callback = () => {
const { isLoading } = useHandleSignInCallback(() => {
// ทำบางอย่างเมื่อเสร็จสิ้น เช่น เปลี่ยนเส้นทางไปยังหน้าแรก
});

// ขณะกำลังดำเนินการ
if (isLoading) {
return <div>กำลังเปลี่ยนเส้นทาง...</div>;
}

return null;
};

สุดท้าย ใส่โค้ดด้านล่างเพื่อสร้าง route /callback ซึ่ง ไม่ต้องการการยืนยันตัวตน (authentication):

App.tsx
// สมมติว่าใช้ react-router
<Route path="/callback" element={<Callback />} />

สร้างฟังก์ชันลงชื่อเข้าใช้และออกจากระบบ

เรามี hook สองตัวคือ useHandleSignInCallback() และ useLogto() ซึ่งช่วยให้คุณจัดการโฟลว์การยืนยันตัวตน (Authentication) ได้อย่างง่ายดาย

บันทึก:

ก่อนเรียก .signIn() โปรดตรวจสอบให้แน่ใจว่าคุณได้กำหนดค่า Redirect URI ใน Admin Console อย่างถูกต้องแล้ว

pages/Home/index.tsx
import { useLogto } from '@logto/react';

const Home = () => {
const { signIn, signOut, isAuthenticated } = useLogto();

return isAuthenticated ? (
<button onClick={signOut}>Sign Out</button>
) : (
<button onClick={() => signIn('http://localhost:3000/callback')}>Sign In</button>
);
};

การเรียกใช้ .signOut() จะล้างข้อมูล Logto ทั้งหมดในหน่วยความจำและ localStorage หากมีอยู่

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

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

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

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

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

หากต้องการแสดงข้อมูลของผู้ใช้ คุณสามารถใช้เมธอด getIdTokenClaims() ตัวอย่างเช่น ในหน้า Home ของคุณ:

pages/Home/index.tsx
import { useLogto, type IdTokenClaims } from '@logto/react';
import { useEffect, useState } from 'react';

// ...
const Home = () => {
const { isAuthenticated, getIdTokenClaims } = useLogto();
const [user, setUser] = useState<IdTokenClaims>();

useEffect(() => {
(async () => {
if (isAuthenticated) {
const claims = await getIdTokenClaims();
setUser(claims);
}
})();
}, [getIdTokenClaims, isAuthenticated]);

return (
// ...
{isAuthenticated && user && (
<table>
<thead>
<tr>
<th>ชื่อ</th>
<th>ค่า</th>
</tr>
</thead>
<tbody>
{Object.entries(user).map(([key, value]) => (
<tr key={key}>
<td>{key}</td>
<td>{typeof value === 'string' ? value : JSON.stringify(value)}</td>
</tr>
))}
</tbody>
</table>
)}
);
}

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

คุณอาจพบว่าข้อมูลผู้ใช้บางอย่างหายไปในอ็อบเจกต์ที่ส่งคืนจาก getIdTokenClaims() สาเหตุเนื่องจาก 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) เพิ่มเติม คุณสามารถกำหนดค่า provider ของ Logto ได้ดังนี้:

App.tsx
import { LogtoConfig, UserScope } from '@logto/react';

const config: LogtoConfig = {
// ...other configs
scopes: [
UserScope.Email,
UserScope.Phone,
UserScope.CustomData,
UserScope.Identities,
UserScope.Organizations,
],
};

จากนั้นคุณสามารถเข้าถึงการอ้างสิทธิ์เพิ่มเติมในค่าที่คืนมาจาก getIdTokenClaims() ได้:

const claims = await getIdTokenClaims();
// ตอนนี้คุณสามารถเข้าถึงการอ้างสิทธิ์เพิ่มเติม เช่น `claims.email`, `claims.phone` เป็นต้น

การอ้างสิทธิ์ (Claims) ที่ต้องใช้การร้องขอผ่านเครือข่าย

เพื่อป้องกันไม่ให้โทเค็น ID (ID token) มีขนาดใหญ่เกินไป การอ้างสิทธิ์บางรายการจำเป็นต้องร้องขอผ่านเครือข่ายเพื่อดึงข้อมูล ตัวอย่างเช่น การอ้างสิทธิ์ custom_data จะไม่ถูกรวมอยู่ในอ็อบเจกต์ผู้ใช้ แม้ว่าจะร้องขอไว้ในขอบเขต (scopes) ก็ตาม หากต้องการเข้าถึงการอ้างสิทธิ์เหล่านี้ คุณสามารถใช้เมธอด fetchUserInfo():

const { fetchUserInfo } = useLogto();

const userInfo = await fetchUserInfo();

// ตอนนี้คุณสามารถเข้าถึงการอ้างสิทธิ์ `userInfo.custom_data`
เมธอดนี้จะดึงข้อมูลผู้ใช้โดยการร้องขอไปยัง จุดปลาย userinfo หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับขอบเขต (scopes) และการอ้างสิทธิ์ (claims) ที่มีอยู่ ดูที่หัวข้อ ขอบเขตและการอ้างสิทธิ์

ขอบเขต (Scopes) และการอ้างสิทธิ์ (Claims) {scopes-and-claims}

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 อย่างถูกต้อง

กำหนดค่า Logto client

เมื่อคุณตั้งค่า ทรัพยากร API (API resources) เรียบร้อยแล้ว คุณสามารถเพิ่มทรัพยากรเหล่านี้ขณะกำหนดค่า Logto ในแอปของคุณได้:

App.tsx
import { LogtoConfig } from '@logto/react';

const config: LogtoConfig = {
// ...other configs
resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'], // เพิ่มทรัพยากร API (Add API resources)
};

แต่ละ ทรัพยากร API (API resource) จะมี สิทธิ์ (scopes) ของตัวเอง

ตัวอย่างเช่น ทรัพยากร https://shopping.your-app.com/api มีสิทธิ์ shopping:read และ shopping:write และทรัพยากร https://store.your-app.com/api มีสิทธิ์ store:read และ store:write

หากต้องการร้องขอสิทธิ์เหล่านี้ คุณสามารถเพิ่มขณะกำหนดค่า Logto ในแอปของคุณได้:

App.tsx
import { LogtoConfig } from '@logto/react';

const config: LogtoConfig = {
// ...other configs
scopes: ['shopping:read', 'shopping:write', 'store:read', 'store:write'],
resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'],
};

คุณอาจสังเกตได้ว่า ขอบเขต (scopes) ถูกกำหนดแยกจาก ทรัพยากร API (API resources) นี่เป็นเพราะ Resource Indicators for OAuth 2.0 ระบุว่า ขอบเขตสุดท้ายสำหรับคำขอจะเป็นผลคูณคาร์ทีเซียนของขอบเขตทั้งหมดในบริการเป้าหมายทั้งหมด

ดังนั้น ในกรณีข้างต้น ขอบเขต (scopes) สามารถทำให้เรียบง่ายขึ้นจากการกำหนดใน Logto โดยทั้งสอง ทรัพยากร API (API resources) สามารถมีขอบเขต read และ write ได้โดยไม่ต้องมีคำนำหน้า จากนั้น ในการตั้งค่า Logto:

App.tsx
import { LogtoConfig } from '@logto/react';

const config: LogtoConfig = {
// ...other configs
scopes: ['read', 'write'], // ขอบเขต (scopes)
resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'], // ทรัพยากร (resources)
};

สำหรับแต่ละ ทรัพยากร API (API resource) จะร้องขอทั้งขอบเขต read และ write

บันทึก:

คุณสามารถร้องขอขอบเขต (scopes) ที่ไม่ได้กำหนดไว้ใน ทรัพยากร API (API resources) ได้ เช่น คุณสามารถร้องขอขอบเขต email ได้ แม้ว่า ทรัพยากร API (API resources) จะไม่มีขอบเขต email ให้ ขอบเขตที่ไม่มีจะถูกละเว้นอย่างปลอดภัย

หลังจากลงชื่อเข้าใช้สำเร็จ Logto จะออกขอบเขตที่เหมาะสมให้กับ ทรัพยากร API (API resources) ตามบทบาทของผู้ใช้

ดึงโทเค็นการเข้าถึง (Access token) สำหรับทรัพยากร API

เพื่อดึงโทเค็นการเข้าถึง (Access token) สำหรับทรัพยากร API เฉพาะ คุณสามารถใช้เมธอด getAccessToken ได้ดังนี้:

pages/Home/index.tsx
import { useLogto } from '@logto/react';

const Home = () => {
const { isAuthenticated, getAccessToken } = useLogto();
const [accessToken, setAccessToken] = useState('');

useEffect(() => {
(async () => {
if (isAuthenticated) {
const token = await getAccessToken('https://shopping.your-app.com/api');
setAccessToken(token);
}
})();
}, [isAuthenticated, getAccessToken]);

return <p>{{ accessToken }}</p>;
};

เมธอดนี้จะส่งคืนโทเค็นการเข้าถึง (JWT access token) ที่สามารถใช้เข้าถึงทรัพยากร API ได้เมื่อผู้ใช้มีสิทธิ์ที่เกี่ยวข้อง หากโทเค็นการเข้าถึงที่แคชไว้หมดอายุแล้ว เมธอดนี้จะพยายามใช้โทเค็นรีเฟรช (Refresh token) เพื่อขอโทเค็นการเข้าถึงใหม่โดยอัตโนมัติ

ดึงโทเค็นองค์กร (Organization tokens)

หากคุณยังไม่คุ้นเคยกับ องค์กร (Organization) โปรดอ่าน 🏢 องค์กร (หลายผู้เช่า; Multi-tenancy) เพื่อเริ่มต้น

คุณต้องเพิ่ม UserScope.Organizations ขอบเขต (scope) ขณะตั้งค่า Logto client:

App.tsx
import { LogtoConfig, UserScope } from '@logto/react';

const config: LogtoConfig = {
// ...other configs
scopes: [UserScope.Organizations], // ขอบเขต (scopes) ที่ร้องขอข้อมูลองค์กร (Organizations)
};

เมื่อผู้ใช้ลงชื่อเข้าใช้แล้ว คุณสามารถดึงโทเค็นองค์กร (organization token) สำหรับผู้ใช้ได้:

pages/Organizations/index.tsx
import { useLogto } from '@logto/react';
import { useEffect, useState } from 'react';

const Organizations = () => {
const { isAuthenticated, getOrganizationToken, getIdTokenClaims } = useLogto();
const [organizationIds, setOrganizationIds] = useState<string[]>();

useEffect(() => {
(async () => {
if (!isAuthenticated) {
return;
}
const claims = await getIdTokenClaims();

// แสดงข้อมูลการอ้างสิทธิ์ของโทเค็น ID
console.log('ID token claims', claims);
setOrganizationIds(claims?.organizations);
})();
}, [isAuthenticated, getIdTokenClaims]);

return (
<section>
<ul>
{organizationIds?.map((organizationId) => {
return (
<li key={organizationId}>
<span>{organizationId}</span>
<button
type="button"
onClick={async () => {
// ดึงโทเค็น (ดูที่คอนโซล)
console.log('raw token', await getOrganizationToken(organizationId));
}}
>
ดึงโทเค็น (ดูที่คอนโซล)
</button>
</li>
);
})}
</ul>
</section>
);
};

export default Organizations;

แนบโทเค็นการเข้าถึง (Access token) ไปกับ request headers

ให้นำโทเค็นไปใส่ในฟิลด์ Authorization ของ HTTP headers โดยใช้รูปแบบ Bearer (Bearer YOUR_TOKEN) ก็พร้อมใช้งานทันที

บันทึก:

ขั้นตอนการใช้งาน Bearer Token อาจแตกต่างกันไปตาม framework หรือ requester ที่คุณใช้ เลือกวิธีที่เหมาะสมในการใส่ request header Authorization

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

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