คุณกำลังดูเอกสารประกอบ Apigee Edge
ไปที่
เอกสารประกอบเกี่ยวกับ Apigee X. ข้อมูล
ในหัวข้อนี้ เราจะพูดถึงวิธีนำเข้าโทเค็นเพื่อการเข้าถึงที่สร้างจากภายนอก รีเฟรชโทเค็น หรือรหัสการตรวจสอบสิทธิ์ลงในการจัดเก็บโทเค็น Edge คุณใช้เทคนิคนี้ได้หากต้องการ กำหนดค่า Apigee Edge เพื่อตรวจสอบโทเค็นที่สร้างขึ้นนอก Apigee Edge
ในกรณีปกติ Apigee Edge จะสร้างและจัดเก็บโทเค็น OAuth แล้วส่งกลับไปยัง แอปพลิเคชันโทรศัพท์ จากนั้นแอปการโทรจะแสดงโทเค็นดังกล่าวกลับไปยัง Apigee Edge เมื่อส่งคำขอ และ Apigee Edge - ผ่านนโยบาย OAuthV2 ที่มีการดำเนินการ = VerifyAccessToken จะ ยืนยันว่าโทเค็นถูกต้อง หัวข้อนี้จะอธิบายวิธีกำหนดค่า Apigee Edge เพื่อจัดเก็บ โทเค็น OAuth ที่สร้างขึ้นที่อื่นในขณะที่ยังเก็บการยืนยันโทเค็นไว้เหมือนเดิม ราวกับว่าโทเค็นสร้างขึ้นโดย Edge
ตัวอย่าง
หากคุณต้องการดูตัวอย่างที่ใช้ได้จริงซึ่งแสดงเทคนิคนี้ ซึ่งอธิบายไว้ในหัวข้อนี้ โปรดดูที่ Apigee ตัวอย่างการจัดการโทเค็นที่ได้รับมอบสิทธิ์
นี่คืออะไร
สมมติว่าคุณมีระบบการให้สิทธิ์อยู่แล้ว และคุณต้องการใช้ ค่าโทเค็นหรือโค้ดที่ระบบสร้างขึ้นแทนโทเค็น OAuth2 หรือค่าโค้ดที่ Edge สร้างขึ้น จากนั้นคุณจะส่งคำขอพร็อกซี API ที่ปลอดภัยได้ด้วยโทเค็นหรือโค้ดทดแทน และ Edge จะทำการยืนยันราวกับว่าเทคโนโลยีสร้างขึ้นโดย Edge
พื้นหลังบางส่วน
ในกรณีปกติ Apigee Edge จะสร้างโทเค็นโดยสร้างสตริงตัวอักษรแบบสุ่มและ ตัวเลข Apigee Edge จะเชื่อมโยงกับโทเค็นนั้น ข้อมูลอื่นๆ เช่น เวลาที่ออกโทเค็น วันหมดอายุ รายการผลิตภัณฑ์ API ที่โทเค็นใช้งานได้ และขอบเขต ทั้งหมดนี้ อาจแสดงข้อมูลในการตอบสนองที่สร้างขึ้นโดยอัตโนมัติโดยนโยบาย OAuthV2 กำหนดค่าด้วยการดำเนินการ = GenerateAccessToken คำตอบจะมีลักษณะดังนี้
{ "issued_at": "1469735625687", "application_name": "06947a86-919e-4ca3-ac72-036723b18231", "scope": "urn://example.com/read", "status": "approved", "api_product_list": "[implicit-test]", "api_product_list_json": ["implicit-test"], "expires_in": "1799", //--in seconds "developer.email": "joe@weathersample.com", "token_type": "BearerToken", "client_id": "U9AC66e9YFyI1yqaXgUF8H6b9wUN1TLk", "access_token": "zBC90HhCGmGlaMBWeZAai2s3za5j", "organization_name": "wwitman", "refresh_token_expires_in": "0", //--in seconds "refresh_count": "0" }
ค่าของแอตทริบิวต์ access_token คือคีย์การค้นหาที่มีประสิทธิภาพ
ข้อมูลการตอบกลับ แอปสามารถส่งคำขอไปยังพร็อกซี API ที่โฮสต์ใน Edge ได้
ที่มีโทเค็นสำหรับผู้ถือ zBC90HhCGmGlaMBWeZAai2s3za5j
และ Edge ที่มี OAuthV2
นโยบายที่มีการดำเนินการ = VerifyAccessToken - จะค้นหาโทเค็น เรียกดูข้อมูลทั้งหมด
และใช้ข้อมูลดังกล่าวเพื่อพิจารณาว่าโทเค็นถูกต้องหรือไม่สำหรับพร็อกซี API ที่ขอ
ซึ่งเรียกว่าการตรวจสอบโทเค็น ข้อมูลทั้งหมดข้างต้นประกอบด้วยโทเค็น
ค่า Access_token เป็นเพียงวิธีค้นหาข้อมูลนั้น
ในทางกลับกัน คุณจะกำหนดค่า Edge เพื่อจัดเก็บ เพื่อให้ค่า access_token สร้างขึ้นโดยผู้ใช้ภายนอก service. ข้อมูลเมตาอื่นๆ ทั้งหมดอาจเหมือนกัน ตัวอย่างเช่น สมมติว่าคุณมีระบบ ภายนอก Apigee Edge ที่จะสร้างโทเค็นในรูปแบบ "TOKEN-<16 แบบสุ่ม ตัวเลข>" ที่ใช้เวลาเพียง 2 นาที ในกรณีดังกล่าว ข้อมูลเมตาของโทเค็นแบบเต็มที่ Apigee Edge จัดเก็บไว้อาจมีลักษณะดังนี้
{ "issued_at": "1469735625687", "application_name": "06947a86-919e-4ca3-ac72-036723b18231", "scope": "urn://example.com/read", "status": "approved", "api_product_list": "[implicit-test]", "api_product_list_json": ["implicit-test"], "expires_in": "1799", //--in seconds "developer.email": "joe@weathersample.com", "token_type": "BearerToken", "client_id": "U9AC66e9YFyI1yqaXgUF8H6b9wUN1TLk", "access_token": "TOKEN-1092837373654221", "organization_name": "wwitman", "refresh_token_expires_in": "0", //--in seconds "refresh_count": "0" }
ในกรณีนี้ แอปอาจส่งคำขอไปยังพร็อกซี API ที่โฮสต์ใน Edge ซึ่งมีผู้ถือ
โทเค็น TOKEN-1092837373654221
และ Edge - ผ่านนโยบาย OAuthV2 ที่มีการดำเนินการ =
VerifyAccessToken - จะสามารถตรวจสอบความถูกต้องได้ คุณสามารถใช้รูปแบบการนำเข้าที่คล้ายกันกับ
รหัสการให้สิทธิ์และโทเค็นการรีเฟรช
มาพูดถึงการตรวจสอบความถูกต้องของไคลเอ็นต์กัน ข้อมูลเข้าสู่ระบบ
ข้อกำหนดเบื้องต้นอย่างหนึ่งในการสร้างโทเค็นคือการตรวจสอบไคลเอ็นต์ที่ส่งคำขอ โดยค่าเริ่มต้น แอตทริบิวต์ นโยบาย OAuthV2/GenerateAccessToken ใน Apigee Edge ยืนยันข้อมูลเข้าสู่ระบบไคลเอ็นต์โดยปริยาย ตามปกติแล้วในคำขอสำหรับโทเค็น OAuthV2 จะมีการส่ง client_id และ client_secret ใน ส่วนหัวการให้สิทธิ์ ซึ่งเข้ารหัสผ่านการให้สิทธิ์พื้นฐาน HTTP (ต่อด้วยโคลอน จากนั้น เข้ารหัส base64) นโยบาย OAuthV2/GenerateAccessToken ใน Apigee Edge จะถอดรหัสส่วนหัวนั้นและ ค้นหา client_id และยืนยันว่า client_secret ที่ส่งต่อนั้นถูกต้อง client_id. วิธีนี้จะได้ผลหาก Apigee Edge รู้จักข้อมูลเข้าสู่ระบบ กล่าวคือ แอปนักพัฒนาซอฟต์แวร์ที่จัดเก็บภายใน Apigee Edge ซึ่งมีข้อมูลเข้าสู่ระบบที่มี ที่ให้ client_id และ client_secret
ในกรณีที่ Apigee Edge ไม่ยืนยันข้อมูลเข้าสู่ระบบไคลเอ็นต์ คุณต้อง ออกแบบพร็อกซี API ของคุณก่อนที่จะสร้างโทเค็น เพื่อตรวจสอบไคลเอ็นต์อย่างชัดเจนผ่าน วิธีอื่นๆ ซึ่งมักจะเป็นการดำเนินการผ่านนโยบาย Serviceข้อความไฮไลต์ ซึ่ง เชื่อมต่อกับปลายทางระยะไกลในเครือข่ายของคุณ
ไม่ว่าจะโดยนัยหรือโดยชัดแจ้ง คุณจะต้องตรวจสอบว่าพร็อกซี API ที่สร้างโทเค็น ให้ตรวจสอบข้อมูลเข้าสู่ระบบของไคลเอ็นต์ก่อน โปรดทราบว่าการตรวจสอบ ไม่อิสระในการสร้างโทเค็นเพื่อการเข้าถึง คุณกำหนดค่า Apigee Edge เพื่อทำทั้ง 2 อย่างได้ ดำเนินการอย่างใดอย่างหนึ่ง หรือไม่ดำเนินการเลย
หากต้องการให้นโยบาย OAuthV2/GenerateAccessToken ใน Apigee Edge ตรวจสอบไคลเอ็นต์
ข้อมูลเข้าสู่ระบบสำหรับ Edge Store ให้ตั้งค่าองค์ประกอบ <ExternalAuthorization>
เป็น
false
ในการกำหนดค่านโยบาย หรือไม่ระบุค่าทั้งหมด หากคุณต้องการใช้
บริการให้สิทธิ์ภายนอกเพื่อตรวจสอบ ข้อมูลเข้าสู่ระบบไคลเอ็นต์อย่างชัดเจน ตั้งค่า
<ExternalAuthorization>
ไปยัง true
แม้ว่า Apigee Edge อาจไม่ตรวจสอบข้อมูลเข้าสู่ระบบของไคลเอ็นต์ แต่ก็ยังคงจำเป็นสำหรับ client_id จะรู้จักและจัดการโดย Apigee Edge Access_token ทั้งหมดใน Apigee Edge ไม่ว่า ที่สร้างโดย Apigee Edge หรือสร้างโดยระบบภายนอกแล้วนำเข้าไปยัง Apigee Edge ต้องเชื่อมโยงกับแอปพลิเคชันไคลเอ็นต์ ซึ่งระบุด้วย client_id ดังนั้นในกรณี โดยที่นโยบาย OAuthV2/GenerateAccessToken ใน Apigee Edge จะไม่ตรวจสอบว่า client_id และ client_secret ที่ตรงกัน นโยบายจะตรวจสอบว่า client_id ถูกต้อง เป็นปัจจุบัน และไม่ถูกต้อง เพิกถอน ดังนั้น คุณอาจต้องนำเข้า client_id ผ่านทาง Edge เพื่อเป็นการทำขั้นตอนการตั้งค่าเบื้องต้น API การดูแลระบบ
โฟลว์นโยบายสำหรับ OAuth ของบุคคลที่สามใน Apigee
หากต้องการใช้โทเค็นจากระบบ OAuth ของบุคคลที่สามใน Apigee Edge ขั้นตอนในการสร้างการเข้าถึงมีดังนี้ โทเค็นควรเป็นไปตามรูปแบบใดรูปแบบหนึ่งต่อไปนี้
แบบต่อภายนอก การตรวจสอบข้อมูลเข้าสู่ระบบไคลเอ็นต์
- ServiceCallout เพื่อยืนยันข้อมูลเข้าสู่ระบบของลูกค้าขาเข้า และรับโทเค็นภายนอก
- ExtractVariables หรือ ขั้นตอน JavaScript เพื่อ แยกโทเค็นที่สร้างจากภายนอกจากการตอบกลับ
- AssignMessageให้
ตั้งค่าตัวแปรพิเศษที่รู้จักในชื่อ
oauth_external_authorization_status
ค่าต้องเป็น "จริง" เพื่อระบุว่าข้อมูลเข้าสู่ระบบไคลเอ็นต์ถูกต้อง - OAuthV2/GenerateAccessToken พร้อม
ตั้งค่าองค์ประกอบ
<ExternalAuthorization>
เป็นtrue
และอย่างน้อย 1 องค์ประกอบแล้ว ของ<ExternalAccessToken>
,<ExternalRefreshToken>
หรือ<ExternalAuthorizationCode>
ติดตั้งมากับเครื่อง การตรวจสอบข้อมูลเข้าสู่ระบบไคลเอ็นต์
- ServiceCallout ในการรับโทเค็นภายนอก
- ExtractVariables หรือ ขั้นตอน JavaScript เพื่อ แยกโทเค็นที่สร้างจากภายนอกจากการตอบกลับ
- OAuthV2/GenerateAccessToken พร้อม
ตั้งค่าองค์ประกอบ
<ExternalAuthorization>
เป็นfalse
และอย่างน้อย 1 องค์ประกอบแล้ว ของ<ExternalAccessToken>
,<ExternalRefreshToken>
หรือ<ExternalAuthorizationCode>
หมายเหตุเกี่ยวกับการกำหนดค่าโฟลว์และนโยบาย
-
ในกรณีที่คุณต้องการใช้ระบบภายนอกเพื่อตรวจสอบข้อมูลรับรองของไคลเอ็นต์ การพัฒนาแนวทางนโยบายโดยทำสิ่งที่จำเป็น โดยปกติคุณจะใช้ นโยบาย Serviceข้อความไฮไลต์ เพื่อส่งข้อมูลเข้าสู่ระบบที่ได้รับการยอมรับจากภายนอกไปยังภายนอก บริการตรวจสอบสิทธิ์ โดยปกติแล้ว บริการตรวจสอบสิทธิ์ภายนอกจะแสดงการตอบกลับ และหากข้อมูลเข้าสู่ระบบถูกต้อง ก็ใช้โทเค็นเพื่อการเข้าถึงได้ด้วย
-
หลังจาก Serviceข้อความไฮไลต์ พร็อกซี API จะต้องแยกวิเคราะห์การตอบกลับเพื่อดึงข้อมูล สถานะการตรวจสอบความถูกต้อง รวมถึงaccess_token ที่สร้างขึ้นจากภายนอก และอาจมี refresh_token.
-
ในนโยบาย OAuthV2/GenerateAccessToken ให้ตั้งค่าองค์ประกอบ
<StoreToken>
เป็นtrue
และตั้งค่าองค์ประกอบ<ExternalAuthorization>
เป็นtrue
หรือfalse
ตามความเหมาะสมเมื่อนโยบาย OAuthV2/GenerateAccessToken ทำงาน นโยบายจะอ่านตัวแปร
oauth_external_authorization_status
หากมีการตั้งค่าตัวแปรและค่าเป็น Apigee Edge จะไม่พยายามตรวจสอบข้อมูลเข้าสู่ระบบของไคลเอ็นต์ หากตัวแปร ไม่ได้ตั้งค่าไว้หรือค่าไม่เป็นจริง Apigee Edge จะพยายามตรวจสอบไคลเอ็นต์ ข้อมูลเข้าสู่ระบบ -
มีองค์ประกอบ 3 อย่างสำหรับนโยบาย OAuthV2 ที่ให้คุณระบุข้อมูลภายนอก ข้อมูลที่จะนำเข้า:
<ExternalAccessToken>
,<ExternalRefreshToken>
, และ<ExternalAuthorizationCode>
องค์ประกอบแต่ละรายการเหล่านี้ยอมรับ ตัวแปรโฟลว์ นโยบาย Edge จะอ่านตัวแปรนั้นเพื่อค้นหา โทเค็นเพื่อการเข้าถึงที่สร้างขึ้นจากภายนอก โทเค็นการรีเฟรช หรือรหัสการให้สิทธิ์ ทั้งหมดขึ้นอยู่กับคุณ ใช้นโยบายและตรรกะเพื่อวางโทเค็นหรือโค้ดภายนอก ตัวแปรตัวอย่างเช่น การกำหนดค่าต่อไปนี้ในนโยบาย OAuthV2 จะแจ้งให้ Edge ให้ค้นหาพารามิเตอร์ โทเค็นในตัวแปรบริบทที่ชื่อ
external_token
<ExternalAccessToken>external_token</ExternalAccessToken>
นอกจากนี้ คุณจะต้องมีขั้นตอนก่อนหน้าที่กำหนดตัวแปรนั้นด้วย
-
เกี่ยวกับการตั้งค่าตัวแปร
oauth_external_authorization_status
เทคนิคในการตั้งค่าตัวแปรนี้คือการใช้นโยบาย AssignMessage กับ องค์ประกอบ AssignVariable ดังนี้<AssignMessage name="AssignMessage-SetVariable"> <DisplayName>Assign Message - Set Variable</DisplayName> <AssignVariable> <Name>oauth_external_authorization_status</Name> <Value>true</Value> </AssignVariable> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </AssignMessage>
อย่าลืมว่านโยบายนี้ต้องอยู่ก่อนนโยบาย OAuthV2 ที่มีการดำเนินการ = GenerateAccessToken.
ตัวอย่างนโยบาย OAuthV2
นโยบาย OAuthV2 ต่อไปนี้
สร้างโทเค็นเพื่อการเข้าถึง Apigee Edge เมื่อ Edge พบ
ค่าโทเค็นในตัวแปรโฟลว์ external_access_token
<OAuthV2 name="OAuth-v20-Store-External-Token"> <ExternalAccessToken>external_access_token</ExternalAccessToken> <ExternalAuthorization>true</ExternalAuthorization> <Operation>GenerateAccessToken</Operation> <GenerateResponse enabled="true"> <Format>FORM_PARAM</Format> </GenerateResponse> <ReuseRefreshToken>false</ReuseRefreshToken> <StoreToken>true</StoreToken> <SupportedGrantTypes> <GrantType>client_credentials</GrantType> </SupportedGrantTypes> <ExpiresIn ref='flow.variable'>2400000</ExpiresIn> </OAuthV2>
ในทางทฤษฎี คุณสามารถใช้รูปแบบนี้กับการให้สิทธิ์ OAuth2 ของบุคคลที่สามรายการใดก็ได้ service.