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

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

เคล็ดลับ:

• การสาธิตต่อไปนี้ทดสอบบน Chrome v123.0.6312.87 (arm64) เวอร์ชันอื่น ๆ ก็ควรใช้งานได้ ตราบใดที่รองรับ chrome API ที่ใช้ใน SDK
• โปรเจกต์ตัวอย่างสามารถดูได้ที่ GitHub repository ของเรา

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

• บัญชี Logto Cloud หรือ Logto ที่โฮสต์เอง
• แอปพลิเคชันหน้าเดียว (SPA) ที่สร้างใน Logto Console
• โปรเจกต์ส่วนขยาย Chrome

การติดตั้ง

npm

npm i @logto/chrome-extension

Yarn

yarn add @logto/chrome-extension

pnpm

pnpm add @logto/chrome-extension

การผสานรวม

โฟลว์การยืนยันตัวตน (The authentication flow)

สมมติว่าคุณใส่ปุ่ม "Sign in" ใน popup ของ Chrome extension ของคุณ โฟลว์การยืนยันตัวตนจะมีลักษณะดังนี้:

สำหรับหน้า interactive อื่น ๆ ใน extension ของคุณ เพียงแค่เปลี่ยนชื่อ Extension popup เป็นชื่อหน้าที่ต้องการ ในคู่มือนี้เราจะเน้นที่หน้า popup

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

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

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

อัปเดต manifest.json

Logto SDK ต้องการ permission ต่อไปนี้ใน manifest.json:

manifest.json

{
  "permissions": ["identity", "storage"],
  "host_permissions": ["https://*.logto.app/*"]
}

• permissions.identity: จำเป็นสำหรับ Chrome Identity API ซึ่งใช้สำหรับลงชื่อเข้าใช้และออกจากระบบ
• permissions.storage: จำเป็นสำหรับจัดเก็บ session ของผู้ใช้
• host_permissions: จำเป็นสำหรับ Logto SDK เพื่อสื่อสารกับ Logto APIs

บันทึก:

หากคุณใช้โดเมนแบบกำหนดเองบน Logto Cloud คุณต้องอัปเดต host_permissions ให้ตรงกับโดเมนของคุณ

ตั้งค่า background script (service worker)

ใน background script ของ Chrome extension ของคุณ ให้เริ่มต้น Logto SDK ดังนี้:

service-worker.js

import LogtoClient from '@logto/chrome-extension';

export const logtoClient = new LogtoClient({
  endpoint: '<your-logto-endpoint>'
  appId: '<your-logto-app-id>',
});

แทนที่ <your-logto-endpoint> และ <your-logto-app-id> ด้วยค่าจริง คุณสามารถดูค่าดังกล่าวได้ในหน้าแอปพลิเคชันที่คุณสร้างไว้ใน Logto Console

หากคุณยังไม่มี background script สามารถดู คู่มืออย่างเป็นทางการ เพื่อสร้างได้

ข้อมูล:

ทำไมต้องมี background script?

หน้า extension ปกติ เช่น popup หรือ options page ไม่สามารถทำงานเบื้องหลังได้ และอาจถูกปิดระหว่างกระบวนการยืนยันตัวตน background script จะช่วยให้กระบวนการยืนยันตัวตนทำงานได้อย่างถูกต้อง

จากนั้น เราต้องฟังข้อความจากหน้า extension อื่น ๆ และจัดการกระบวนการยืนยันตัวตน:

service-worker.js

chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
  // ในโค้ดด้านล่าง เนื่องจากเราคืนค่า `true` สำหรับแต่ละ action เราต้องเรียก `sendResponse`
  // เพื่อแจ้งผู้ส่ง คุณสามารถจัดการ error ที่นี่ หรือใช้วิธีอื่นแจ้งผู้ส่งก็ได้

  if (message.action === 'signIn') {
    const redirectUri = chrome.identity.getRedirectURL('/callback');
    logtoClient.signIn(redirectUri).finally(sendResponse);
    return true;
  }

  if (message.action === 'signOut') {
    const redirectUri = chrome.identity.getRedirectURL();
    logtoClient.signOut(redirectUri).finally(sendResponse);
    return true;
  }

  return false;
});

คุณจะสังเกตเห็นว่ามี redirect URI สองแบบในโค้ดข้างต้น ทั้งสองถูกสร้างโดย chrome.identity.getRedirectURL ซึ่งเป็น Chrome API ในตัว สำหรับสร้าง redirect URL สำหรับ auth flow โดยสอง URI จะเป็น:

• https://<extension-id>.chromiumapp.org/callback สำหรับ sign-in
• https://<extension-id>.chromiumapp.org/ สำหรับ sign-out

โปรดทราบว่า URI เหล่านี้ไม่สามารถเข้าถึงได้ และใช้สำหรับให้ Chrome trigger การกระทำเฉพาะในกระบวนการยืนยันตัวตนเท่านั้น

