Microsoft身分識別平臺和 OAuth 2.0 On-Behalf-Of 流程

代理者 （OBO） 流程描述 Web API 使用自己的身分識別來呼叫另一個 Web API 的案例。 在 OAuth 中稱為委派，其意圖是透過要求鏈結來傳遞使用者的身分識別和權限。

若要讓仲介層服務向下游服務提出已驗證的要求，它必須保護來自Microsoft身分識別平臺的存取令牌。 它只會使用委派 的範圍 ，而不是應用程式 角色。 角色 仍會附加至主體（使用者），且永遠不會附加至代表使用者作的應用程式。 這會防止使用者取得他們不應該存取的資源許可權。

本文說明如何直接針對應用程式中的通訊協議進行程序設計。 可能的話，建議您改用支援的 Microsoft 驗證連結庫 （MSAL） 來取得令牌，並呼叫受保護的 Web API。 另請參閱 使用 MSAL 的範例應用程式 範例。

用戶端限制

如果服務主體要求僅限應用程式令牌，並將它傳送至 API，則該 API 會交換不代表原始服務主體的令牌。 這是因為 OBO 流程僅適用於用戶主體。 相反地，它必須使用 用戶端認證流程 來取得僅限應用程式令牌。 在單頁應用程式（SPA）的情況下，它們應該將存取令牌傳遞至仲介層機密用戶端，以改為執行 OBO 流程。

如果用戶端使用隱含流程來取得id_token，而且在回復 URL 中也有通配符，則id_token無法用於 OBO 流程。 通配符是以字元結尾的 * URL。 例如，如果 https://myapp.com/* 是回復 URL，則無法使用id_token，因為它不夠具體，無法識別用戶端。 這可防止發出令牌。 不過，透過隱含授與流程取得的存取令牌會由機密客戶端兌換，即使起始用戶端已註冊通配符回復 URL 也一樣。 這是因為機密用戶端可以識別取得存取令牌的用戶端。 接著，機密用戶端可以使用存取令牌來取得下游 API 的新存取令牌。

此外，具有自定義簽署密鑰的應用程式不能當做 OBO 流程中的仲介層 API 使用。 這包括針對單一登錄設定的企業應用程式。 如果仲介層 API 使用自定義簽署金鑰，下游 API 將不會驗證傳遞給它的存取令牌簽章。 這會導致錯誤，因為以用戶端控制之密鑰簽署的令牌無法安全地接受。

通訊協議圖表

假設使用者已使用 OAuth 2.0 授權碼授與流程 或其他登入流程來驗證應用程式。 此時，應用程式具有 API A （Token A） 的存取令牌，其中包含使用者的宣告，並同意存取仲介層 Web API（API A）。 現在，API A 必須向下游 Web API (API B) 提出已驗證的要求。

接下來的步驟會構成 OBO 流程，我們會透過下圖的協助加以說明。

1. 用戶端應用程式向具有令牌 A 的 API A 提出要求（具有 aud API A 的宣告）。
2. API A 會向Microsoft身分識別平臺令牌發行端點進行驗證，並要求令牌來存取 API B。
3. Microsoft身分識別平臺令牌發行端點會驗證 API A 的認證以及令牌 A，並將 API B （令牌 B） 的存取令牌發行至 API A。
4. 令牌 B 是由 API A 在對 API B 的要求授權標頭中設定的。
5. 來自受保護資源的數據會由 API B 傳回至 API A，然後傳回用戶端。

在此案例中，中介層服務沒有用戶互動，可讓使用者同意存取下游 API。 因此，在驗證期間，授與下游 API 存取權的選項會顯示為同意步驟的一部分。 若要瞭解如何在應用程式中實作此作業，請參閱 取得中介層應用程式的同意。

中介層存取令牌要求

若要要求存取令牌，請使用下列參數，對租使用者特定的Microsoft身分識別平臺令牌端點發出 HTTP POST。

