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

โครงสร้างข้อมูลแอปพลิเคชัน

บทนำ​

ใน Logto แอปพลิเคชัน หมายถึงโปรแกรมซอฟต์แวร์หรือบริการเฉพาะที่ลงทะเบียนกับแพลตฟอร์ม Logto และได้รับการอนุญาต (Authorization) ให้เข้าถึงข้อมูลผู้ใช้หรือดำเนินการในนามของผู้ใช้ แอปพลิเคชันถูกใช้เพื่อระบุแหล่งที่มาของคำขอที่ส่งไปยัง Logto API รวมถึงจัดการกระบวนการการยืนยันตัวตน (Authentication) และการอนุญาต (Authorization) สำหรับผู้ใช้ที่เข้าถึงแอปเหล่านั้น

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

แอปพลิเคชันยังถูกใช้ในบันทึกการตรวจสอบ (audit logs) ของ Logto เพื่อติดตามกิจกรรมของผู้ใช้และระบุภัยคุกคามหรือการละเมิดความปลอดภัยที่อาจเกิดขึ้น โดยการเชื่อมโยงการกระทำเฉพาะกับแอปพลิเคชัน Logto สามารถให้ข้อมูลเชิงลึกอย่างละเอียดเกี่ยวกับวิธีการเข้าถึงและใช้ข้อมูล ช่วยให้องค์กรจัดการข้อกำหนดด้านความปลอดภัยและการปฏิบัติตามข้อกำหนดได้ดียิ่งขึ้น หากคุณต้องการผสานรวมแอปของคุณกับ Logto ดูที่ Integrate Logto

คุณสมบัติ​

Application ID​

Application ID คือคีย์ที่สร้างขึ้นโดยอัตโนมัติและไม่ซ้ำกันเพื่อระบุแอปของคุณใน Logto และถูกอ้างถึงว่าเป็น client id ใน OAuth 2.0

ประเภทของแอปพลิเคชัน​

แอปพลิเคชัน สามารถเป็นหนึ่งในประเภทต่อไปนี้:

  • Native app คือแอปที่ทำงานในสภาพแวดล้อมเนทีฟ เช่น iOS app, Android app
    • Device flow app คือ native app ประเภทพิเศษสำหรับอุปกรณ์ที่จำกัดการป้อนข้อมูลหรือแอปแบบไม่มีหัว (headless) (เช่น สมาร์ททีวี, เกมคอนโซล, CLI tools, อุปกรณ์ IoT) โดยใช้ OAuth 2.0 Device Authorization Grant แทน flow แบบ redirect มาตรฐาน ดู Device flow quick start สำหรับรายละเอียด
  • Single page app คือแอปที่ทำงานในเว็บเบราว์เซอร์ ซึ่งอัปเดตหน้าเว็บด้วยข้อมูลใหม่จากเซิร์ฟเวอร์โดยไม่ต้องโหลดหน้าใหม่ทั้งหมด เช่น React DOM app, Vue app
  • Traditional web app คือแอปที่เรนเดอร์และอัปเดตหน้าโดยเว็บเซิร์ฟเวอร์เท่านั้น เช่น JSP, PHP
  • Machine-to-machine (M2M) app คือแอปที่ทำงานในสภาพแวดล้อมของเครื่องเพื่อสื่อสารระหว่างบริการโดยตรงโดยไม่ต้องมีการโต้ตอบกับผู้ใช้

Application secret​

Application secret คือคีย์ที่ใช้ในการยืนยันตัวตนของแอปในระบบการยืนยันตัวตน โดยเฉพาะสำหรับ private clients (Traditional Web และ M2M apps) เพื่อเป็นเกราะป้องกันความปลอดภัย

เคล็ดลับ:

Single Page Apps (SPAs) และ Native apps จะไม่มี App secret เนื่องจาก SPAs และ Native apps เป็น "public clients" และไม่สามารถเก็บความลับได้ (โค้ดเบราว์เซอร์หรือ app bundle สามารถถูกตรวจสอบได้) แทนที่จะใช้ app secret, Logto จะปกป้องด้วย PKCE, การตรวจสอบ redirect URI/CORS อย่างเข้มงวด, access token อายุสั้น และการหมุนเวียน refresh-token

Application name​

Application name คือชื่อที่มนุษย์อ่านเข้าใจได้ของแอปพลิเคชันและจะแสดงใน admin console

