การใช้โทเค็น OAuth ของบุคคลที่สาม

คุณกำลังดูเอกสารประกอบของ Apigee Edge
ไปที่ เอกสารประกอบของ Apigee X info

ในหัวข้อนี้ เราจะพูดถึงวิธีนำเข้าโทเค็นเพื่อการเข้าถึง โทเค็นเพื่อการรีเฟรช หรือรหัสการให้สิทธิ์ที่สร้างขึ้นภายนอกไปยังที่เก็บโทเค็นของ Edge คุณสามารถใช้เทคนิคนี้ได้หากต้องการ กำหนดค่า Apigee Edge เพื่อตรวจสอบโทเค็นที่สร้างขึ้นภายนอก Apigee Edge

ในกรณีปกติ Apigee Edge จะสร้างและจัดเก็บโทเค็น OAuth แล้วส่งคืนโทเค็นดังกล่าวไปยัง แอปพลิเคชันที่เรียก จากนั้นแอปที่เรียกจะส่งโทเค็นนั้นกลับไปยัง Apigee Edge เมื่อส่งคำขอรับ บริการ และ Apigee Edge จะตรวจสอบว่าโทเค็นถูกต้องหรือไม่ผ่านนโยบาย OAuthV2 ที่มี Operation = VerifyAccessToken หัวข้อนี้อธิบายวิธีกำหนดค่า Apigee Edge เพื่อจัดเก็บ โทเค็น OAuth ที่สร้างขึ้นที่อื่น โดยยังคงส่วนการตรวจสอบโทเค็นไว้เหมือนเดิม ราวกับว่าโทเค็นนั้นสร้างขึ้นโดย Edge

ตัวอย่าง

หากต้องการดูตัวอย่างการทำงานที่แสดงเทคนิค ที่อธิบายไว้ในหัวข้อนี้ โปรดดูตัวอย่างการจัดการโทเค็นที่มอบสิทธิ์ของ Apigee

นี่คืออะไร

สมมติว่าคุณมีระบบการให้สิทธิ์อยู่แล้ว และต้องการใช้ค่าโทเค็นหรือค่ารหัสที่ระบบนั้นสร้างขึ้นแทนค่าโทเค็นหรือค่ารหัส OAuth2 ที่ Edge สร้างขึ้น จากนั้นคุณจะส่งคำขอพร็อกซี API ที่ปลอดภัยด้วยโทเค็นหรือรหัสที่แทนที่ และ Edge จะตรวจสอบโทเค็นหรือรหัสเหล่านั้นราวกับว่าสร้างขึ้นโดย Edge

ข้อมูลเบื้องต้น

ในกรณีปกติ Apigee Edge จะสร้างโทเค็นโดยสร้างสตริงตัวอักษรและ ตัวเลขแบบสุ่ม Apigee Edge จะเชื่อมโยงข้อมูลอื่นๆ กับโทเค็นนั้น เช่น เวลาที่ออกโทเค็น วันที่หมดอายุ รายการผลิตภัณฑ์ API ที่โทเค็นใช้ได้ และขอบเขต ระบบจะส่งคืนข้อมูลทั้งหมดนี้ ในคำตอบที่สร้างขึ้นโดยอัตโนมัติโดยนโยบาย OAuthV2 ที่กำหนดค่าด้วย Operation = 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 จะค้นหาโทเค็น ดึงข้อมูลทั้งหมด และใช้ข้อมูลนั้นเพื่อพิจารณาว่าโทเค็นถูกต้องหรือไม่สำหรับพร็อกซี API ที่ขอ ผ่านนโยบาย OAuthV2 ที่มี Operation = VerifyAccessToken ซึ่งเรียกว่า การตรวจสอบโทเค็น ข้อมูลทั้งหมดข้างต้นประกอบกันเป็นโทเค็น ค่า access_token เป็นเพียงวิธีค้นหาข้อมูลนั้น

ในทางกลับกัน การทำตามขั้นตอนที่อธิบายไว้ที่นี่จะช่วยให้คุณกำหนดค่า Edge เพื่อจัดเก็บโทเค็น เพื่อให้ค่า access_token เป็นค่าที่สร้างขึ้นโดยบริการภายนอก ข้อมูลเมตาอื่นๆ ทั้งหมดอาจเหมือนกัน เช่น สมมติว่าคุณมีระบบ ภายนอก Apigee Edge ที่สร้างโทเค็นในรูปแบบ "TOKEN-<16 random numbers>" ในกรณีนี้ ข้อมูลเมตาโทเค็นแบบเต็มที่ 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 ที่มี Operation = 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 ก่อนที่จะสร้างโทเค็น เพื่อตรวจสอบไคลเอ็นต์อย่างชัดแจ้งด้วยวิธี อื่น ซึ่งมักจะทำผ่านนโยบาย ServiceCallout ที่ เชื่อมต่อกับปลายทางระยะไกลในเครือข่าย

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