https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token

警告

請勿 將發行至仲介層的存取令牌傳送到令牌的目標物件以外的任何位置。 發行至中介層的存取令牌 僅供 該仲介層用來與預定物件端點通訊。

將存取權杖從中介層資源轉接至客戶端的安全性風險（而不是用戶端自行取得存取權杖）包括：

• 增加透過遭入侵 SSL/TLS 通道進行令牌攔截的風險。
• 無法滿足需要宣告步驟的令牌系結和條件式存取案例（例如 MFA、登入頻率）。
• 與系統管理員設定的裝置型原則不相容（例如 MDM、位置型原則）。

根據用戶端應用程式選擇受到共享密碼或憑證保護，有兩種情況。

第一個案例：具有共享密鑰的存取令牌請求

使用共享密碼時，服務對服務存取令牌要求包含下列參數：

參數	類型	說明
grant_type	為必填項目	憑證請求的類型。 對於使用 JWT 的要求，此值必須是 urn:ietf:params:oauth:grant-type:jwt-bearer。
client_id	為必填項目	Microsoft Entra 系統管理中心 - 指派給應用程式的應用程式註冊頁面的應用程式 （用戶端） 識別碼。
client_secret	為必填項目	您在 Microsoft Entra 系統管理中心 - 應用程式註冊頁面為應用程式產生的客戶端密碼。 每個 RFC 6749 也支援基本身份驗證模式，而不是在授權標頭中提供認證。
assertion	為必填項目	傳送至仲介層 API 的存取令牌。 此令牌必須具有發出此 OBO 要求之應用程式的物件 （aud） 宣告（欄位 client-id 所表示的應用程式）。 應用程式無法兌換不同應用程式的令牌（例如，如果用戶端傳送適用於 Microsoft Graph 的令牌，API 就無法使用 OBO 兌換令牌。它應該改為拒絕令牌。
scope	為必填項目	以空格分隔的令牌請求範圍列表。 如需詳細資訊，請參閱 範圍。
requested_token_use	為必填項目	指定應該如何處理要求。 在 OBO 流程中，值必須設定為 on_behalf_of。

範例

下列 HTTP POST 會要求具有 Web API 範圍的user.read存取令牌和重新整理令牌https://graph.microsoft.com。 要求會使用用戶端密碼進行簽署，並由機密客戶端進行。

//line breaks for legibility only
    
POST /oauth2/v2.0/token HTTP/1.1
Host: login.microsoftonline.com/<tenant>
Content-Type: application/x-www-form-urlencoded
    
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&client_secret=sampleCredentia1s
&assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCJ9.eyJhdWQiOiIyO{a lot of characters here}
&scope=https://graph.microsoft.com/user.read+offline_access
&requested_token_use=on_behalf_of

第二個案例：使用憑證的存取令牌請求

具有憑證的服務對服務存取令牌要求除了上述範例中的參數之外，還包含下列參數：

參數	類型	說明
grant_type	為必填項目	令牌要求的型別。 對於使用 JWT 的要求，此值必須是 urn:ietf:params:oauth:grant-type:jwt-bearer。
client_id	為必填項目	Microsoft Entra 系統管理中心 - 指派給應用程式的應用程式註冊頁面的應用程式 （用戶端） 識別碼。
client_assertion_type	為必填項目	值必須是 urn:ietf:params:oauth:client-assertion-type:jwt-bearer。
client_assertion	為必填項目	聲明（JSON Web Token），您必須使用您註冊為應用程式認證的憑證來建立和簽署。 若要瞭解如何註冊憑證和判斷提示的格式，請參閱 憑證認證。
assertion	為必填項目	傳送至仲介層 API 的存取令牌。 此令牌必須具有發出此 OBO 要求之應用程式的物件 （aud） 宣告（欄位 client-id 所表示的應用程式）。 應用程式無法為不同的應用程式兌換令牌（例如，如果用戶端傳送適用於 MS Graph 的令牌，API 就無法使用 OBO 兌換令牌。它應該改為拒絕令牌。
requested_token_use	為必填項目	指定應該如何處理要求。 在 OBO 流程中，值必須設定為 on_behalf_of。
scope	為必填項目	令牌要求的範圍以空格分隔的清單。 如需詳細資訊，請參閱 範圍。