Application name เป็นองค์ประกอบสำคัญในการจัดการแอปใน Logto เพราะช่วยให้ผู้ดูแลระบบสามารถระบุและติดตามกิจกรรมของแต่ละแอปในแพลตฟอร์มได้อย่างง่ายดาย

บันทึก:

ควรเลือก Application name อย่างระมัดระวัง เพราะจะแสดงให้ผู้ใช้ทุกคนที่เข้าถึง admin console เห็น ควรสะท้อนวัตถุประสงค์และฟังก์ชันของแอปอย่างถูกต้อง และเข้าใจง่าย

คำอธิบาย​

คำอธิบายสั้น ๆ ของแอปพลิเคชันจะแสดงในหน้ารายละเอียดแอปของ admin console คำอธิบายนี้มีไว้เพื่อให้ข้อมูลเพิ่มเติมแก่ผู้ดูแลระบบ เช่น วัตถุประสงค์ ฟังก์ชัน และรายละเอียดอื่น ๆ ที่เกี่ยวข้อง

Redirect URIs​

Redirect URIs คือรายการของ redirect URI ที่ถูกต้องซึ่งถูกกำหนดไว้ล่วงหน้าสำหรับแอปพลิเคชัน เมื่อผู้ใช้ลงชื่อเข้าใช้ Logto และพยายามเข้าถึงแอปพลิเคชัน พวกเขาจะถูกเปลี่ยนเส้นทางไปยังหนึ่งใน URI ที่อนุญาตตามที่ระบุไว้ในการตั้งค่าแอป

รายการ URI ที่อนุญาตนี้ใช้สำหรับตรวจสอบ redirect URI ที่รวมอยู่ในคำขอการอนุญาตที่แอปส่งไปยัง Logto ระหว่างกระบวนการยืนยันตัวตน หาก redirect URI ที่ระบุในคำขอการอนุญาตตรงกับ URI ที่อนุญาตในแอป ผู้ใช้จะถูกเปลี่ยนเส้นทางไปยัง URI นั้นหลังจากยืนยันตัวตนสำเร็จ หาก redirect URI ไม่อยู่ในรายการที่อนุญาต ผู้ใช้จะไม่ถูกเปลี่ยนเส้นทางและกระบวนการยืนยันตัวตนจะล้มเหลว

บันทึก:

ควรตรวจสอบให้แน่ใจว่าได้เพิ่ม redirect URI ที่ถูกต้องทั้งหมดลงในรายการที่อนุญาตของแอปใน Logto เพื่อให้ผู้ใช้สามารถเข้าถึงแอปได้สำเร็จหลังจากยืนยันตัวตน

คุณสามารถดูข้อมูลเพิ่มเติมได้ที่ Redirection endpoint

ทำความเข้าใจ Redirect URIs ใน OIDC ด้วย Authorization Code Flow

รูปแบบ Wildcard​

ใช้ได้กับ: Single page app, Traditional web app

Redirect URIs รองรับรูปแบบ wildcard (*) สำหรับสภาพแวดล้อมแบบไดนามิก เช่น การ deploy แบบ preview สามารถใช้ wildcard ในส่วน hostname และ pathname ของ HTTP/HTTPS URI ได้

