เพิ่มการยืนยันตัวตนให้กับแอป Python เว็บของคุณ (Add authentication to your Python web application)
คู่มือนี้จะแสดงวิธีผสาน Logto เข้ากับแอป Python เว็บของคุณ
- ตัวอย่างนี้ใช้ Flask แต่แนวคิดเดียวกันนี้ใช้ได้กับเฟรมเวิร์กอื่น ๆ
- โปรเจกต์ตัวอย่างภาษา Python มีให้ใน Python SDK repo ของเรา
- Logto SDK ใช้ coroutines อย่าลืมใช้
await
เมื่อเรียกฟังก์ชันแบบ async
ข้อกำหนดเบื้องต้น
- บัญชี Logto Cloud หรือ Logto ที่โฮสต์เอง
- สร้างแอป Logto เว็บแบบดั้งเดิมไว้แล้ว
การติดตั้ง
ดำเนินการในไดเรกทอรีรากของโปรเจกต์:
pip install logto # หรือ `poetry add logto` หรือเครื่องมือที่คุณใช้
การผสานระบบ
เริ่มต้น LogtoClient
ก่อนอื่น สร้าง Logto config:
from logto import LogtoClient, LogtoConfig
client = LogtoClient(
LogtoConfig(
endpoint="https://you-logto-endpoint.app", # แทนที่ด้วย Logto endpoint ของคุณ
appId="replace-with-your-app-id",
appSecret="replace-with-your-app-secret",
),
)
คุณสามารถค้นหาและคัดลอก "App Secret" ได้จากหน้ารายละเอียดแอปพลิเคชันใน Admin Console:

นอกจากนี้ ให้แทนที่ memory storage เริ่มต้นด้วย storage แบบถาวร เช่น:
from logto import LogtoClient, LogtoConfig, Storage
from flask import session
from typing import Union
class SessionStorage(Storage):
def get(self, key: str) -> Union[str, None]:
return session.get(key, None)
def set(self, key: str, value: Union[str, None]) -> None:
session[key] = value
def delete(self, key: str) -> None:
session.pop(key, None)
client = LogtoClient(
LogtoConfig(...),
storage=SessionStorage(),
)
ดูรายละเอียดเพิ่มเติมได้ที่ Storage
กำหนดค่า redirect URIs
ก่อนที่เราจะลงลึกในรายละเอียด นี่คือภาพรวมประสบการณ์ของผู้ใช้ปลายทาง กระบวนการลงชื่อเข้าใช้สามารถสรุปได้ดังนี้:
- แอปของคุณเรียกใช้งานเมธอดลงชื่อเข้าใช้
- ผู้ใช้จะถูกเปลี่ยนเส้นทางไปยังหน้าลงชื่อเข้าใช้ของ Logto สำหรับแอปเนทีฟ ระบบจะเปิดเบราว์เซอร์ของระบบ
- ผู้ใช้ลงชื่อเข้าใช้และถูกเปลี่ยนเส้นทางกลับไปยังแอปของคุณ (ตามที่กำหนดไว้ใน redirect URI)
เกี่ยวกับการลงชื่อเข้าใช้แบบเปลี่ยนเส้นทาง (redirect-based sign-in)
- กระบวนการยืนยันตัวตนนี้เป็นไปตามโปรโตคอล OpenID Connect (OIDC) และ Logto บังคับใช้มาตรการรักษาความปลอดภัยอย่างเข้มงวดเพื่อปกป้องการลงชื่อเข้าใช้ของผู้ใช้
- หากคุณมีหลายแอป คุณสามารถใช้ผู้ให้บริการข้อมูลระบุตัวตน (Logto) เดียวกันได้ เมื่อผู้ใช้ลงชื่อเข้าใช้แอปหนึ่งแล้ว Logto จะดำเนินการลงชื่อเข้าใช้โดยอัตโนมัติเมื่อผู้ใช้เข้าถึงแอปอื่น
หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับเหตุผลและประโยชน์ของการลงชื่อเข้าใช้แบบเปลี่ยนเส้นทาง โปรดดูที่ อธิบายประสบการณ์การลงชื่อเข้าใช้ของ Logto
ในตัวอย่างโค้ดต่อไปนี้ เราถือว่าแอปของคุณกำลังทำงานอยู่ที่ http://localhost:3000/
กำหนดค่า Redirect URI
ไปที่หน้ารายละเอียดแอปพลิเคชันใน Logto Console เพิ่ม redirect URI http://localhost:3000/callback

