การสำรวจการตั้งค่า OpenID Connect: ช่องข้อมูลหลักและการใช้ประโยชน์
สำรวจช่องข้อมูลหลักและแอปพลิเคชั่นในทางปฏิบัติของการตั้งค่า OpenID Connect
ในโลกดิจิทัลของวันนี้ การตรวจสอบตัวตนได้กลายเป็นส่วนประกอบหลักในการรักษาความปลอดภัยของเว็บไซต์และแอปพลิเคชัน OpenID Connect (OIDC) ซึ่งเป็นเลเยอร์การตรวจสอบตัวตนที่สร้างขึ้นบนโปรโตคอล OAuth 2.0 ให้การตรวจสอบตัวตนในรูปแบบที่ได้มาตรฐานและตรงไปตรงมา
อย่างไรก็ตาม การผสานรวม OIDC อย่างถูกต้องอาจเป็นที่ท้าทาย โดยเฉพาะสำหรับผู้เริ่มต้น จุดเริ่มต้นที่ดีมักจะเป็น ไฟล์การตั้งค่า OIDC ที่มักจะพบที่ URL {authServerUrl}/.well-known/openid-configuration
ซึ่งประกอบด้วยรายละเอียดที่จำเป็นทั้งหมดในการดำเนินการบริการ OIDC
คู่มือเล่มนี้มีวัตถุประสงค์เพื่อชี้แจงช่องข้อมูลหลักภายในการตั้งค่านี้ ช่วยให้นักพัฒนาสามารถเข้าใจความสำคัญและการประยุกต์ใช้งานในทางปฏิบัติเพื่อผสาน OIDC เข้ากับโครงการของพวกเขาได้ดียิ่งขึ้น
การวิเคราะห์ช่องข้อมูลการตั้งค่า OIDC
การตั้งค่า OIDC เป็นไฟล์ JSON ที่คล้ายกับต่อไปนี้:
ถัดไปเราจะเจาะลึกในบางส่วนของช่องข้อมูลหลัก
authorization_endpoint
เมื่อผสานรวมบริ การ OIDC ขั้นตอนแรกมักจะเกี่ยวข้องกับการจัดการคำขอเข้าสู่ระบบของผู้ใช้ภายในแอปพลิเคชัน กระบวนการนี้รวมถึงการเปลี่ยนเส้นทางผู้ใช้ไปยัง authorization_endpoint
ของเซิร์ฟเวอร์การอนุญาต จุดนี้เป็นที่อยู่ของเซิร์ฟเวอร์ที่ส่งคำขอการอนุญาต นำพาผู้ใช้ไปยังหน้าลงชื่อเข้าใช้สำหรับการตรวจสอบตัวตน
เมื่อทำการร้องขอต่อ authorization_endpoint
จะต้องตั้งค่าด้วยพารามิเตอร์คำถามเพิ่มเติมสำหรับแต่ละการอนุญาต:
response_type
: ระบุประเภทของการอนุญาตที่ได้รับกลับคืน ซึ่งมักจะรวมถึง "code" (สำหรับการไหลของ authorization code), "token" (สำหรับการไหล implicit), และ "id_token token" หรือ "code id_token" (สำหรับการไหล hybrid) ซึ่งสามารถพบได้ในช่องresponse_types_supported
ของการตั้งค่า OIDCclient_id
: ตัวระบุเฉพาะที่กำหนดให้แก่แอปพลิเคชันโดยเซิร์ฟเวอร์การอนุญาตเมื่อแอปถูกลงทะเบียน ตัวตัวระบุตัวนี้ใช้ โดยเซิร์ฟเวอร์การอนุญาตเพื่อรู้จักแอปพลิเคชันไคลเอนต์ที่เริ่มต้นคำขอscope
: กำหนดขอบเขตของการเข้าถึงที่ร้องขอ ระบุทรัพยากรหรือข้อมูลผู้ใช้ที่สามารถเข้าถึงได้ ขอบเขตที่พบบ่อยรวมถึง "openid" (บังคับ), "profile", และ "email" เป็นต้น คุณสามารถพบขอบเขตที่รองรับในช่องscopes_supported
ของการตั้งค่า OIDC; ขอบเขตที่แตกต่างกันควรถูกแยกด้วยช่องว่างredirect_uri
: หลังจากการลงชื่อเข้าหรือการอนุญาต เซิร์ฟเวอร์การอนุญาตจะเปลี่ยนเส้นทางผู้ใช้กลับไปยัง URI ที่ให้มาโดยแอปพลิเคชัน URI นี้ต้องตรงกันกับ URI ที่ให้ในระหว่างการลงทะเบียนแอปพลิเคชันstate
: สายอักขระที่สร้างแบบสุ่มใช้เพื่อปกป้องไคลเอนต์จากการโจมตี cross-site request forgery ความสม่ำเสมอของ state ระหว่างคำขอการอนุญาตและการตีกลับต้องถูกรักษาไว้เพื่อความปลอดภัย
พารามิเตอร์เหล่านี้อนุญาตให้ นักพัฒนาควบคุมพฤติกรรมของคำขอการอนุญาต OIDC อย่างถูกต้อง เพื่อให้แน่ใจว่ามีความปลอดภัยและตรงกับความต้องการของแอปพลิเคชัน
หลังจากเสร็จสิ้นคำขอต่อ authorization_endpoint
และผ่านการตรวจสอบตัวตนแล้ว ผู้ใช้จะถูกเปลี่ยนเส้นทางไปยัง redirect_uri
ที่ระบุ ซึ่งจะรวมพารามิเตอร์คำถามที่สำคัญมาก – code
โค้ดการอนุญาตนี้มอบให้โดยเซิร์ฟเวอร์การอนุญาตและเป็นผลลัพธ์ของการที่ผู้ใช้รับรองความถูกต้องและอนุญาตให้แอปเข้าถึงข้อมูลของพวกเขาที่เซิร์ฟเวอร์การอนุญาต
token_endpoint
token_endpoint
เป็นเซิร์ฟเวอร์ปลายทางที่ใช้โดยเซิร์ฟเวอร์การอนุญาตในการแลกเปลี่ยนโค้ดการอนุญาตที่กล่าวถึงก่อนหน้านี้เพื่อรับ access และ refresh tokens ในการไหลของการอนุญาต OAuth 2.0 code ขั้นตอนนี้เป็นเรื่องสำคัญเพราะมันเกี่ยวข้องกับการแปลงโค้ดการอนุญาตที่ได้รับมาเป็น access tokens จริง ซึ่งแอปสามารถใช้เพื่อเข้าถึงทรัพยากรที่ได้รับการปกป้องของผู้ใช้
นี่คือวิธีที่การแลกเปลี่ยนโค้ดการอนุญาตเพื่อ access tokens ถูกดำเนินการ (โปรดทราบว่าในตัวอย่างนี้ใช้วิธีการตรวจสอบสิทธิ์ 'client_secret_post' สำหรับวิธีการตรวจสอบสิทธิ์ที่รองรับอื่น ๆ สามารถดูได้จากการวิเคราะห์ภายหลังก็ของช่องข้อมูล
token_endpoint_auth_methods_supported
ในโค้ดนี้ เราส่งคำขอไปยัง token_endpoint
โดยใช้วิธี POST
ชนิดเนื้อหาถูกตั้งเป็น application/x-www-form-urlencoded
ซึ่งจำเป็นสำหรับเซิร์ฟเวอร์การอนุญาตส่วนมาก ร่างกายคำขอประกอบด้วยพารามิเตอร์ดังต่อไปนี้:
- code: โค้ดการอนุญาตที่ได้มาจากเซิร์ฟเวอร์การอนุญาต ซึ่งถูกส่งกลับผ่านทาง
redirectUri
หลังจากที่ผู้ใช้ดำเนินการอนุญาตเสร็จสิ้น - redirect_uri: URI เปลี่ยนเส้นทางเดียวกันที่ใช้ในการรับโค้ดการอนุญาต ใช้เพื่อยืนยันความถูกต้องของคำขอ
- client_id: สัญลักษณ์ประจำไคลเอ็นต์ของแอปพลิเคชัน ใช้เพื่อระบุแอปพลิเคชันที่ทำคำขอ
- client_secret: ความลับของไคลเอ็นต์ของแอปพลิเคชัน ใช้เพื่อยืนยันตัวตนของแอปพลิเคชัน
- grant_type: ระบุประเภทของการอนุญาต โดยใช้
"authorization_code"
ที่นี่ ซึ่งแสดงว่าตัว token ได้มาจากการใช้โค้ดการอนุญาต
ฟังก์ชันนี้ถูกดำเนินการแบบอะซิงโครนัสและส่งคืนวัตถุ JSON ที่ประกอบด้วย access token ซึ่งแอปพลิเคชันสามารถใช้เพื่อขอข้อมูลผู้ใช้หรือทำการดำเนินการอื่น ๆ ได้
userinfo_endpoint
userinfo_endpoint
เป็นเซิร์ฟเวอร์ปลายทางที่ใช้โดยเซิร์ฟเวอร์การอนุญาตในการดึงข้อมูลรายละเอียดเกี่ยวกับผู้ใช้ที่รับรองความถูกต้องแล้ว หลังจากที่ผู้ใช้อนุญาตและได้รับ access tokens สำเร็จผ่านทาง token_endpoint
, แอปพลิเคชันสามารถร้องขอเซิร์ฟเวอร์ปลายทางนี้เพื่อเข้าถึงข้อมูลโปรไฟล์ของผู้ใช้ เช่น ชื่อผู้ใช้และที่อยู่อีเมล ข้อมูลที่ได้ระบุเฉพาะขึ้นอยู่กับ scope
ที่ผู้ใช้กำหนดไว้ในคำขอการรับรองความถูกต้อง
ในฟังก์ชันนี้ เราใช้วิธี GET
ในการร้องขอ userinfo_endpoint
รวมทั้งเพิ่มช่อง Authorization
ในส่วนหัวของคำขอที่ประกอบด้วย token_type
และ accessToken
นี่เป็นกระบวนการมาตรฐานตามสเปคของ OAuth 2.0 เพื่อรับข้อมูลผู้ใช้อย่างปลอดภัย นอกจากนี้ ขอบเขตของข้อมูลผู้ใช้ที่เข้าถึงได้ผ่าน access token นั้นขึ้นอยู่กับค่าพารามิเตอร์ scope
ที่ผู้ใช้เลือกใช้ตอนเริ่มต้นของการตรวจสอบตัวตน อย่างเช่น ถ้าใช้ขอบเขต email
การตอบรับควรรวม ถึงที่อยู่อีเมลของผู้ใช้
issuer & jwks_uri
ผู้ออกบัตรระบุ URL ของเซิร์ฟเวอร์การอนุญาต ขณะที่ jwks_uri
ให้ URI สำหรับ JSON Web Key Set (JWKS) ซึ่งเป็นชุดของรหัสสาธารณะที่ใช้ในการยืนยันลายเซ็นของ JWT การยืนยัน issuer
ของ JWT และลายเซ็นเป็นขั้นตอนพื้นฐานในการตรวจสอบความปลอดภัยของ token แต่ในสถานการณ์จริง
กระบวนการตรวจสอบมักจะรวมถึงการตรวจสอบระยะเวลาการใช้งานของ token ผู้ชม ขอบเขตการอนุญาต และช่องข้อมูลสำคัญอื่น ๆ
โค้ดต่อไปนี้แสดงหลักการใช้ issuer
และ jwks_uri
ร่วมกันเพื่อยืนยัน JWT:
scopes_supported & claims_supported
ช่อง claims_supported
และ scopes_supported
ระบุแอตทริบิวต์ผู้ใช้ (claims) และข อบเขตการเข้าถึง (scopes) ที่รับรองโดยเซิร์ฟเวอร์การอนุญาต พวกเขาช่วยให้ไคลเอนต์เข้าใจว่าแอตทริบิวต์ผู้ใช้และขอบเขตการเข้าถึงใด ๆ ที่รองรับโดยเซิร์ฟเวอร์การอนุญาต ทำให้ไคลเอนต์สามารถสร้างคำขอการอนุญาตได้อย่างมีประสิทธิภาพและวิเคราะห์การตอบสนองได้
เมื่อสร้างคำขอการอนุญาต ไคลเอนต์สามารถกำหนด scope
ที่จำเป็นตามความต้องการของแอปพลิเคชัน Scope
กำหนดทรัพยากรและการดำเนินการที่ไคลเอนต์ขอเข้าถึง เช่น openid
, email
, profile
, และอื่นๆ
สิ่งสำคัญคือควรทราบว่า claims เฉพาะที่เข้าถึงได้ในแต่ละคำขอการอนุญาตจะแตกต่างกันไปตามค่าขอบเขตที่ระบุที่จุดเริ่มต้นของการร้องขอการตรวจสอบตัวตน เช่น ขอบเขต email ให้สิทธิ์การเข้าถึงที่อยู่อีเมลของผู้ใช้ ขณะที่ขอบเขต phone ให้สิทธิ์การเข้าถึงหมายเลขโทรศัพท์ซึ่งไคลเอนต์ควรเลือกลำดับความสำคัญของขอบเขตที่เกี่ยวข้องเพื่อให้เข้ากับความต้องการของแอปพลิเคชันเมื่อสร้างคำขอการอนุญาต เพื่อให้แน่ใจว่าพวกเขาสามารถดึงแอตทริบิวต์ผู้ใช้ที่จำเป็นได้:
token_endpoint_auth_methods_supported
ช่อง
token_endpoint_auth_methods_supported
เมื่อทำการตรวจสอบสิทธิ์โดยใช้ token endpoint วิธีการตรวจสอบสิทธิ์ทั่วไป ได้แก่ client_secret_post
, client_secret_basic
และ client_secret_jwt
.
-
client_secret_post
: ไคลเอนต์ใช้ตัวระบุไคลเอนต์และความลับของไคลเอนต์ในการสร้างร่างกายที่เข้ารหัสเป็นฟอร์มซึ ่งถูกส่งเป็นส่วนหนึ่งของร่างกายคำขอ เราได้เห็นตัวอย่างของวิธีนี้ในส่วนtoken_endpoint
ข้างต้นแล้ว -
client_secret_basic
: ไคลเอนต์ใช้ตัวระบุไคลเอนต์และความลับของไคลเอนต์ในการสร้างส่วนหัวของการตรวจสอบสิทธิ์แบบพื้นฐานซึ่งถูกเพิ่มในส่วนหัวของคำขอ
client_secret_jwt
: ไคลเอนต์ใช้ JWT (JSON Web Token) เป็นการยืนยันของไคลเอนต์ในการตรวจสอบสิทธิ์. JWT นี้ประกอบด้วยตัวระบุไคลเอนต์และเมทาดาทาเพิ่มเติมบางอย่างและเซ็นโดยใช้ความลับของไคลเอนต์ หลังจากรับคำขอ เซิร์ฟเวอร์การอนุญาตตรวจสอบตัวตนของไคลเอนต์โดยตรวจสอบลายเซ็นของ JWT
ในการใช้งานจริง ไคลเอนต์จำเป็นต้องเลือกวิธีการตรวจสอบสิทธิ์ที่เหมาะสมตามวิธีที่เซิร์ฟเวอร์การอนุญาตรองรับ และต้องแน่ใจว่าข้อมูลการตรวจสอบสิทธิ์ถูกเพิ่มไปยังคำขออย่างถูกต้องเพื่อแลกเปลี่ยนโค้ดการอนุญาตเพื่อรับ access tokens อย่างปลอดภัย
บทสรุป
เราได้สำรวจช่องข้อมูลหลักในการตั้งค่า OIDC โดยมุ่งเน้นไปที่วัตถุประสงค์และการประยุกต์ใช้ของมัน การทำความเข้าใจรายละเอียดเหล่านี้จะช่วยเพิ่มความเข้าใจของคุณต่อ OpenID Connect ทำให้คุณสามารถผสานรวมและใช้งานมันได้อย่างมีประสิทธิภาพมากขึ้นในโครงการของคุณ ด้วยความรู้ที่ได้รับคุณพร้อมที่จะแฮนเดิล OIDC ซึ่งจะนำไปสู่การตรวจสอบตัวตนของผู้ใช้ที่ปลอดภัยและมีประสิทธิภาพมากขึ้น
Logto เป็นบริการตรวจสอบตัวตนที่สร้างขึ้นบน OIDC ซึ่งมีชุด SDK ที่ครอบคลุมในหลายภาษา พร้อมทั้งคำแนะนำในการผสานรวมที่หลากหลาย ช่วยให้คุณสามารถผสานรวมการเข้าสู่ระบบ OAuth / OIDC เข้ากับแอปพลิเคชันของคุณได้อย่างราบรื่นในเวลาเพียงไม่กี่นาที หากคุณกำลังมองหาบริการ OIDC ที่เชื่อถือได้และใช้งานง่าย ลองใช้ Logto วันนี้!