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

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

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

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

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

เรามาพูดถึงการตรวจสอบข้อมูลเข้าสู่ระบบไคลเอ็นต์กัน

สิ่งที่ต้องมีก่อนการสร้างโทเค็นคือการยืนยันไคลเอ็นต์ที่ส่งคำขอ โดยค่าเริ่มต้น นโยบาย 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 ก่อนที่จะสร้างโทเค็น เพื่อให้มีการตรวจสอบไคลเอ็นต์อย่างชัดเจนผ่านวิธีการอื่นๆ ซึ่งมักเกิดขึ้นผ่านนโยบาย ServiceAPI ที่เชื่อมต่อกับปลายทางระยะไกลในเครือข่ายของคุณ

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

หากต้องการให้นโยบาย OAuthV2/GenerateAccessToken ใน Apigee Edge ไว้ตรวจสอบข้อมูลเข้าสู่ระบบของไคลเอ็นต์กับ Edge Store ให้ตั้งค่าองค์ประกอบ <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 Admin 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 รายการ

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

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

  • หลัง Serviceสามารถแสดงโฆษณา พร็อกซี API ต้องแยกวิเคราะห์การตอบกลับเพื่อดึงสถานะความถูกต้อง รวมถึง access_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 ของบุคคลที่สาม