หากต้องการให้นโยบาย OAuthV2/GenerateAccessToken ใน Apigee Edge ตรวจสอบข้อมูลเข้าสู่ระบบของไคลเอ็นต์ กับที่เก็บของ Edge ให้ตั้งค่าองค์ประกอบ <ExternalAuthorization> เป็น false ภายในการกำหนดค่านโยบาย หรือละเว้นองค์ประกอบนี้ไปเลย หากต้องการใช้บริการการให้สิทธิ์ภายนอกเพื่อตรวจสอบข้อมูลเข้าสู่ระบบของไคลเอ็นต์อย่างชัดแจ้ง ให้ตั้งค่า <ExternalAuthorization> เป็น true

แม้ว่า Apigee Edge อาจไม่ได้ตรวจสอบข้อมูลเข้าสู่ระบบของไคลเอ็นต์ แต่ Apigee Edge ก็ยังต้องทราบและจัดการ client_id access_token ทุกรายการใน Apigee Edge ไม่ว่าจะ สร้างขึ้นโดย Apigee Edge หรือสร้างขึ้นโดยระบบภายนอกแล้วนำเข้าไปยัง Apigee Edge, จะต้องเชื่อมโยงกับแอปพลิเคชันไคลเอ็นต์ ซึ่งระบุโดย client_id ดังนั้น แม้ในกรณีที่ นโยบาย OAuthV2/GenerateAccessToken ใน Apigee Edge จะไม่ตรวจสอบว่า client_id และ client_secret ตรงกันหรือไม่ นโยบายจะตรวจสอบว่า client_id ถูกต้อง มีอยู่ และไม่ ถูกเพิกถอน ดังนั้น คุณอาจต้องนำเข้า client_id ผ่าน Edge Administrative API เป็นขั้นตอนการตั้งค่าเบื้องต้น

โฟลว์นโยบายสำหรับ OAuth ของบุคคลที่สามใน Apigee

หากต้องการใช้โทเค็นจากระบบ OAuth ของบุคคลที่สามใน Apigee Edge โฟลว์สำหรับการสร้างโทเค็นเพื่อการเข้าถึง ควรเป็นไปตามรูปแบบใดรูปแบบหนึ่งต่อไปนี้

การตรวจสอบข้อมูลเข้าสู่ระบบของไคลเอ็นต์ภายนอก

  1. ServiceCallout เพื่อตรวจสอบข้อมูลเข้าสู่ระบบของไคลเอ็นต์ขาเข้าและรับโทเค็นภายนอก
  2. ExtractVariables หรือ ขั้นตอน JavaScript เพื่อ ดึงโทเค็นที่สร้างขึ้นภายนอกจากคำตอบ
  3. AssignMessage เพื่อ ตั้งค่าตัวแปรที่รู้จักกันดีเป็นพิเศษที่เรียกว่า oauth_external_authorization_status ค่าต้องเป็น "จริง" เพื่อระบุว่าข้อมูลเข้าสู่ระบบของไคลเอ็นต์ถูกต้อง
  4. OAuthV2/GenerateAccessToken ที่มีองค์ประกอบ <ExternalAuthorization> ตั้งค่าเป็น true และมีองค์ประกอบ <ExternalAccessToken>, <ExternalRefreshToken> หรือ <ExternalAuthorizationCode> อย่างน้อย 1 รายการ

การตรวจสอบข้อมูลเข้าสู่ระบบของไคลเอ็นต์ภายใน

  • ServiceCallout เพื่อรับโทเค็นภายนอก
  • ExtractVariables หรือ ขั้นตอน JavaScript เพื่อ ดึงโทเค็นที่สร้างขึ้นภายนอกจากคำตอบ
  • OAuthV2/GenerateAccessToken ที่มีองค์ประกอบ <ExternalAuthorization> ตั้งค่าเป็น false และมีองค์ประกอบ <ExternalAccessToken>, <ExternalRefreshToken> หรือ <ExternalAuthorizationCode> อย่างน้อย 1 รายการ

หมายเหตุเกี่ยวกับการกำหนดค่าโฟลว์และนโยบาย

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

  • หลังจาก ServiceCallout แล้ว พร็อกซี API ต้องแยกวิเคราะห์คำตอบเพื่อดึงสถานะความถูกต้อง รวมถึง access_token ที่สร้างขึ้นภายนอกและอาจเป็น refresh_token

  • ในนโยบาย OAuthV2/GenerateAccessToken ให้ตั้งค่าองค์ประกอบ <StoreToken> เป็น true และตั้งค่าองค์ประกอบ <ExternalAuthorization> เป็น true หรือ false ตามความเหมาะสม

    เมื่อนโยบาย OAuthV2/GenerateAccessToken ทำงาน นโยบายจะอ่านตัวแปร oauth_external_authorization_status หากตั้งค่าตัวแปรและค่าเป็น "จริง" Apigee Edge จะไม่พยายามตรวจสอบข้อมูลเข้าสู่ระบบของไคลเอ็นต์ หากไม่ได้ตั้งค่าตัวแปร หรือค่าไม่ใช่ "จริง" Apigee Edge จะพยายามตรวจสอบข้อมูลเข้าสู่ระบบของไคลเอ็นต์

  • นโยบาย OAuthV2 มีองค์ประกอบ 3 รายการที่ช่วยให้คุณระบุข้อมูลภายนอกที่จะนำเข้า ได้แก่ <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 ที่มี Operation = 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 ของบุคคลที่สามได้