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

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

บทนำ​

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

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

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

คุณสมบัติ​

Application ID​

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

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

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

  • Native app คือแอปที่ทำงานในสภาพแวดล้อมเนทีฟ เช่น แอป iOS, แอป Android
  • 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 secret, Logto ปกป้องด้วย PKCE, การตรวจสอบ redirect URI / CORS อย่างเข้มงวด, โทเค็นการเข้าถึง (Access token) อายุสั้น และการหมุนเวียนโทเค็นรีเฟรช (refresh-token rotation)

Application name​

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

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

บันทึก:

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

คำอธิบาย (Description)​

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

Redirect URIs​

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

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

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

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

เข้าใจการหมุนเวียนโทเค็นรีเฟรช (refresh token rotation)

อายุการใช้งาน (TTL) ของโทเค็นรีเฟรช (refresh token) เป็นวัน​

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

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

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

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

Backchannel logout URI​

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

ข้อมูลกำหนดเอง (Custom data)​

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