กฎ:

  • อนุญาตให้ใช้ wildcard เฉพาะใน hostname และ pathname เท่านั้น
  • ไม่อนุญาตให้ใช้ wildcard ใน scheme, port, query parameters หรือ hash fragments
  • wildcard ใน hostname ต้องมีจุดอย่างน้อยหนึ่งจุด (เช่น https://*.example.com/callback)

ตัวอย่าง:

  • https://*.example.com/callback - ตรงกับทุก subdomain
  • https://preview-*.example.com/callback - ตรงกับการ deploy แบบ preview
  • https://example.com/*/callback - ตรงกับทุก path segment
ข้อควรระวัง:

Wildcard redirect URIs ไม่ใช่มาตรฐาน OIDC และอาจเพิ่มความเสี่ยงด้านความปลอดภัย ควรใช้ด้วยความระมัดระวังและควรใช้ redirect URI ที่ตรงเป๊ะเมื่อเป็นไปได้

Post sign-out redirect URIs​

Post sign-out redirect URIs คือรายการ URI ที่ถูกต้องซึ่งถูกกำหนดไว้ล่วงหน้าสำหรับแอปพลิเคชันเพื่อเปลี่ยนเส้นทางผู้ใช้หลังจากออกจากระบบ Logto

การใช้ Allowed Post Sign-out Redirect URIs สำหรับ Logout เป็นส่วนหนึ่งของข้อกำหนด RP-Initiated (Relying Party Initiated) Logout ใน OIDC ซึ่งเป็นวิธีมาตรฐานสำหรับแอปในการเริ่มคำขอออกจากระบบให้ผู้ใช้ รวมถึงการเปลี่ยนเส้นทางผู้ใช้ไปยัง endpoint ที่กำหนดไว้ล่วงหน้าหลังจากออกจากระบบ

เมื่อผู้ใช้ออกจากระบบ Logto เซสชันของพวกเขาจะสิ้นสุดและจะถูกเปลี่ยนเส้นทางไปยัง URI ที่อนุญาตตามที่ระบุไว้ในการตั้งค่าแอป เพื่อให้แน่ใจว่าผู้ใช้จะถูกเปลี่ยนเส้นทางไปยัง endpoint ที่ได้รับอนุญาตและถูกต้องเท่านั้นหลังจากออกจากระบบ ช่วยป้องกันการเข้าถึงโดยไม่ได้รับอนุญาตและความเสี่ยงด้านความปลอดภัยที่เกี่ยวข้องกับการเปลี่ยนเส้นทางไปยัง endpoint ที่ไม่รู้จักหรือไม่ได้รับการตรวจสอบ

คุณสามารถดูข้อมูลเพิ่มเติมได้ที่ RP-initiated logout

CORS allowed origins​

CORS (Cross-origin resource sharing) allowed origins คือรายการ origin ที่อนุญาตให้แอปพลิเคชันส่งคำขอไปยังบริการ Logto ได้ Origin ที่ไม่ได้อยู่ในรายการนี้จะไม่สามารถส่งคำขอไปยังบริการ Logto ได้

รายการ CORS allowed origins ใช้เพื่อจำกัดการเข้าถึงบริการ Logto จากโดเมนที่ไม่ได้รับอนุญาต และช่วยป้องกันการโจมตีแบบ cross-site request forgery (CSRF) โดยการระบุ origin ที่อนุญาตสำหรับแอปใน Logto จะช่วยให้แน่ใจว่ามีเพียงโดเมนที่ได้รับอนุญาตเท่านั้นที่สามารถส่งคำขอไปยังบริการได้

บันทึก:

รายการ allowed origins ควรมี origin ที่แอปจะถูกให้บริการอยู่ เพื่อให้แน่ใจว่าคำขอจากแอปจะได้รับอนุญาต ในขณะที่คำขอจาก origin ที่ไม่ได้รับอนุญาตจะถูกบล็อก

OpenID provider configuration endpoint​

Endpoint สำหรับ OpenID Connect Discovery

Authorization endpoint​

Authorization Endpoint เป็นคำศัพท์ของ OIDC และเป็น endpoint ที่จำเป็นสำหรับเริ่มกระบวนการยืนยันตัวตนของผู้ใช้ เมื่อผู้ใช้พยายามเข้าถึงทรัพยากรหรือแอปที่ได้รับการลงทะเบียนกับ Logto พวกเขาจะถูกเปลี่ยนเส้นทางไปยัง Authorization Endpoint เพื่อยืนยันตัวตนและขออนุญาตเข้าถึงทรัพยากรที่ร้องขอ

คุณสามารถดูข้อมูลเพิ่มเติมได้ที่ Authorization Endpoint

Token endpoint​

Token Endpoint เป็นคำศัพท์ของ OIDC เป็น endpoint ของเว็บ API ที่ OIDC client ใช้เพื่อขอรับโทเค็นการเข้าถึง (access token), โทเค็น ID (ID token) หรือโทเค็นรีเฟรช (refresh token) จาก OIDC provider

เมื่อ OIDC client ต้องการขอรับ access token หรือ ID token จะส่งคำขอไปยัง Token Endpoint พร้อม authorization grant ซึ่งโดยทั่วไปคือ authorization code หรือ refresh token จากนั้น Token Endpoint จะตรวจสอบ authorization grant และออก access token หรือ ID token ให้ client หาก grant ถูกต้อง

คุณสามารถดูข้อมูลเพิ่มเติมได้ที่ Token Endpoint

Userinfo endpoint​

OpenID Connect UserInfo Endpoint

Always issue refresh token​

ใช้ได้กับ: Traditional web, SPA

เมื่อเปิดใช้งาน Logto จะออกโทเค็นรีเฟรช (refresh tokens) เสมอ ไม่ว่าจะมี prompt=consent ในคำขอการยืนยันตัวตนหรือไม่ หรือมี offline_access ในขอบเขต (scopes) หรือไม่ก็ตาม

อย่างไรก็ตาม ไม่แนะนำให้ใช้แนวทางนี้เว้นแต่จำเป็น (โดยปกติจะใช้กับการผสานรวม OAuth ของบุคคลที่สามที่ต้องการ refresh token) เพราะไม่สอดคล้องกับ OpenID Connect และอาจก่อให้เกิดปัญหาได้

Rotate refresh token​

ค่าเริ่มต้น: true

เมื่อเปิดใช้งาน Logto จะออก refresh token ใหม่สำหรับคำขอโทเค็นภายใต้เงื่อนไขต่อไปนี้:

  • หาก refresh token ถูกหมุนเวียน (TTL ถูกขยายโดยการออกใหม่) เป็นเวลาหนึ่งปี; หรือ
  • หาก refresh token ใกล้หมดอายุ (>=70% ของ TTL เดิมผ่านไปแล้ว); หรือ
  • หาก client เป็น public client เช่น Native application หรือ single page application (SPA)
บันทึก:

สำหรับ public clients เมื่อเปิดใช้งานฟีเจอร์นี้ จะมีการออก refresh token ใหม่เสมอเมื่อ client แลกเปลี่ยน refresh token เป็น access token ใหม่ แม้ว่าคุณจะสามารถปิดฟีเจอร์นี้สำหรับ public clients ได้ แต่ขอแนะนำอย่างยิ่งให้เปิดไว้เพื่อเหตุผลด้านความปลอดภัย

ทำความเข้าใจการหมุนเวียน refresh token

อายุ refresh token (TTL) เป็นวัน​

ใช้ได้กับ: ไม่ใช่ SPA; ค่าเริ่มต้น: 14 วัน

ระยะเวลาที่ refresh token สามารถใช้ขอ access token ใหม่ได้ก่อนหมดอายุและกลายเป็นโมฆะ คำขอโทเค็นจะขยาย TTL ของ refresh token เป็นค่านี้

โดยทั่วไป ค่าที่ต่ำกว่าจะดีกว่า

หมายเหตุ: SPA (single page app) จะไม่สามารถขยาย TTL refresh token ได้ด้วยเหตุผลด้านความปลอดภัย หมายความว่า Logto จะไม่ขยาย TTL ผ่านคำขอโทเค็น เพื่อปรับปรุงประสบการณ์ผู้ใช้ คุณสามารถเปิดฟีเจอร์ "Rotate refresh token" เพื่อให้ Logto ออก refresh token ใหม่เมื่อจำเป็น

โทเค็นรีเฟรช (refresh token) และการผูกกับเซสชัน:

เมื่อ refresh token ถูกออก โดยไม่มี ขอบเขต offline_access ในคำขอการอนุญาต มันจะถูกผูกกับเซสชันของผู้ใช้ โดยเซสชันจะมี TTL คงที่ 14 วัน หลังจากเซสชันหมดอายุ refresh token จะกลายเป็นโมฆะไม่ว่าค่า TTL ของมันจะตั้งไว้เท่าใดก็ตาม

เพื่อให้การตั้งค่า TTL ของ refresh token มีผลเต็มที่ ต้องแน่ใจว่าได้ใส่ขอบเขต offline_access ในคำขอการอนุญาตของคุณ

Backchannel logout URI​

Endpoint สำหรับ OpenID Connect backchannel logout ดู Federated sign-out: Back-channel logout สำหรับข้อมูลเพิ่มเติม

ข้อมูลกำหนดเอง​

ข้อมูลเพิ่มเติมของแอปพลิเคชันที่ไม่ได้อยู่ในคุณสมบัติที่กำหนดไว้ล่วงหน้า ผู้ใช้สามารถกำหนดฟิลด์ข้อมูลกำหนดเองตามความต้องการเฉพาะ เช่น การตั้งค่าทางธุรกิจหรือการกำหนดค่าต่าง ๆ