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

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

บทนำ​

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

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

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

คุณสมบัติ​

Application ID​

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

บันทึก:

Dynamic app client จะไม่ได้ลงทะเบียนใน Logto โดย client ID ของพวกเขาคือ URL HTTPS สาธารณะที่เป็นของ client ซึ่งใช้สำหรับให้บริการ client metadata document

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

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

  • Native app คือแอปที่ทำงานในสภาพแวดล้อม native เช่น 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 client (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 อย่างเข้มงวด, โทเค็นการเข้าถึงอายุสั้น และการหมุนเวียนโทเค็นรีเฟรช

ชื่อแอปพลิเคชัน​

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

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

บันทึก:

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

คำอธิบาย​

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

Redirect URIs​

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

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

บันทึก:

สิ่งสำคัญคือต้องแน่ใจว่า redirect URIs ที่ถูกต้องทั้งหมดถูกเพิ่มในรายการที่อนุญาตสำหรับแอปพลิเคชันใน 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 URIs

กฎ:

  • อนุญาตให้ใช้ 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 คือรายการ URIs ที่ถูกกำหนดไว้ล่วงหน้าสำหรับแอปพลิเคชันเพื่อเปลี่ยนเส้นทางผู้ใช้หลังจากที่พวกเขาออกจากระบบ Logto

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

เมื่อผู้ใช้ออกจากระบบ Logto เซสชันของพวกเขาจะถูกยุติและพวกเขาจะถูกเปลี่ยนเส้นทางไปยังหนึ่งใน URIs ที่อนุญาตที่ระบุไว้ในการตั้งค่าแอปพลิเคชัน เพื่อให้แน่ใจว่าผู้ใช้จะถูกนำทางไปยัง 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 ต้องการขอรับโทเค็นการเข้าถึงหรือ ID token จะส่งคำขอไปยัง Token Endpoint พร้อม authorization grant ซึ่งโดยปกติจะเป็น authorization code หรือ refresh token จากนั้น Token Endpoint จะตรวจสอบ authorization grant และออกโทเค็นการเข้าถึงหรือ ID token ให้ client หาก grant ถูกต้อง

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

Userinfo endpoint​

OpenID Connect UserInfo Endpoint

Always issue refresh token​

รองรับ: Traditional web, SPA

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

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

Rotate refresh token​

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

เมื่อเปิดใช้งาน Logto อาจออกโทเค็นรีเฟรชใหม่เมื่อ client ใช้ refresh token เพื่อขอโทเค็นใหม่ หาก refresh token และ app grant ของมันยังคงถูกต้อง นโยบายการหมุนเวียนเริ่มต้นคือ:

  • โทเค็นรีเฟรชสามารถหมุนเวียนได้เฉพาะก่อนที่ chain ของ refresh token จะมีอายุครบหนึ่งปี นี่คือขีดจำกัดความปลอดภัยภายใน; TTL ของ refresh token หรือ TTL ของ app grant อาจหมดอายุก่อนถึงขีดจำกัดนี้ หลังจากถึงขีดจำกัด Logto จะไม่หมุนเวียน refresh token อีกต่อไป และ refresh token ปัจจุบันจะหมดอายุเป็นครั้งสุดท้าย
  • สำหรับ public client ที่ไม่ได้ใช้ sender-constrained refresh token (เช่น Native app ปกติและ single page app) Logto จะหมุนเวียน refresh token ทุกครั้งที่มีการร้องขอ refresh token ในขณะที่ยังอนุญาตให้หมุนเวียน
  • สำหรับ client อื่น ๆ Logto จะหมุนเวียน refresh token เฉพาะเมื่อใกล้หมดอายุ (>=70% ของ TTL เดิมได้ผ่านไปแล้ว)
บันทึก:

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

Sender-constrained refresh token จะผูกกับ proof key หรือ certificate ที่ client ถืออยู่ สำหรับ SPA ปกติ การหมุนเวียนจะออก refresh token ใหม่แต่จะไม่ขยายอายุ refresh token ใหม่ refresh token ใหม่นี้จะสืบทอด TTL ที่เหลือของ refresh token ก่อนหน้า

อายุของ refresh token chain:

Refresh token จะเชื่อมโยงกับ app grant โดย TTL ของ grant ใน Logto เริ่มต้นคือ 180 วัน เมื่อ grant หมดอายุ คำขอ refresh token จะล้มเหลวและไม่สามารถใช้ refresh token เพื่อขอโทเค็นใหม่ได้อีก แม้ว่าจะเปิดใช้งานการหมุนเวียน refresh token ก็ตาม

นั่นหมายความว่า อายุสูงสุดในทางปฏิบัติของการอนุญาตที่รองรับ refresh token จะถูกจำกัดด้วย TTL ของ grant, การเพิกถอนโดยตรง หรือการหมดอายุของ refresh token แล้วแต่กรณีใดจะเกิดขึ้นก่อน

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

Refresh token time-to-live (TTL) เป็นวัน​

รองรับ: Native app, Traditional web, SPA; ค่าเริ่มต้น: 14 วัน; สูงสุด: 180 วัน

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

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

บันทึก:

การต่ออายุ TTL ของ refresh token ไม่สามารถใช้ได้ใน single-page applications (SPAs) ด้วยเหตุผลด้านความปลอดภัย สำหรับ SPA การตั้งค่านี้จะควบคุมอายุ refresh token แบบคงที่นับจากเวลาที่ออกครั้งแรก Logto จะไม่ขยาย TTL ผ่านคำขอโทเค็น และการหมุนเวียน refresh token จะไม่ป้องกัน refresh token ของ SPA จากการหมดอายุ

Refresh token TTL และ grant TTL:

Refresh token TTL ไม่ใช่ขีดจำกัดการหมดอายุเพียงอย่างเดียว Refresh token จะผูกกับ app grant และ TTL ของ grant ใน Logto เริ่มต้นคือ 180 วัน เมื่อ grant หมดอายุ คำขอ refresh token จะล้มเหลวแม้ว่า refresh token จะยังไม่หมดอายุก็ตาม

สำหรับ client ที่คำขอโทเค็นจะต่ออายุ refresh token TTL, grant TTL จะเป็นอายุสูงสุดของ refresh token chain สำหรับ SPA, refresh token อาจหมดอายุก่อน grant

Refresh token และ session binding:

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

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

Backchannel logout URI​

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

Max allowed grants (maxAllowedGrants)​

maxAllowedGrants เป็นฟิลด์ระดับแอปแบบเลือกได้ภายใต้ customClientMetadata ที่ควบคุมจำนวน grant ที่ใช้งานพร้อมกันสูงสุดต่อผู้ใช้สำหรับแอปปัจจุบัน

  • ค่าเริ่มต้น: undefined (ไม่จำกัด)
  • เมื่อกำหนดค่า: ทุกครั้งที่อนุญาตสำเร็จ Logto จะตรวจสอบจำนวน grant ที่ใช้งานทั้งหมดของผู้ใช้ในแอปปัจจุบัน (ข้ามเบราว์เซอร์และอุปกรณ์) หากเกินขีดจำกัด Logto จะเพิกถอน grant ที่เก่าที่สุด

การตั้งค่านี้มีประโยชน์เมื่อคุณต้องการจำกัดจำนวนอุปกรณ์ที่รับรองความถูกต้องพร้อมกันต่อแอป

ทุกครั้งที่มีการขับไล่ (eviction) จะทริกเกอร์เหตุการณ์ webhook Grant.LimitExceeded webhook event เพื่อให้คุณแจ้งผู้ใช้หรือบันทึกความถี่ที่ถึงขีดจำกัด

บันทึก:

ฟิลด์นี้ไม่รองรับสำหรับ:

  • Machine-to-machine apps
  • Protected apps
  • SAML apps

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

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