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 的存取權杖 (權杖 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 會要求 https://graph.microsoft.com Web API 之 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 參數會由兩個參數取代：client_assertion_type 和 client_assertion。 client_assertion_type 參數會設定為 urn:ietf:params:oauth:client-assertion-type:jwt-bearer，而 client_assertion 參數會設定為使用憑證私密金鑰簽署的 JWT 權杖。
範例
下列 HTTP POST 會使用憑證要求 https://graph.microsoft.com Web API 之 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%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 範圍時，才會提供重新整理權杖。 |
成功的回應範例
下列範例顯示 https://graph.microsoft.com Web API 存取權杖要求的成功回應。 回應包含存取權杖和重新整理權杖，並使用憑證的私密金鑰簽署。
{
"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 服務需要存取會在非互動流程中接受 SAML 判斷提示的其他 Web 服務 API。 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 流程中，範圍值一律必須是已附加 /.default 的 SAML 實體識別碼。 例如，如果 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值，則必須將值設定為資源應用程式組態中的第一個非萬用字元回應 URL。 由於預設的回應 URL 不會用來判斷Recipient值，因此您可能必須重新排序應用程式組態中的回應 URL，以確保使用第一個非萬用字元的回應 URL。 如需詳細資訊，請參閱回覆 URL。 - SubjectConfirmationData 節點：節點不能包含
InResponseTo屬性，因為它不屬於 SAML 回應的一部分。 接收 SAML 權杖的應用程式必須能夠接受 SAML 判斷提示，而不需要InResponseTo屬性。 - API 權限：您必須在中介層應用程式上新增必要的 API 權限，以允許存取 SAML 應用程式，讓其可以針對 SAML 應用程式的
/.default範圍要求權杖。 - 同意：必須授與同意，才能接收 SAML 權杖，其中包含 OAuth 流程上的使用者資料。 如需詳細資訊，請參閱 取得中介層應用程式的同意。
使用 SAML 判斷提示進行回應
| 參數 | 描述 |
|---|---|
| token_type | 指出權杖類型的值。 Microsoft Entra ID 支援的唯一類型是 持有人。 如需持有人權杖的詳細資訊，請參閱 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：Bearer
- 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 流程成功：
預設與合併的同意
中介層應用程式會將用戶端新增至其資訊清單中的已知用戶端應用程式清單 (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 通訊協定，以及另一種使用用戶端認證來執行服務對服務驗證的方式。
意見反應
即將登場：在 2024 年，我們將逐步淘汰 GitHub 問題作為內容的意見反應機制，並將它取代為新的意見反應系統。 如需詳細資訊，請參閱：https://aka.ms/ContentUserFeedback。
提交並檢視相關的意見反應