請注意，參數幾乎與共享密碼的要求相同，不同之處在於 client_secret 參數會由兩個參數取代：a client_assertion_type 和 client_assertion。 參數 client_assertion_type 會設定為 urn:ietf:params:oauth:client-assertion-type:jwt-bearer ，且 client_assertion 參數會設定為使用憑證私鑰簽署的 JWT 令牌。

範例

下列 HTTP POST 會要求具有 user.read 憑證之 https://graph.microsoft.com Web API 範圍的存取令牌。 要求會使用用戶端密碼進行簽署，並由機密客戶端進行。

// line breaks for legibility only
    
POST /oauth2/v2.0/token HTTP/1.1
Host: login.microsoftonline.com/<tenant>
Content-Type: application/x-www-form-urlencoded
    
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&client_id=11112222-bbbb-3333-cccc-4444dddd5555
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6Imd4OHRHeXN5amNScUtqRlBuZDdSRnd2d1pJMCJ9.eyJ{a lot of characters here}
&assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCIsImtpZCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCJ9.eyJhdWQiO{a lot of characters here}
&requested_token_use=on_behalf_of
&scope=https://graph.microsoft.com/user.read+offline_access

仲介層存取令牌回應

成功回應為包含下列參數的 JSON OAuth 2.0 回應。

參數	說明
token_type	表示令牌類型值。 Microsoft身分識別平台支援的唯一類型是 Bearer。 如需持有人令牌的詳細資訊，請參閱 OAuth 2.0 授權架構：持有人令牌使用方式（RFC 6750）。
scope	在令牌中授予的存取範圍。
expires_in	存取權杖的有效時間 (以秒為單位)。
access_token	要求的存取憑證。 呼叫服務可以使用此權杖來驗證接收服務。
refresh_token	所要求存取權杖的刷新權杖。 目前的存取權杖到期後，呼叫服務可以使用此權杖來要求另一個存取權杖。 只有在要求範圍時 offline_access ，才會提供重新整理令牌。

成功的回應範例

下列範例顯示 Web API 存取令牌 https://graph.microsoft.com 要求的成功回應。 回應包含存取令牌和重新整理令牌，並使用憑證的私鑰簽署。

