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

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

บทนำ​

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

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

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

คุณสมบัติ​

Application ID​

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

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

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

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

Application secret​

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

เคล็ดลับ:

แอปหน้าเดียว (SPAs) และแอปเนทีฟไม่มีการให้ App secret SPAs และแอปเนทีฟเป็น "ไคลเอนต์สาธารณะ" และไม่สามารถเก็บความลับได้ (โค้ดเบราว์เซอร์หรือบันเดิลแอปสามารถตรวจสอบได้) แทนที่จะใช้ app secret, Logto ปกป้องพวกเขาด้วย PKCE, การตรวจสอบ redirect URI / CORS ที่เข้มงวด, โทเค็นการเข้าถึงที่มีอายุสั้น และการหมุนเวียนโทเค็นรีเฟรช

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

ชื่อแอปพลิเคชัน เป็นชื่อที่มนุษย์อ่านได้ของแอปพลิเคชันและจะแสดงในคอนโซลผู้ดูแลระบบ

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

บันทึก:

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

คำอธิบาย​

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

Redirect URIs​

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

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

บันทึก:

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

คุณสามารถดู Redirection endpoint สำหรับข้อมูลเพิ่มเติม

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

รูปแบบไวด์การ์ด​

ความพร้อมใช้งาน: แอปหน้าเดียว, แอปเว็บแบบดั้งเดิม

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

กฎ:

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

ตัวอย่าง:

  • https://*.example.com/callback - ตรงกับทุกซับโดเมน
  • https://preview-*.example.com/callback - ตรงกับการปรับใช้ตัวอย่างล่วงหน้า
  • https://example.com/*/callback - ตรงกับทุกส่วนของเส้นทาง
ข้อควรระวัง:

Redirect URIs ที่ใช้ไวด์การ์ดไม่ใช่มาตรฐาน OIDC และสามารถเพิ่มพื้นผิวการโจมตีได้ ใช้อย่างระมัดระวังและควรใช้ Redirect URIs ที่แน่นอนเมื่อเป็นไปได้

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

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

บันทึก:

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

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 เพื่อรับโทเค็นการเข้าถึง, โทเค็น ID, หรือโทเค็นรีเฟรชจากผู้ให้บริการ OIDC

เมื่อไคลเอนต์ OIDC ต้องการรับโทเค็นการเข้าถึงหรือโทเค็น ID มันจะส่งคำขอไปยัง Token Endpoint พร้อมกับการอนุญาต grant ซึ่งมักจะเป็นโค้ดการอนุญาตหรือโทเค็นรีเฟรช Token Endpoint จะตรวจสอบการอนุญาต grant และออกโทเค็นการเข้าถึงหรือโทเค็น ID ให้กับไคลเอนต์หาก grant นั้นถูกต้อง

คุณสามารถดู Token Endpoint สำหรับข้อมูลเพิ่มเติม

Userinfo endpoint​

OpenID Connect UserInfo Endpoint

ออกโทเค็นรีเฟรชเสมอ​

ความพร้อมใช้งาน: เว็บแบบดั้งเดิม, SPA

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

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

หมุนเวียนโทเค็นรีเฟรช​

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

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

  • หากโทเค็นรีเฟรชถูกหมุนเวียน (มี TTL ขยายโดยการออกใหม่) เป็นเวลาหนึ่งปี; หรือ
  • หากโทเค็นรีเฟรชใกล้หมดอายุ (>=70% ของ Time to Live (TTL) ดั้งเดิมผ่านไป); หรือ
  • หากไคลเอนต์เป็นไคลเอนต์สาธารณะ เช่น แอปพลิเคชันเนทีฟหรือแอปหน้าเดียว (SPA)
บันทึก:

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

ทำความเข้าใจการหมุนเวียนโทเค็นรีเฟรช

เวลาในการมีชีวิตของโทเค็นรีเฟรช (TTL) ในวัน​

ความพร้อมใช้งาน: ไม่ใช่ SPA; ค่าเริ่มต้น: 14 วัน

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

โดยทั่วไป ค่าที่ต่ำกว่าจะเป็นที่ต้องการ

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

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

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

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

Backchannel logout URI​

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

Max allowed grants (maxAllowedGrants)​

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

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

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

บันทึก:

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

  • แอปเครื่องต่อเครื่อง
  • แอปที่ได้รับการป้องกัน
  • แอป SAML

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

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