ในโลกดิจิทัลของวันนี้ การตรวจสอบตัวตนได้กลายเป็นส่วนประกอบหลักในการรักษาความปลอดภัยของเว็บไซต์และแอปพลิเคชัน OpenID Connect (OIDC) ซึ่งเป็นเลเยอร์การตรวจสอบตัวตนที่สร้างขึ้นบนโปรโตคอล OAuth 2.0 ให้การตรวจสอบตัวตนในรูปแบบที่ได้มาตรฐานและตรงไปตรงมา อย่างไรก็ตาม การผสานรวม OIDC อย่างถูกต้องอาจเป็นที่ท้าทาย โดยเฉพาะสำหรับผู้เริ่มต้น จุดเริ่มต้นที่ดีมักจะเป็นไฟล์การตั้งค่า OIDC ที่มักจะพบที่ URL `{authServerUrl}/.well-known/openid-configuration` ซึ่งประกอบด้วยรายละเอียดที่จำเป็นทั้งหมดในการดำเนินการบริการ OIDC คู่มือเล่มนี้มีวัตถุประสงค์เพื่อชี้แจงช่องข้อมูลหลักภายในการตั้งค่านี้ ช่วยให้นักพัฒนาสามารถเข้าใจความสำคัญและการประยุกต์ใช้งานในทางปฏิบัติเพื่อผสาน OIDC เข้ากับโครงการของพวกเขาได้ดียิ่งขึ้น ## การวิเคราะห์ช่องข้อมูลการตั้งค่า OIDC การตั้งค่า OIDC เป็นไฟล์ JSON ที่คล้ายกับต่อไปนี้: ```json { "authorization_endpoint": "", "claims_parameter_supported": false, "claims_supported": [ "sub", "name", "profile", "email", "email_verified", "phone_number", "phone_number_verified" ], "code_challenge_methods_supported": ["S256"], "grant_types_supported": [ "implicit", "authorization_code", "refresh_token", "client_credentials" ], "issuer": "", "jwks_uri": "", "response_modes_supported": ["form_post", "fragment", "query"], "response_types_supported": ["code id_token", "code", "id_token", "none"], "scopes_supported": ["openid", "offline_access", "profile", "email", "phone"], "subject_types_supported": ["public"], "token_endpoint_auth_methods_supported": [ "client_secret_basic", "client_secret_jwt", "client_secret_post" ], "token_endpoint_auth_signing_alg_values_supported": ["HS256"], "token_endpoint": "", "userinfo_endpoint": "" } ``` ถัดไปเราจะเจาะลึกในบางส่วนของช่องข้อมูลหลัก ### authorization_endpoint เมื่อผสานรวมบริการ OIDC ขั้นตอนแรกมักจะเกี่ยวข้องกับการจัดการคำขอเข้าสู่ระบบของผู้ใช้ภายในแอปพลิเคชัน กระบวนการนี้รวมถึงการเปลี่ยนเส้นทางผู้ใช้ไปยัง `authorization_endpoint` ของเซิร์ฟเวอร์การอนุญาต จุดนี้เป็นที่อยู่ของเซิร์ฟเวอร์ที่ส่งคำขอการอนุญาต นำพาผู้ใช้ไปยังหน้าลงชื่อเข้าใช้สำหรับการตรวจสอบตัวตน เมื่อทำการร้องขอต่อ `authorization_endpoint` จะต้องตั้งค่าด้วยพารามิเตอร์คำถามเพิ่มเติมสำหรับแต่ละการอนุญาต: - `response_type`: ระบุประเภทของการอนุญาตที่ได้รับกลับคืน ซึ่งมักจะรวมถึง "code" (สำหรับการไหลของ authorization code), "token" (สำหรับการไหล implicit), และ "id_token token" หรือ "code id_token" (สำหรับการไหล hybrid) ซึ่งสามารถพบได้ในช่อง `response_types_supported` ของการตั้งค่า OIDC - `client_id`: ตัวระบุเฉพาะที่กำหนดให้แก่แอปพลิเคชันโดยเซิร์ฟเวอร์การอนุญาตเมื่อแอปถูกลงทะเบียน ตัวตัวระบุตัวนี้ใช้โดยเซิร์ฟเวอร์การอนุญาตเพื่อรู้จักแอปพลิเคชันไคลเอนต์ที่เริ่มต้นคำขอ - `scope`: กำหนดขอบเขตของการเข้าถึงที่ร้องขอ ระบุทรัพยากรหรือข้อมูลผู้ใช้ที่สามารถเข้าถึงได้ ขอบเขตที่พบบ่อยรวมถึง "openid" (บังคับ), "profile", และ "email" เป็นต้น คุณสามารถพบขอบเขตที่รองรับในช่อง `scopes_supported` ของการตั้งค่า OIDC; ขอบเขตที่แตกต่างกันควรถูกแยกด้วยช่องว่าง - `redirect_uri`: หลังจากการลงชื่อเข้าหรือการอนุญาต เซิร์ฟเวอร์การอนุญาตจะเปลี่ยนเส้นทางผู้ใช้กลับไปยัง URI ที่ให้มาโดยแอปพลิเคชัน URI นี้ต้องตรงกันกับ URI ที่ให้ในระหว่างการลงทะเบียนแอปพลิเคชัน - `state`: สายอักขระที่สร้างแบบสุ่มใช้เพื่อปกป้องไคลเอนต์จากการโจมตี cross-site request forgery ความสม่ำเสมอของ state ระหว่างคำขอการอนุญาตและการตีกลับต้องถูกรักษาไว้เพื่อความปลอดภัย พารามิเตอร์เหล่านี้อนุญาตให้นักพัฒนาควบคุมพฤติกรรมของคำขอการอนุญาต OIDC อย่างถูกต้อง เพื่อให้แน่ใจว่ามีความปลอดภัยและตรงกับความต้องการของแอปพลิเคชัน ```js // สร้าง URL คำขอการอนุญาต function createAuthRequestURL(clientId, redirectUri, scope, responseType, state) { const url = new URL(config.authorization_endpoint); url.searchParams.append('response_type', responseType); url.searchParams.append('client_id', clientId); // URI เปลี่ยนเส้นทางที่ผู้ใช้ถูกเปลี่ยนเส้นทางหลังจากเข้าสู่ระบบ url.searchParams.append('redirect_uri', redirectUri); // ขอบเขตการอนุญาตที่ร้องขอ เช่น "openid email profile" url.searchParams.append('scope', scope); // ค่าของ state แบบสุ่มเพื่อป้องกันการโจมตี CSRF url.searchParams.append('state', state); return url.toString(); } ``` หลังจากเสร็จสิ้นคำขอต่อ `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`): ```js // แลกเปลี่ยนโค้ดการอนุญาตเพื่อ access tokens async function fetchTokens(code, redirectUri, clientId, clientSecret) { const response = await fetch(config.token_endpoint, { method: 'POST', headers: { 'Content-Type': 'application/x-www-form-urlencoded', }, body: `code=${code}&redirect_uri=${redirectUri}&client_id=${clientId}&client_secret=${clientSecret}&grant_type=authorization_code`, }); return await response.json(); } ``` ในโค้ดนี้ เราส่งคำขอไปยัง `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` ที่ผู้ใช้กำหนดไว้ในคำขอการรับรองความถูกต้อง ```js // ดึงข้อมูลผู้ใช้ async function fetchUserInfo(accessToken, tokenType) { const response = await fetch(config.userinfo_endpoint, { method: 'GET', // เรียกใช้ userinfo_endpoint โดยใช้วิธี GET headers: { /** * ใช้ประเภทของ token และ access token * ประเภทของ token ที่ส่งคืนมากับ access token โดย token endpoint */ Authorization: `${tokenType} ${accessToken}`, }, }); if (!response.ok) { throw new Error('ไม่สามารถดึงข้อมูลผู้ใช้ได้'); } return await response.json(); // แปลงและส่งคืนข้อมูลผู้ใช้ในรูปแบบ JSON } ``` ในฟังก์ชันนี้ เราใช้วิธี `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: ```js import { jwtVerify } from 'jose'; // สมมติว่าคุณได้รับการตั้งค่า OIDC แล้ว const config = { issuer: '', jwks_uri: '', }; // ดึง JWKS async function fetchJWKS() { const response = await fetch(config.jwks_uri); const { keys } = await response.json(); return keys; } // ตรวจสอบ token async function validateToken(token, audience) { try { const jwks = await fetchJWKS(); const { payload } = await jwtVerify(token, jwks, { issuer: config.issuer, audience, }); console.log('Token validated successfully:', payload); return true; } catch (error) { console.error('Failed to validate token:', error); return false; } } ``` ### scopes_supported & claims_supported ช่อง `claims_supported` และ `scopes_supported` ระบุแอตทริบิวต์ผู้ใช้ (claims) และขอบเขตการเข้าถึง (scopes) ที่รับรองโดยเซิร์ฟเวอร์การอนุญาต พวกเขาช่วยให้ไคลเอนต์เข้าใจว่าแอตทริบิวต์ผู้ใช้และขอบเขตการเข้าถึงใด ๆ ที่รองรับโดยเซิร์ฟเวอร์การอนุญาต ทำให้ไคลเอนต์สามารถสร้างคำขอการอนุญาตได้อย่างมีประสิทธิภาพและวิเคราะห์การตอบสนองได้ เมื่อสร้างคำขอการอนุญาต ไคลเอนต์สามารถกำหนด `scope` ที่จำเป็นตามความต้องการของแอปพลิเคชัน `Scope` กำหนดทรัพยากรและการดำเนินการที่ไคลเอนต์ขอเข้าถึง เช่น `openid`, `email`, `profile`, และอื่นๆ สิ่งสำคัญคือควรทราบว่า claims เฉพาะที่เข้าถึงได้ในแต่ละคำขอการอนุญาตจะแตกต่างกันไปตามค่าขอบเขตที่ระบุที่จุดเริ่มต้นของการร้องขอการตรวจสอบตัวตน เช่น ขอบเขต email ให้สิทธิ์การเข้าถึงที่อยู่อีเมลของผู้ใช้ ขณะที่ขอบเขต phone ให้สิทธิ์การเข้าถึงหมายเลขโทรศัพท์ซึ่งไคลเอนต์ควรเลือกลำดับความสำคัญของขอบเขตที่เกี่ยวข้องเพื่อให้เข้ากับความต้องการของแอปพลิเคชันเมื่อสร้างคำขอการอนุญาต เพื่อให้แน่ใจว่าพวกเขาสามารถดึงแอตทริบิวต์ผู้ใช้ที่จำเป็นได้: ```js // สร้าง URL คำขอการอนุญาต function createAuthRequestURL(clientId, redirectUri, scope, responseType) { const url = new URL(config.authorization_endpoint); url.searchParams.append('response_type', responseType); url.searchParams.append('client_id', clientId); url.searchParams.append('redirect_uri', redirectUri); // ระบุขอบเขตที่ต้องการในคำขอการอนุญาต url.searchParams.append('scope', scope); return url.toString(); } ``` ### token_endpoint_auth_methods_supported ช่อง `token_endpoint_auth_methods_supported` ระบุวิธีการตรวจสอบสิทธิ์ที่รองรับโดย token endpoint วิธีการเหล่านี้ใช้โดยไคลเอนต์ในการตรวจสอบสิทธิ์กับเซิร์ฟเวอร์การอนุญาตเมื่อแลกเปลี่ยนโค้ดการอนุญาตเพื่อรับ access tokens เมื่อทำการตรวจสอบสิทธิ์โดยใช้ token endpoint วิธีการตรวจสอบสิทธิ์ทั่วไป ได้แก่ `client_secret_post`, `client_secret_basic` และ `client_secret_jwt`. - `client_secret_post`: ไคลเอนต์ใช้ตัวระบุไคลเอนต์และความลับของไคลเอนต์ในการสร้างร่างกายที่เข้ารหัสเป็นฟอร์มซึ่งถูกส่งเป็นส่วนหนึ่งของร่างกายคำขอ เราได้เห็นตัวอย่างของวิธีนี้ในส่วน `token_endpoint` ข้างต้นแล้ว - `client_secret_basic`: ไคลเอนต์ใช้ตัวระบุไคลเอนต์และความลับของไคลเอนต์ในการสร้างส่วนหัวของการตรวจสอบสิทธิ์แบบพื้นฐานซึ่งถูกเพิ่มในส่วนหัวของคำขอ ```js // ใช้วิธีการตรวจสอบสิทธิ์ client_secret_basic const headersBasic = new Headers(); headersBasic.append( 'Authorization', `Basic ${Buffer.from(`${clientId}:${clientSecret}`).toString('base64')}` ); // จากนั้นส่งคำขอด้วยส่วนหัวการตรวจสอบสิทธิ์พื้นฐานเพื่อรับ access token // ... ``` - `client_secret_jwt`: ไคลเอนต์ใช้ JWT (JSON Web Token) เป็นการยืนยันของไคลเอนต์ในการตรวจสอบสิทธิ์. JWT นี้ประกอบด้วยตัวระบุไคลเอนต์และเมทาดาทาเพิ่มเติมบางอย่างและเซ็นโดยใช้ความลับของไคลเอนต์ หลังจากรับคำขอ เซิร์ฟเวอร์การอนุญาตตรวจสอบตัวตนของไคลเอนต์โดยตรวจสอบลายเซ็นของ JWT ```js // ใช้วิธีการตรวจสอบสิทธิ์ client_secret_jwt const clientSecretJwt = await new SignJWT({ iss: clientId, sub: clientId, aud: tokenEndpoint, jti: randomString(), exp: Math.floor(Date.now() / 1000) + 600, // เวลาหมดอายุคือ 10 นาที iat: Math.floor(Date.now() / 1000), }) .setProtectedHeader({ alg: 'HS256', }) .sign(Buffer.from(clientSecret)); // เพิ่มการยืนยัน JWT ในร่างกายคำขอ const params = new URLSearchParams(); params.append('grant_type', 'authorization_code'); params.append('code', authorizationCode); // เพิ่มพารามิเตอร์การยืนยันของไคลเอนต์ params.append('client_assertion_type', 'urn:ietf:params:oauth:client-assertion-type:jwt-bearer'); params.append('client_assertion', clientSecretJwt); // ส่งคำขอและรับ access token const tokenResponse = await fetch(tokenEndpoint, { method: 'POST', headers: { 'Content-Type': 'application/x-www-form-urlencoded', }, body: params, }); ``` ในการใช้งานจริง ไคลเอนต์จำเป็นต้องเลือกวิธีการตรวจสอบสิทธิ์ที่เหมาะสมตามวิธีที่เซิร์ฟเวอร์การอนุญาตรองรับ และต้องแน่ใจว่าข้อมูลการตรวจสอบสิทธิ์ถูกเพิ่มไปยังคำขออย่างถูกต้องเพื่อแลกเปลี่ยนโค้ดการอนุญาตเพื่อรับ access tokens อย่างปลอดภัย ## บทสรุป เราได้สำรวจช่องข้อมูลหลักในการตั้งค่า OIDC โดยมุ่งเน้นไปที่วัตถุประสงค์และการประยุกต์ใช้ของมัน การทำความเข้าใจรายละเอียดเหล่านี้จะช่วยเพิ่มความเข้าใจของคุณต่อ OpenID Connect ทำให้คุณสามารถผสานรวมและใช้งานมันได้อย่างมีประสิทธิภาพมากขึ้นในโครงการของคุณ ด้วยความรู้ที่ได้รับคุณพร้อมที่จะแฮนเดิล OIDC ซึ่งจะนำไปสู่การตรวจสอบตัวตนของผู้ใช้ที่ปลอดภัยและมีประสิทธิภาพมากขึ้น Logto เป็นบริการตรวจสอบตัวตนที่สร้างขึ้นบน OIDC ซึ่งมีชุด SDK ที่ครอบคลุมในหลายภาษา พร้อมทั้งคำแนะนำในการผสานรวมที่หลากหลาย ช่วยให้คุณสามารถผสานรวมการเข้าสู่ระบบ OAuth / OIDC เข้ากับแอปพลิเคชันของคุณได้อย่างราบรื่นในเวลาเพียงไม่กี่นาที หากคุณกำลังมองหาบริการ OIDC ที่เชื่อถือได้และใช้งานง่าย ลองใช้ Logto วันนี้! ลองใช้ Logto วันนี้!