{
    "token_type": "Bearer",
    "scope": "https://graph.microsoft.com/user.read",
    "expires_in": 3269,
    "ext_expires_in": 0,
    "access_token": "eyJ0eXAiOiJKV1QiLCJub25jZSI6IkFRQUJBQUFBQUFCbmZpRy1tQTZOVGFlN0NkV1c3UWZkQ0NDYy0tY0hGa18wZE50MVEtc2loVzRMd2RwQVZISGpnTVdQZ0tQeVJIaGlDbUN2NkdyMEpmYmRfY1RmMUFxU21TcFJkVXVydVJqX3Nqd0JoN211eHlBQSIsImFsZyI6IlJTMjU2IiwieDV0IjoiejAzOXpkc0Z1aXpwQmZCVksxVG4yNVFIWU8wIiwia2lkIjoiejAzOXpkc0Z1aXpwQmZCVksxVG4yNVFIWU8wIn0.eyJhdWQiOiJodHRwczovL2dyYXBoLm1pY3Jvc29mdC5jb20iLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83MmY5ODhiZi04NmYxLTQxYWYtOTFhYi0yZDdjZDAxMWRiNDcvIiwiaWF0IjoxNDkzOTMwMzA1LCJuYmYiOjE0OTM5MzAzMDUsImV4cCI6MTQ5MzkzMzg3NSwiYWNyIjoiMCIsImFpbyI6IkFTUUEyLzhEQUFBQU9KYnFFWlRNTnEyZFcxYXpKN1RZMDlYeDdOT29EMkJEUlRWMXJ3b2ZRc1k9IiwiYW1yIjpbInB3ZCJdLCJhcHBfZGlzcGxheW5hbWUiOiJUb2RvRG90bmV0T2JvIiwiYXBwaWQiOiIyODQ2ZjcxYi1hN2E0LTQ5ODctYmFiMy03NjAwMzViMmYzODkiLCJhcHBpZGFjciI6IjEiLCJmYW1pbHlfbmFtZSI6IkNhbnVtYWxsYSIsImdpdmVuX25hbWUiOiJOYXZ5YSIsImlwYWRkciI6IjE2Ny4yMjAuMC4xOTkiLCJuYW1lIjoiTmF2eWEgQ2FudW1hbGxhIiwib2lkIjoiZDVlOTc5YzctM2QyZC00MmFmLThmMzAtNzI3ZGQ0YzJkMzgzIiwib25wcmVtX3NpZCI6IlMtMS01LTIxLTIxMjc1MjExODQtMTYwNDAxMjkyMC0xODg3OTI3NTI3LTI2MTE4NDg0IiwicGxhdGYiOiIxNCIsInB1aWQiOiIxMDAzM0ZGRkEwNkQxN0M5Iiwic2NwIjoiVXNlci5SZWFkIiwic3ViIjoibWtMMHBiLXlpMXQ1ckRGd2JTZ1JvTWxrZE52b3UzSjNWNm84UFE3alVCRSIsInRpZCI6IjcyZjk4OGJmLTg2ZjEtNDFhZi05MWFiLTJkN2NkMDExZGI0NyIsInVuaXF1ZV9uYW1lIjoibmFjYW51bWFAbWljcm9zb2Z0LmNvbSIsInVwbiI6Im5hY2FudW1hQG1pY3Jvc29mdC5jb20iLCJ1dGkiOiJWR1ItdmtEZlBFQ2M1dWFDaENRSkFBIiwidmVyIjoiMS4wIn0.cubh1L2VtruiiwF8ut1m9uNBmnUJeYx4x0G30F7CqSpzHj1Sv5DCgNZXyUz3pEiz77G8IfOF0_U5A_02k-xzwdYvtJUYGH3bFISzdqymiEGmdfCIRKl9KMeoo2llGv0ScCniIhr2U1yxTIkIpp092xcdaDt-2_2q_ql1Ha_HtjvTV1f9XR3t7_Id9bR5BqwVX5zPO7JMYDVhUZRx08eqZcC-F3wi0xd_5ND_mavMuxe2wrpF-EZviO3yg0QVRr59tE3AoWl8lSGpVc97vvRCnp4WVRk26jJhYXFPsdk4yWqOKZqzr3IFGyD08WizD_vPSrXcCPbZP3XWaoTUKZSNJg",
    "refresh_token": "OAQABAAAAAABnfiG-mA6NTae7CdWW7QfdAALzDWjw6qSn4GUDfxWzJDZ6lk9qRw4An{a lot of characters here}"
}

此存取令牌是適用於 Microsoft Graph 的 v1.0 格式令牌。 這是因為令牌格式是以所存取 的資源 為基礎，且與用來要求它的端點無關。 Microsoft Graph 設定為接受 v1.0 令牌，因此當用戶端要求 Microsoft Graph 的令牌時，Microsoft身分識別平臺會產生 v1.0 存取令牌。 其他應用程式可能表示他們想要 v2.0 格式的令牌、v1.0 格式的令牌，甚至是專屬或加密的令牌格式。 v1.0 和 v2.0 端點都可以發出任一格式的令牌。 如此一來，無論用戶端要求令牌的方式或位置為何，資源一律都能取得正確的令牌格式。

