สำรวจช่องข้อมูลหลักและแอปพลิเคชั่นในทางปฏิบัติของการตั้งค่า OpenID Connect
ในโลกดิจิทัลของวันนี้ การตรวจสอบตัวตนได้กลายเป็นส่วนประกอบหลักในการรักษาความปลอดภัยของเว็บไซต์และแอปพลิเคชัน OpenID Connect (OIDC) ซึ่งเป็นเลเยอร์การตรวจสอบตัวตนที่สร้างขึ้นบนโปรโตคอล OAuth 2.0 ให้การตรวจสอบตัวตนในรูปแบบที่ได้มาตรฐานและตรงไปตรงมา
อย่างไรก็ตาม การผสานรวม OIDC อย่างถูกต้องอาจเป็นที่ท้าทาย โดยเฉพาะสำหรับผู้เริ่มต้น จุดเริ่มต้นที่ดีมักจะเป็นไฟล์การตั้งค่า OIDC ที่มักจะพบที่ URL {authServerUrl}/.well-known/openid-configuration ซึ่งประกอบด้วยรายละเอียดที่จำเป็นทั้งหมดในการดำเนินการบริการ OIDC
คู่มือเล่มนี้มีวัตถุประสงค์เพื่อชี้แจงช่องข้อมูลหลักภายในการตั้งค่านี้ ช่วยให้นักพัฒนาสามารถเข้าใจความสำคัญและการประยุกต์ใช้งานในทางปฏิบัติเพื่อผสาน OIDC เข้ากับโครงการของพวกเขาได้ดียิ่งขึ้น
การตั้งค่า OIDC เป็นไฟล์ JSON ที่คล้ายกับต่อไปนี้:
ถัดไปเราจะเจาะลึกในบางส่วนของช่องข้อมูลหลัก
เมื่อผสานรวมบริการ 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 เป็นเซิร์ฟเวอร์ปลายทางที่ใช้โดยเซิร์ฟเวอร์การอนุญาตในการแลกเปลี่ยนโค้ดการอนุญาตที่กล่าวถึงก่อนหน้านี้เพื่อรับ 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 ซึ่งจำเป็นสำหรับเซิร์ฟเวอร์การอนุญาตส่วนมาก ร่างกายคำขอประกอบด้วยพารามิเตอร์ดังต่อไปนี้:
redirectUri หลังจากที่ผู้ใช้ดำเนินการอนุญาตเสร็จสิ้น"authorization_code" ที่นี่ ซึ่งแสดงว่าตัว token ได้มาจากการใช้โค้ดการอนุญาตฟังก์ชันนี้ถูกดำเนินการแบบอะซิงโครนัสและส่งคืนวัตถุ JSON ที่ประกอบด้วย access token ซึ่งแอปพลิเคชันสามารถใช้เพื่อขอข้อมูลผู้ใช้หรือทำการดำเนินการอื่น ๆ ได้
userinfo_endpoint เป็นเซิร์ฟเวอร์ปลายทางที่ใช้โดยเซิร์ฟเวอร์การอนุญาตในการดึงข้อมูลรายละเอียดเกี่ยวกับผู้ใช้ที่รับรองความถูกต้องแล้ว หลังจากที่ผู้ใช้อนุญาตและได้รับ access tokens สำเร็จผ่านทาง token_endpoint, แอปพลิเคชันสามารถร้องขอเซิร์ฟเวอร์ปลายทางนี้เพื่อเข้าถึงข้อมูลโปรไฟล์ของผู้ใช้ เช่น ชื่อผู้ใช้และที่อยู่อีเมล ข้อมูลที่ได้ระบุเฉพาะขึ้นอยู่กับ scope ที่ผู้ใช้กำหนดไว้ในคำขอการรับรองความถูกต้อง
ในฟังก์ชันนี้ เราใช้วิธี GET ในการร้องขอ userinfo_endpoint รวมทั้งเพิ่มช่อง Authorization ในส่วนหัวของคำขอที่ประกอบด้วย token_type และ accessToken นี่เป็นกระบวนการมาตรฐานตามสเปคของ OAuth 2.0 เพื่อรับข้อมูลผู้ใช้อย่างปลอดภัย นอกจากนี้ ขอบเขตของข้อมูลผู้ใช้ที่เข้าถึงได้ผ่าน access token นั้นขึ้นอยู่กับค่าพารามิเตอร์ scope ที่ผู้ใช้เลือกใช้ตอนเริ่มต้นของการตรวจสอบตัวตน อย่างเช่น ถ้าใช้ขอบเขต email การตอบรับควรรวมถึงที่อยู่อีเมลของผู้ใช้
ผู้ออกบัตรระบุ URL ของเซิร์ฟเวอร์การอนุญาต ขณะที่ jwks_uri ให้ URI สำหรับ JSON Web Key Set (JWKS) ซึ่งเป็นชุดของรหัสสาธารณะที่ใช้ในการยืนยันลายเซ็นของ JWT การยืนยัน issuer ของ JWT และลายเซ็นเป็นขั้นตอนพื้นฐานในการตรวจสอบความปลอดภัยของ token แต่ในสถานการณ์จริง
กระบวนการตรวจสอบมักจะรวมถึงการตรวจสอบระยะเวลาการใช้งานของ token ผู้ชม ขอบเขตการอนุญาต และช่องข้อมูลสำคัญอื่น ๆ
โค้ดต่อไปนี้แสดงหลักการใช้ issuer และ jwks_uri ร่วมกันเพื่อยืนยัน JWT:
ช่อง claims_supported และ scopes_supported ระบุแอตทริบิวต์ผู้ใช้ (claims) และขอบเขตการเข้าถึง (scopes) ที่รับรองโดยเซิร์ฟเวอร์การอนุญาต พวกเขาช่วยให้ไคลเอนต์เข้าใจว่าแอตทริบิวต์ผู้ใช้และขอบเขตการเข้าถึงใด ๆ ที่รองรับโดยเซิร์ฟเวอร์การอนุญาต ทำให้ไคลเอนต์สามารถสร้างคำขอการอนุญาตได้อย่างมีประสิทธิภาพและวิเคราะห์การตอบสนองได้
เมื่อสร้างคำขอการอนุญาต ไคลเอนต์สามารถกำหนด scope ที่จำเป็นตามความต้องการของแอปพลิเคชัน Scope กำหนดทรัพยากรและการดำเนินการที่ไคลเอนต์ขอเข้าถึง เช่น openid, email, profile, และอื่นๆ
สิ่งสำคัญคือควรทราบว่า claims เฉพาะที่เข้าถึงได้ในแต่ละคำขอการอนุญาตจะแตกต่างกันไปตามค่าขอบเขตที่ระบุที่จุดเริ่มต้นของการร้องขอการตรวจสอบตัวตน เช่น ขอบเขต email ให้สิทธิ์การเข้าถึงที่อยู่อีเมลของผู้ใช้ ขณะที่ขอบเขต phone ให้สิทธิ์การเข้าถึงหมายเลขโทรศัพท์ซึ่งไคลเอนต์ควรเลือกลำดับความสำคัญของขอบเขตที่เกี่ยวข้องเพื่อให้เข้ากับความต้องการของแอปพลิเคชันเมื่อสร้างคำขอการอนุญาต เพื่อให้แน่ใจว่าพวกเขาสามารถดึงแอตทริบิวต์ผู้ใช้ที่จำเป็นได้:
ช่อง
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 วันนี้!