Microsoft 身分識別平台 和 OAuth 2.0 代理者流程
代理者 (OBO) 流程描述了 Web API 使用與自己不同的身分識別的 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 流程，我們會透過下圖的協助加以說明。
- 用戶端應用程式向使用權杖 A 向 API A 提出要求 (其中包含 API A 的
aud宣告)。 - API A 向 Microsoft 身分識別平台權杖發行端點進行驗證，並要求存取 API B 的權杖。
- Microsoft 身分識別平台權杖發行端點會驗證 API A 的認證以及權杖 A，並向 API A 發行 API B (權杖 B) 的存取權杖。
- 權杖 B 是由 API A 在向 API B 提出要求的授權標頭中所設定的。
- 來自受保護資源的資料會由 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 範圍的https://graph.microsoft.com存取令牌和重新整理令牌user.read。 要求會使用用戶端密碼進行簽署，並由機密客戶端進行。
//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 權杖)。 若要瞭解如何註冊憑證和判斷提示的格式，請參閱 憑證認證。 |
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\":[\"9ab03e19-ed42-4168-b6b7-7001fb3e933a\"]}}}"
}
使用存取令牌來存取受保護的資源
現在中介層服務可以使用先前取得的令牌，藉由在標頭中 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 服務作為目標資源的代理者流程。
這是 OAuth 2.0 代理者流程的非標準延伸模組，可讓 OAuth2 型應用程式存取取用 SAML 令牌的 Web 服務 API 端點。
提示
當您從前端 Web 應用程式呼叫 SAML 保護的 Web 服務時，只需呼叫 API，並使用使用者現有的工作階段起始一般的互動式驗證流程。 當服務對服務呼叫需要 SAML 令牌以提供使用者內容時，您只需要使用 OBO 流程。
使用 OBO 要求搭配共用秘密取得 SAML 令牌
SAML 判斷提示的服務對服務要求包含下列參數：
| 參數 | 類型 | 描述 |
|---|---|---|
| grant_type | 必要 | 令牌要求的型別。 對於使用 JWT 的要求，值必須是 urn:ietf:params:oauth:grant-type:jwt-bearer。 |
| assertion | 必要 | 要求中使用的存取令牌值。 |
| client_id | 必要 | 使用 Microsoft Entra ID 註冊期間指派給呼叫服務的應用程式識別碼。 若要在 Microsoft Entra 系統管理中心尋找應用程式識別碼，請流覽至 [身分識別>應用程式> 應用程式註冊 然後選取應用程式名稱。 |
| client_secret | 必要 | 在 Microsoft Entra ID 中為呼叫服務註冊的密鑰。 註冊時應該注意此值。 每個 RFC 6749 也支援基本身份驗證模式，而不是在授權標頭中提供認證。 |
| 範圍 (scope) | 必要 | 令牌要求的範圍以空格分隔的清單。 如需詳細資訊，請參閱 範圍。 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 應用程式而言可能很重要。 |
| requested_token_use | 必要 | 指定應該如何處理要求。 在代理者流程中，值必須是 on_behalf_of。 |
| requested_token_type | 必要 | 指定要求的令牌類型。 此值可以是 urn:ietf:params:oauth:token-type:saml2 或 urn:ietf:params:oauth:token-type:saml1 ，視所存取資源的需求而定。 |
回應包含以 UTF8 和 Base 64url 編碼的 SAML 令牌。
- 來自 OBO 呼叫之 SAML 判斷提示的 SubjectConfirmationData：如果目標應用程式需要 中的
SubjectConfirmationData值，則必須在資源應用程式組態中將此值設定為第一個Recipient非wildcard 回復 URL。 由於預設的回復 URL 不會用來判斷Recipient值，因此您可能必須重新排序應用程式組態中的回復 URL，以確保使用第一個非通配符回復 URL。 如需詳細資訊，請參閱 回復 URL。 - SubjectConfirmationData 節點：節點不能包含
InResponseTo屬性，因為它不是 SAML 回應的一部分。 接收 SAML 令牌的應用程式必須能夠接受沒有InResponseTo屬性的 SAML 判斷提示。 - API 許可權：您必須 在中介層應用程式上新增必要的 API 許可權 ，以允許存取 SAML 應用程式，以便它可以要求 SAML 應用程式範圍的令牌
/.default。 - 同意：必須授與同意，才能接收 SAML 令牌，其中包含 OAuth 流程上的用戶數據。 如需詳細資訊，請參閱 取得中介層應用程式的同意。
使用 SAML 判斷提示的回應
| 參數 | 描述 |
|---|---|
| token_type | 指出權杖類型的值。 Microsoft Entra ID 支援的唯一類型是 Bearer。 如需持有人令牌的詳細資訊，請參閱 OAuth 2.0 授權架構：持有人令牌使用方式（RFC 6750）。 |
| 範圍 (scope) | 在權杖中授與的存取範圍。 |
| expires_in | 存取令牌的有效時間長度（以秒為單位）。 |
| expires_on | 存取令牌到期的時間。 日期會以 1970-01-01T0：0：0Z UTC 到到期時間之前的秒數表示。 這個值用來判斷快取令牌的存留期。 |
| resource | 接收服務的應用程式識別碼 URI（受保護的資源）。 |
| access_token | 傳回 SAML 判斷提示的參數。 |
| refresh_token | 重新整理令牌。 呼叫端服務可以使用此令牌，在目前的 SAML 判斷提示到期后要求另一個存取令牌。 |
- token_type：持有人
- expires_in：3296
- ext_expires_in： 0
- expires_on：1529627844
- resource:
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 設定的所有必要許可權，這些許可權會識別用戶端為已知的用戶端應用程式。
預先授權的應用程式
資源可以指出指定的應用程式一律具有接收特定範圍的許可權。 這很適合讓前端用戶端與後端資源之間的連線更加順暢。 資源可以在 其指令清單中宣告多個預先授權的應用程式 （preAuthorizedApplications）。 任何這類應用程式都可以在 OBO 流程中要求這些許可權，並在使用者提供同意的情況下接收這些許可權。
管理員同意
租用戶系統管理員可以藉由為仲介層應用程式提供管理員同意，保證應用程式有權呼叫其必要的 API。 若要這樣做，系統管理員可以在其租使用者中找到仲介層應用程式、開啟必要的許可權頁面，然後選擇為應用程式授與許可權。 若要深入瞭解管理員同意，請參閱 同意和許可權檔。
使用單一應用程式
在某些情況下，您只能有一對仲介層和前端用戶端。 在此案例中，您可以更輕鬆地將此單一應用程式設為單一應用程式，而完全否定中介層應用程式的需求。 若要在前端和 Web API 之間進行驗證，您可以使用 Cookie、id_token或應用程式本身要求的存取令牌。 然後，向後端資源要求來自這個單一應用程式的同意。
另請參閱
深入瞭解 OAuth 2.0 通訊協定，以及使用用戶端認證執行服務對服務驗證的另一種方式。