警告

請勿在程式代碼中嘗試驗證或讀取您未擁有之任何 API 的令牌，包括此範例中的令牌。 Microsoft 服務的令牌可以使用無法作為 JWT 驗證的特殊格式，並且可能為消費者（Microsoft 帳戶）用戶加密。 雖然讀取令牌是實用的偵錯和學習工具，但請勿在程式碼中對其建立依賴性，也不要假設非您自身 API 所控制範圍的令牌具體細節。

錯誤回應範例

如果下游 API 有條件式存取原則（例如 多重要素驗證），則當嘗試取得下游 API 的存取令牌時，令牌端點會傳回錯誤回應。 仲介層服務應該將此錯誤呈現給用戶端應用程式，讓用戶端應用程式可以提供使用者互動來滿足條件式存取原則。

若要 將此錯誤呈現回 用戶端，中介層服務會以 HTTP 401 未經授權回復，並具有包含錯誤和宣告挑戰的 WWW-Authenticate HTTP 標頭。 客戶端必須剖析此標頭，並從令牌簽發者取得新的令牌，方法是在有宣告時提出挑戰。 用戶端不應該重試使用快取存取令牌來存取中介層服務。

{
    "error":"interaction_required",
    "error_description":"AADSTS50079: Due to a configuration change made by your administrator, or because you moved to a new location, you must enroll in multifactor authentication to access 'aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb'.\r\nTrace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333\r\nCorrelation ID: aaaa0000-bb11-2222-33cc-444444dddddd\r\nTimestamp: 2017-05-01 22:43:20Z",
    "error_codes":[50079],
    "timestamp":"2017-05-01 22:43:20Z",
    "trace_id":"0000aaaa-11bb-cccc-dd22-eeeeee333333",
    "correlation_id":"aaaa0000-bb11-2222-33cc-444444dddddd",
    "claims":"{\"access_token\":{\"polids\":{\"essential\":true,\"values\":[\"00aa00aa-bb11-cc22-dd33-44ee44ee44ee\"]}}}"
}

使用存取令牌來存取受保護的資源

現在中介層服務可以使用先前取得的令牌，藉由在標頭中 Authorization 設定令牌，向下游Web API提出已驗證的要求。

範例

    GET /v1.0/me HTTP/1.1
    Host: graph.microsoft.com
    Authorization: Bearer eyJ0eXAiO ... 0X2tnSQLEANnSPHY0gKcgw

使用 OAuth2.0 OBO 流程取得的 SAML 判斷提示

某些 OAuth 型 Web 服務需要存取其他 Web 服務 API，以接受非互動式流程中的 SAML 判斷提示。 Microsoft Entra ID 可以提供 SAML 判斷提示，以回應使用 SAML 型 Web 服務作為目標資源的 On-Behalf-Of 流程。

這是 OAuth 2.0 On-Behalf-Of 流程的非標準延伸模組，可讓 OAuth2 型應用程式存取取用 SAML 令牌的 Web 服務 API 端點。

小提示

當您從前端 Web 應用程式呼叫 SAML 保護的 Web 服務時，只需呼叫 API，並使用使用者現有的工作階段起始一般的互動式驗證流程。 當服務對服務呼叫需要 SAML 令牌以提供使用者內容時，您只需要使用 OBO 流程。

使用 OBO 要求搭配共用秘密取得 SAML 令牌

SAML 判斷提示的服務對服務要求包含下列參數：