เช่นเดียวกับการลงชื่อเข้าใช้ ผู้ใช้ควรถูกเปลี่ยนเส้นทางไปที่ Logto เพื่อออกจากเซสชันที่ใช้ร่วมกัน เมื่อเสร็จสิ้นแล้ว ควรเปลี่ยนเส้นทางผู้ใช้กลับไปยังเว็บไซต์ของคุณ ตัวอย่างเช่น เพิ่ม http://localhost:3000/
ในส่วน post sign-out redirect URI
จากนั้นคลิก "Save" เพื่อบันทึกการเปลี่ยนแปลง
สร้างเส้นทาง sign-in และ sign-out
ในแอปพลิเคชันเว็บของคุณ ให้เพิ่ม route เพื่อจัดการคำขอลงชื่อเข้าใช้จากผู้ใช้อย่างถูกต้อง ตัวอย่างนี้จะใช้ /sign-in
:
@app.route("/sign-in")
async def sign_in():
# รับ URL สำหรับลงชื่อเข้าใช้และเปลี่ยนเส้นทางผู้ใช้ไปยังหน้านั้น
return redirect(await client.signIn(
redirectUri="http://localhost:3000/callback",
))
แทนที่ http://localhost:3000/callback
ด้วย callback URL ที่คุณตั้งค่าไว้ใน Logto Console สำหรับแอปพลิเคชันนี้
หากคุณต้องการแสดงหน้าสมัครสมาชิก (sign-up) เป็นหน้าจอแรก สามารถตั้งค่า interactionMode
เป็น signUp
ได้ดังนี้:
@app.route("/sign-in")
async def sign_in():
return redirect(await client.signIn(
redirectUri="http://localhost:3000/callback",
interactionMode="signUp", # แสดงหน้าสมัครสมาชิกเป็นหน้าจอแรก
))
ตอนนี้ ทุกครั้งที่ผู้ใช้ของคุณเข้าชม http://localhost:3000/sign-in
จะเริ่มกระบวนการลงชื่อเข้าใช้ใหม่และเปลี่ยนเส้นทางผู้ใช้ไปยังหน้าลงชื่อเข้าใช้ของ Logto
หมายเหตุ การสร้าง route สำหรับลงชื่อเข้าใช้ไม่ใช่วิธีเดียวในการเริ่มต้นกระบวนการลงชื่อเข้าใช้ คุณสามารถใช้เมธอด
signIn
เพื่อรับ URL สำหรับลงชื่อเข้าใช้และเปลี่ยนเส้นทางผู้ใช้ไปยังหน้านั้นได้เสมอ
หลังจากที่ผู้ใช้ร้องขอลงชื่อออก Logto จะล้างข้อมูลการยืนยันตัวตนของผู้ใช้ทั้งหมดใน session
เพื่อเคลียร์ session ของ Python และ session ของ Logto สามารถสร้าง route สำหรับลงชื่อออกได้ดังนี้:
@app.route("/sign-out")
async def sign_out():
return redirect(
# เปลี่ยนเส้นทางผู้ใช้ไปยังหน้าแรกหลังจากลงชื่อออกสำเร็จ
await client.signOut(postLogoutRedirectUri="http://localhost:3000/")
)
จัดการสถานะการยืนยันตัวตน
ใน Logto SDK เราสามารถใช้ client.isAuthenticated()
เพื่อตรวจสอบสถานะการยืนยันตัวตน (authentication) ได้ หากผู้ใช้ลงชื่อเข้าใช้แล้ว ค่านี้จะเป็น true หากยังไม่ลงชื่อเข้าใช้ ค่านี้จะเป็น false
ที่นี่เรายังได้สร้างหน้าแรกอย่างง่ายเพื่อสาธิตการทำงานดังนี้:
- หากผู้ใช้ยังไม่ลงชื่อเข้าใช้ จะแสดงปุ่มลงชื่อเข้าใช้
- หากผู้ใช้ลงชื่อเข้าใช้แล้ว จะแสดงปุ่มลงชื่อออก
@app.route("/")
async def home():
if client.isAuthenticated() is False:
return "ยังไม่ได้ยืนยันตัวตน <a href='/sign-in'>ลงชื่อเข้าใช้</a>"
return "ยืนยันตัวตนแล้ว <a href='/sign-out'>ลงชื่อออก</a>"
จุดตรวจสอบ: ทดสอบแอปพลิเคชันของคุณ
ตอนนี้คุณสามารถทดสอบแอปพลิเคชันของคุณได้แล้ว:
- รันแอปพลิเคชันของคุณ คุณจะเห็นปุ่มลงชื่อเข้าใช้
- คลิกปุ่มลงชื่อเข้าใช้ SDK จะเริ่มกระบวนการลงชื่อเข้าใช้และเปลี่ยนเส้นทางคุณไปยังหน้าลงชื่อเข้าใช้ของ Logto
- หลังจากที่คุณลงชื่อเข้าใช้แล้ว คุณจะถูกเปลี่ยนเส้นทางกลับไปยังแอปพลิเคชันของคุณและเห็นปุ่มลงชื่อออก
- คลิกปุ่มลงชื่อออกเพื่อเคลียร์ที่เก็บโทเค็นและออกจากระบบ
รับข้อมูลผู้ใช้
แสดงข้อมูลผู้ใช้
เพื่อแสดงข้อมูลของผู้ใช้ คุณสามารถใช้เมธอด getIdTokenClaims
หรือ fetchUserInfo
เพื่อดึงข้อมูลผู้ใช้ โดย getIdTokenClaims
จะคืนค่าข้อมูลผู้ใช้ที่อยู่ในโทเค็น ID (ID token) ส่วน fetchUserInfo
จะดึงข้อมูลผู้ใช้จาก userinfo endpoint
ดังที่เห็น เราใช้ decorator @authenticated
เพื่อดึง context ข้อมูลผู้ใช้มาใช้กับ API ของแอป Flask
from functools import wraps
from flask import g, jsonify, redirect
from samples.client import client
def authenticated(shouldRedirect: bool = False, fetchUserInfo: bool = False):
def decorator(func):
@wraps(func)
async def wrapper(*args, **kwargs):
if client.isAuthenticated() is False:
if shouldRedirect:
return redirect("/sign-in")
return jsonify({"error": "Not authenticated"}), 401
# Store user info in Flask application context
g.user = (
await client.fetchUserInfo()
if fetchUserInfo
else client.getIdTokenClaims()
)
return await func(*args, **kwargs)
return wrapper
return decorator
ตัวอย่างเช่น หากต้องการแสดงข้อมูลผู้ใช้ใน API สามารถใช้โค้ดดังนี้:
@app.route("/protected/userinfo")
@authenticated(shouldRedirect=True, fetchUserInfo=True)
async def protectedUserinfo():
try:
return (
"<h2>User info</h2>"
+ g.user.model_dump_json(indent=2, exclude_unset=True).replace("\n", "<br>")
+ navigationHtml
)
except LogtoException as e:
return "<h2>Error</h2>" + str(e) + "<br>" + navigationHtml
โมเดลข้อมูลของเราสร้างบน pydantic ดังนั้นคุณสามารถใช้ model_dump_json
เพื่อแปลงโมเดลข้อมูลเป็น JSON ได้
การเพิ่ม exclude_unset=True
จะตัดฟิลด์ที่ไม่ได้ตั้งค่าออกจากผลลัพธ์ JSON ทำให้ผลลัพธ์แม่นยำยิ่งขึ้น
ตัวอย่างเช่น หากเราไม่ได้ร้องขอขอบเขต email
ตอนลงชื่อเข้าใช้ ฟิลด์ email
จะไม่ปรากฏใน JSON แต่หากร้องขอขอบเขต email
แล้วผู้ใช้ไม่มีอีเมล ฟิลด์ email
จะอยู่ใน JSON โดยมีค่าเป็น null
หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับขอบเขต (scopes) และการอ้างสิทธิ์ (claims) ดูที่ รับข้อมูลผู้ใช้
ขอการอ้างสิทธิ์เพิ่มเติม
คุณอาจพบว่าข้อมูลผู้ใช้บางอย่างหายไปในอ็อบเจกต์ที่ส่งคืนจาก client.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 ไปยังอ็อบเจกต์ LogtoConfig
ตัวอย่างเช่น:
from logto import UserInfoScope
client = LogtoClient(
LogtoConfig(
# ...other configurations
scopes = [
UserInfoScope.email,
UserInfoScope.phone,
],
),
storage=SessionStorage(),
)
จากนั้นคุณสามารถเข้าถึงการอ้างสิทธิ์เพิ่มเติมในค่าที่คืนมาจาก client.getIdTokenClaims()
:
idTokenClaims = await client.getIdTokenClaims();
การอ้างสิทธิ์ (Claims) ที่ต้องใช้การร้องขอผ่านเครือข่าย
เพื่อป้องกันไม่ให้โทเค็น ID (ID token) มีขนาดใหญ่เกินไป การอ้างสิทธิ์บางรายการจำเป็นต้องร้องขอผ่านเครือข่ายเพื่อดึงข้อมูล ตัวอย่างเช่น การอ้างสิทธิ์ custom_data
จะไม่ถูกรวมอยู่ในอ็อบเจกต์ผู้ใช้ แม้ว่าจะร้องขอไว้ในขอบเขต (scopes) ก็ตาม หากต้องการเข้าถึงการอ้างสิทธิ์เหล่านี้ คุณสามารถใช้เมธอด client.fetchUserInfo()
:
(await client.fetchUserInfo()).custom_data
ขอบเขตและการอ้างสิทธิ์
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 หรือไม่? |
---|---|---|---|
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 และองค์กร
เราแนะนำให้อ่าน 🔐 การควบคุมการเข้าถึงตามบทบาท (RBAC) ก่อน เพื่อทำความเข้าใจแนวคิดพื้นฐานของ RBAC ใน Logto และวิธีตั้งค่าทรัพยากร API อย่างถูกต้อง
กำหนดค่า Logto client
เมื่อคุณตั้งค่า ทรัพยากร API (API resources) เรียบร้อยแล้ว คุณสามารถเพิ่มทรัพยากรเหล่านี้ขณะกำหนดค่า Logto ในแอปของคุณได้:
client = LogtoClient(
LogtoConfig(
# ...การตั้งค่าอื่น ๆ
resources=["https://shopping.your-app.com/api", "https://store.your-app.com/api"], # เพิ่มทรัพยากร API
),
)
แต่ละ ทรัพยากร 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 ในแอปของคุณได้:
client = LogtoClient(
LogtoConfig(
# ...other configs
scopes=["shopping:read", "shopping:write", "store:read", "store:write"], # ขอบเขต (scopes) ที่ร้องขอ
resources=["https://shopping.your-app.com/api", "https://store.your-app.com/api"], # ทรัพยากร (resources) ที่ร้องขอ
),
)
คุณอาจสังเกตได้ว่า ขอบเขต (scopes) ถูกกำหนดแยกจาก ทรัพยากร API (API resources) นี่เป็นเพราะ Resource Indicators for OAuth 2.0 ระบุว่า ขอบเขตสุดท้ายสำหรับคำขอจะเป็นผลคูณคาร์ทีเซียนของขอบเขตทั้งหมดในบริการเป้าหมายทั้งหมด
ดังนั้น ในกรณีข้างต้น ขอบเขต (scopes) สามารถทำให้เรียบง่ายขึ้นจากการกำหนดใน Logto โดยทั้งสอง ทรัพยากร API (API resources) สามารถมีขอบเขต read
และ write
ได้โดยไม่ต้องมีคำนำหน้า จากนั้น ในการตั้งค่า Logto:
client = LogtoClient(
LogtoConfig(
# ...การตั้งค่าอื่น ๆ
scopes=["read", "write"], # ขอบเขต (scopes) ที่ร้องขอ
resources=["https://shopping.your-app.com/api", "https://store.your-app.com/api"], # ทรัพยากร API ที่ร้องขอ
),
)
สำหรับแต่ละ ทรัพยากร API (API resource) จะร้องขอทั้งขอบเขต read
และ write
คุณสามารถร้องขอขอบเขต (scopes) ที่ไม่ได้กำหนดไว้ใน ทรัพยากร API (API resources) ได้ เช่น คุณสามารถร้องขอขอบเขต email
ได้ แม้ว่า ทรัพยากร API (API resources) จะไม่มีขอบเขต email
ให้ ขอบเขตที่ไม่มีจะถูกละเว้นอย่างปลอดภัย
หลังจากลงชื่อเข้าใช้สำเร็จ Logto จะออกขอบเขตที่เหมาะสมให้กับ ทรัพยากร API (API resources) ตามบทบาทของผู้ใช้
ดึงโทเค็นการเข้าถึงสำหรับทรัพยากร API
เพื่อดึงโทเค็นการเข้าถึง (Access token) สำหรับทรัพยากร API เฉพาะ คุณสามารถใช้เมธอด GetAccessToken
ได้ดังนี้:
accessToken = await client.getAccessToken("https://shopping.your-app.com/api")
# หรือ
claims = await client.getAccessTokenClaims("https://shopping.your-app.com/api")
เมธอดนี้จะส่งคืนโทเค็นการเข้าถึง (JWT access token) ที่สามารถใช้เข้าถึงทรัพยากร API ได้เมื่อผู้ใช้มีสิทธิ์ที่เกี่ยวข้อง หากโทเค็นการเข้าถึงที่แคชไว้หมดอายุแล้ว เมธอดนี้จะพยายามใช้โทเค็นรีเฟรช (Refresh token) เพื่อขอโทเค็นการเข้าถึงใหม่โดยอัตโนมัติ
ดึงโทเค็นองค์กร
หากคุณยังไม่คุ้นเคยกับ องค์กร (Organization) โปรดอ่าน 🏢 องค์กร (หลายผู้เช่า; Multi-tenancy) เพื่อเริ่มต้น
คุณต้องเพิ่ม core.UserScopeOrganizations
ขอบเขต (scope) ขณะตั้งค่า Logto client:
from logto import LogtoClient, LogtoConfig, UserInfoScope
client = LogtoClient(
LogtoConfig(
# ...การตั้งค่าอื่น ๆ
scopes=[UserInfoScope.organizations],
),
)
เมื่อผู้ใช้ลงชื่อเข้าใช้แล้ว คุณสามารถดึงโทเค็นองค์กร (organization token) สำหรับผู้ใช้ได้:
# แทนที่พารามิเตอร์ด้วยรหัสองค์กรที่ถูกต้อง
# รหัสองค์กรที่ถูกต้องสำหรับผู้ใช้สามารถดูได้ในการอ้างสิทธิ์ (claim) ของโทเค็น ID (`organizations`)
organizationToken = await client.getOrganizationToken(organization_id)
# หรือ
organizationTokenClaims = await client.getOrganizationTokenClaims(organization_id)