อัปเดตการตั้งค่าแอปพลิเคชัน Logto

ตอนนี้เราต้องอัปเดตการตั้งค่าแอป Logto เพื่ออนุญาต redirect URI ที่เราสร้างไว้

1. ไปที่หน้าแอปพลิเคชันใน Logto Console
2. ในส่วน "Redirect URIs" ให้เพิ่ม URI: https://<extension-id>.chromiumapp.org/callback
3. ในส่วน "Post sign-out redirect URIs" ให้เพิ่ม URI: https://<extension-id>.chromiumapp.org/
4. ในส่วน "CORS allowed origins" ให้เพิ่ม URI: chrome-extension://<extension-id> โดย SDK ใน Chrome extension จะใช้ origin นี้ในการสื่อสารกับ Logto APIs
5. คลิก Save changes

อย่าลืมแทนที่ <extension-id> ด้วย extension ID จริงของคุณ สามารถดู extension ID ได้ที่หน้า chrome://extensions

เพิ่มปุ่ม sign-in และ sign-out ใน popup

ใกล้เสร็จแล้ว! มาเพิ่มปุ่ม sign-in และ sign-out พร้อม logic ที่จำเป็นในหน้า popup

ในไฟล์ popup.html:

popup.html

<button id="sign-in">Sign in</button> <button id="sign-out">Sign out</button>

ในไฟล์ popup.js (โดยสมมติว่า popup.js ถูก include ใน popup.html):

popup.js

document.getElementById('sign-in').addEventListener('click', async () => {
  await chrome.runtime.sendMessage({ action: 'signIn' });
  // การลงชื่อเข้าใช้เสร็จสิ้น (หรือไม่สำเร็จ) สามารถอัปเดต UI ที่นี่
});

document.getElementById('sign-out').addEventListener('click', async () => {
  await chrome.runtime.sendMessage({ action: 'signOut' });
  // การออกจากระบบเสร็จสิ้น (หรือไม่สำเร็จ) สามารถอัปเดต UI ที่นี่
});

เช็คพอยต์: ทดสอบโฟลว์การยืนยันตัวตน

ตอนนี้คุณสามารถทดสอบโฟลว์การยืนยันตัวตนใน Chrome extension ของคุณได้แล้ว:

1. เปิด popup ของ extension
2. คลิกปุ่ม "Sign in"
3. คุณจะถูกเปลี่ยนเส้นทางไปยังหน้าลงชื่อเข้าใช้ Logto
4. ลงชื่อเข้าใช้ด้วยบัญชี Logto ของคุณ
5. คุณจะถูกเปลี่ยนเส้นทางกลับมายัง Chrome

ตรวจสอบสถานะการยืนยันตัวตน

เนื่องจาก Chrome มี unified storage API นอกเหนือจากโฟลว์ sign-in และ sign-out แล้ว คุณสามารถใช้เมธอดอื่น ๆ ของ Logto SDK ในหน้า popup ได้โดยตรง

ใน popup.js ของคุณ สามารถใช้ instance ของ LogtoClient ที่สร้างใน background script หรือสร้างใหม่ด้วย config เดียวกันก็ได้:

popup.js

import LogtoClient from '@logto/chrome-extension';

const logtoClient = new LogtoClient({
  endpoint: '<your-logto-endpoint>'
  appId: '<your-logto-app-id>',
});

// หรือใช้ instance logtoClient ที่สร้างใน background script
import { logtoClient } from './service-worker.js';

จากนั้นสามารถสร้างฟังก์ชันเพื่อโหลดสถานะการยืนยันตัวตนและโปรไฟล์ผู้ใช้:

popup.js

const loadAuthenticationState = async () => {
  const isAuthenticated = await logtoClient.isAuthenticated();
  // อัปเดต UI ตามสถานะการยืนยันตัวตน

  if (isAuthenticated) {
    const user = await logtoClient.getIdTokenClaims(); // { sub: '...', email: '...', ... }
    // อัปเดต UI ด้วยโปรไฟล์ผู้ใช้
  }
};

คุณยังสามารถรวมฟังก์ชัน loadAuthenticationState เข้ากับ logic ของ sign-in และ sign-out ได้:

popup.js

document.getElementById('sign-in').addEventListener('click', async () => {
  await chrome.runtime.sendMessage({ action: 'signIn' });
  await loadAuthenticationState();
});

document.getElementById('sign-out').addEventListener('click', async () => {
  await chrome.runtime.sendMessage({ action: 'signOut' });
  await loadAuthenticationState();
});

ตัวอย่างหน้า popup ที่แสดงสถานะการยืนยันตัวตน:

ข้อควรพิจารณาอื่น ๆ