參數	類型	說明
grant_type (授權類型)	必須的	令牌要求的型別。 對於使用 JWT 的要求，值必須是 urn:ietf:params:oauth:grant-type:jwt-bearer。
斷言	必須的	要求中使用的存取令牌值。
client_id (客戶識別碼)	必須的	在註冊期間指派給呼叫服務的應用程式標識碼，Microsoft Entra ID。 若要在 Microsoft Entra 系統管理中心尋找應用程式識別碼，請流覽至 Entra ID>應用程式註冊，然後選取應用程式名稱。
用戶端密鑰	必須的	Microsoft Entra ID 中為呼叫服務註冊的密鑰。 註冊時應該注意此值。 每個 RFC 6749 也支援基本身份驗證模式，而不是在授權標頭中提供認證。
範圍	必須的	令牌要求的範圍以空格分隔的清單。 如需詳細資訊，請參閱 範圍。 SAML 本身沒有範圍的概念，但用來識別您想要接收令牌的目標 SAML 應用程式。 在此 OBO 流程中，範圍值一律是附加的 SAML 實體標識碼 /.default 。 例如，如果 SAML 應用程式的實體識別碼是 https://testapp.contoso.com，則要求的範圍應該是 https://testapp.contoso.com/.default。 如果實體標識碼不是以 URI 配置開頭，例如 https:，Microsoft Entra 前面會加上 spn:實體識別碼。 在這裡情況下，您必須要求範圍 spn:<EntityID>/.default，例如 spn:testapp/.default ，實體識別碼為 testapp。 您在這裡要求的範圍值會決定 SAML 令牌中產生的 Audience 專案，這對接收令牌的 SAML 應用程式而言可能很重要。
請求的代幣使用	必須的	指定應該如何處理要求。 在 On-Behalf-Of 流程中，值必須是 on_behalf_of。
請求的憑證類型	必須的	指定要求的令牌類型。 此值可以是 urn:ietf:params:oauth:token-type:saml2 或 urn:ietf:params:oauth:token-type:saml1 ，視所存取資源的需求而定。

回應包含以 UTF8 和 Base 64url 編碼的 SAML 令牌。

• 來自 OBO 呼叫之 SAML 判斷提示的 SubjectConfirmationData：如果目標應用程式需要 中的Recipient值，則必須在資源應用程式組態中將此值設定為第一個SubjectConfirmationData非wildcard 回復 URL。 由於預設的回復 URL 不會用來判斷 Recipient 值，因此您可能必須重新排序應用程式組態中的回復 URL，以確保使用第一個非通配符回復 URL。 如需詳細資訊，請參閱 回復 URL。
• SubjectConfirmationData 節點：節點不能包含 InResponseTo 屬性，因為它不是 SAML 回應的一部分。 接收 SAML 令牌的應用程式必須能夠接受沒有 InResponseTo 屬性的 SAML 判斷提示。
• API 許可權：您必須在中介層應用程式 上新增必要的 API 許可權 ，以允許存取 SAML 應用程式，以便它可以要求 SAML 應用程式範圍的令牌 /.default 。
• 同意：必須授與同意，才能接收 SAML 令牌，其中包含 OAuth 流程上的用戶數據。 如需詳細資訊，請參閱 取得中介層應用程式的同意。

使用 SAML 判斷提示的回應

參數	說明
令牌類型	表示令牌類型值。 Microsoft Entra ID 支援的唯一類型是 Bearer。 如需持有人令牌的詳細資訊，請參閱 OAuth 2.0 授權架構：持有人令牌使用方式（RFC 6750）。
範圍	在令牌中授予的存取範圍。
有效期限	存取令牌的有效時間長度（以秒為單位）。
到期日	存取令牌到期的時間。 日期會以 1970-01-01T0：0：0Z UTC 到到期時間之前的秒數表示。 這個值用來判斷快取令牌的存留期。
資源	接收服務的應用程式識別碼 URI（受保護的資源）。
access_token（存取憑證）	傳回 SAML 判斷提示的參數。
刷新令牌	重新整理令牌。 呼叫端服務可以使用此令牌，在目前的 SAML 判斷提示到期后要求另一個存取令牌。

• token_type：持有人
• expires_in：3296
• ext_expires_in： 0
• expires_on：1529627844
• 資源: https://api.contoso.com
• access_token： <SAML 判斷提示>
• issued_token_type：urn：ietf：params：oauth：token-type：saml2
• refresh_token： <重新整理令牌>

取得中介層應用程式的同意

OBO 流程的目標是確保已獲得適當的同意，讓用戶端應用程式可以呼叫仲介層應用程式，而仲介層應用程式有權呼叫後端資源。 根據應用程式的架構或使用方式，您應該考慮下列事項，以確保 OBO 流程成功：

.default 和合併同意

仲介層應用程式會將用戶端新增至其指令清單中的 已知用戶端應用程式清單 （knownClientApplications）。 如果客戶端觸發同意提示，同意流程會同時用於本身和仲介層應用程式。 在Microsoft身分識別平臺上，這會使用 .default 範圍來完成。 範圍 .default 是一個特殊範圍，可用來要求同意以存取應用程式擁有許可權的所有範圍。 當應用程式需要存取多個資源時，這非常有用，但用戶應該只提示同意一次。

使用已知的用戶端應用程式和 .default觸發同意畫面時，同意畫面會顯示用戶端對仲介層 API 的許可權，同時要求仲介層 API 所需的任何許可權。 使用者為這兩個應用程式提供同意，然後 OBO 流程運作。

要求中識別的資源服務 （API） 應該是用戶端應用程式要求存取令牌的 API，因為使用者登入。 例如， scope=openid https://middle-tier-api.example.com/.default （若要要求中介層 API 的存取令牌），或 scope=openid offline_access .default （未識別資源時，預設為 Microsoft Graph）。

無論在授權要求中識別哪一個 API，同意提示都會與針對用戶端應用程式設定的所有必要許可權結合。 也會包含針對用戶端必要許可權清單中所列之每個仲介層 API 設定的所有必要許可權，這些許可權會識別用戶端為已知的用戶端應用程式。

這很重要

雖然在涉及scope=openid https://resource/.default的合併同意流程中使用是有效的，但您不得與相同要求中的其他委派範圍合併.default，例如 User.Read、Mail.Read、 profile或 User.ReadWrite.All 。 這會導致 AADSTS70011 錯誤，因為 .default 代表預先同意的靜態許可權，而其他人在運行時間需要動態使用者同意。

offline_access 有時會接受 .default 以啟用重新整理令牌，但不應與任何其他委派範圍結合。 如有疑問，請分割令牌要求以避免範圍類型衝突。

預先授權的應用程式

資源可以指出指定的應用程式一律具有接收特定範圍的許可權。 這很適合讓前端用戶端與後端資源之間的連線更加順暢。 資源可以在其指令清單中 宣告多個預先授權的應用程式 （preAuthorizedApplications）。 任何這類應用程式都可以在 OBO 流程中要求這些許可權，並在使用者提供同意的情況下接收這些許可權。

管理員同意

租用戶系統管理員可以藉由為仲介層應用程式提供管理員同意，保證應用程式有權呼叫其必要的 API。 若要這樣做，系統管理員可以在其租使用者中找到仲介層應用程式、開啟必要的許可權頁面，然後選擇為應用程式授與許可權。 若要深入瞭解管理員同意，請參閱 同意和許可權檔。

使用單一應用程式

在某些情況下，您只能有一對仲介層和前端用戶端。 在此案例中，您可以更輕鬆地將此單一應用程式設為單一應用程式，而完全否定中介層應用程式的需求。 若要在前端和 Web API 之間進行驗證，您可以使用 Cookie、id_token或應用程式本身要求的存取令牌。 然後，向後端資源要求來自這個單一應用程式的同意。

另請參閱

深入瞭解 OAuth 2.0 通訊協定，以及使用用戶端認證執行服務對服務驗證的另一種方式。

• Microsoft身分識別平臺中的 OAuth 2.0 用戶端認證授與
• Microsoft身分識別平臺中的 OAuth 2.0 程式代碼流程
• /.default使用範圍