• Service worker bundling: หากคุณใช้ bundler เช่น Webpack หรือ Rollup ต้องตั้งค่า target เป็น browser หรือคล้ายกัน เพื่อหลีกเลี่ยงการ bundle โมดูล Node.js ที่ไม่จำเป็น
• Module resolution: Logto Chrome extension SDK เป็นโมดูลแบบ ESM-only

ดู โปรเจกต์ตัวอย่าง ของเรา สำหรับตัวอย่างที่สมบูรณ์พร้อม TypeScript, Rollup และการตั้งค่าอื่น ๆ

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

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

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

Home.js

const userInfo = await logtoClient.getIdTokenClaims();

// สร้างตารางแสดงข้อมูลการอ้างสิทธิ์ของโทเค็น ID
const table = document.createElement('table');
const thead = document.createElement('thead');
const tr = document.createElement('tr');
const thName = document.createElement('th');
const thValue = document.createElement('th');
thName.innerHTML = 'Name';
thValue.innerHTML = 'Value';
tr.append(thName, thValue);
thead.append(tr);
table.append(thead);

const tbody = document.createElement('tbody');

for (const [key, value] of Object.entries(userInfo)) {
  const tr = document.createElement('tr');
  const tdName = document.createElement('td');
  const tdValue = document.createElement('td');
  tdName.innerHTML = key;
  tdValue.innerHTML = typeof value === 'string' ? value : JSON.stringify(value);
  tr.append(tdName, tdValue);
  tbody.append(tr);
}

table.append(tbody);

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

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

index.js

import LogtoClient, { UserScope } from '@logto/browser';

const logtoClient = new LogtoClient({
  appId: '<your-application-id>',
  endpoint: '<your-logto-endpoint>',
  scopes: [UserScope.Email, UserScope.Phone],
});

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

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

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

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

const userInfo = await logtoClient.fetchUserInfo();
// ตอนนี้คุณสามารถเข้าถึงการอ้างสิทธิ์ `userInfo.custom_data`

เมธอดนี้จะดึงข้อมูลผู้ใช้โดยการร้องขอไปยัง จุดปลาย userinfo หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับขอบเขต (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 หรือไม่?
sub	string	ตัวระบุที่ไม่ซ้ำของผู้ใช้	ไม่

profile

ชื่อการอ้างสิทธิ์	ประเภท	คำอธิบาย	ต้องใช้ userinfo หรือไม่?
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 ด้วยโดยไม่ต้องร้องขอ endpoint userinfo ความแตกต่างเมื่อเทียบกับการอ้างสิทธิ์ข้างต้นคือ การอ้างสิทธิ์เหล่านี้จะถูกส่งกลับมาเฉพาะเมื่อค่าของมันไม่ว่างเปล่า ในขณะที่การอ้างสิทธิ์ข้างต้นจะส่งกลับ null หากค่าเป็นค่าว่าง

บันทึก:

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

email

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

phone

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

address

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

custom_data

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

identities

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

roles

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

urn:logto:scope:organizations

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

urn:logto:scope:organization_roles

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

---

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

ทรัพยากร API (API resources)

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

กำหนดค่า Logto client

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

index.js

import LogtoClient from '@logto/browser';

const logtoClient = new LogtoClient({
  // ...other configs
  resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'], // เพิ่มทรัพยากร API (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 ในแอปของคุณได้:

index.js

import LogtoClient from '@logto/chrome-extension';

const logtoClient = new LogtoClient({
// ...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
});

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

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

index.js

import LogtoClient, { UserScope } from '@logto/chrome-extension';

const logtoClient = new LogtoClient({
// ...other configs
scopes: ['read', 'write'],
resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'],
});

สำหรับแต่ละ ทรัพยากร 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 ได้ดังนี้:

const accessToken = await logtoClient.getAccessToken('https://store.your-app.com/api');
console.log('โทเค็นการเข้าถึง (Access token)', accessToken);

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

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

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

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

index.js

import LogtoClient, { UserScope } from '@logto/chrome-extension';

const logtoClient = new LogtoClient({
// ...การตั้งค่าอื่น ๆ
scopes: [UserScope.Organizations],
});

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

index.js

// ดึง organizationIds จาก userInfo

const claims = await logtoClient.getIdTokenClaims();
const organizationIds = claims.organizations;

/**
 * หรือจากการอ้างสิทธิ์ในโทเค็น ID
 *
 * const claims = await logtoClient.getIdTokenClaims();
 * const organizationIds = claims.organizations;
 */

// ดึงโทเค็นองค์กร (Organization token)
if (organizationIds.length > 0) {
  const organizationId = organizationIds[0];
  const organizationAccessToken = await logtoClient.getOrganizationToken(organizationId);
  console.log('โทเค็นองค์กร (Organization access token)', organizationAccessToken);
}

./code/_scopes-and-claims-code.mdx./code/_config-organization-code.mdx

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

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

บันทึก:

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

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

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