You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A BroCI refresh tokens is a brokered token exchange pattern where an existing refresh token is used with extra broker parameters to request tokens as another trusted first-party app.
214
+
215
+
These refresh tokens must be minted in that broker context (a regular refresh token usually cannot be used as a BroCI refresh token).
216
+
217
+
### Goal and purpose
218
+
219
+
The goal of BroCI is to reuse a valid user session from a broker-capable app chain and request tokens for another trusted app/resource pair without running a new full interactive flow each time.
220
+
221
+
From an offensive perspective, this matters because:
222
+
223
+
- It can unlock pre-consented first-party app paths that are not accessible with standard refresh exchanges.
224
+
- It can return access tokens for high-value APIs (for example, Microsoft Graph) under app identities with broad delegated permissions.
What changes in a NAA/BroCI refresh token is not the visible token format, but the **issuance context** and broker-related metadata that Microsoft validates during brokered refresh operations.
228
+
229
+
NAA/BroCI token exchanges are **not** the same as a regular OAuth refresh exchange.
230
+
231
+
- A regular refresh token (for example obtained via device code flow) is usually valid for standard `grant_type=refresh_token` operations.
232
+
- A BroCI request includes additional broker context (`brk_client_id`, broker `redirect_uri`, and `origin`).
233
+
- Microsoft validates whether the presented refresh token was minted in a matching brokered context.
234
+
- Therefore, many "normal" refresh tokens fail in BroCI requests with errors such as `AADSTS900054` ("Specified Broker Client ID does not match ID in provided grant").
235
+
- You generally cannot "convert" a normal refresh token into a BroCI-valid one in code.
236
+
- You need a refresh token already issued by a compatible brokered flow.
If any part of that broker chain does not match, the exchange fails.
245
+
246
+
### Where to find a BroCI-valid refresh token
247
+
248
+
In authorized testing/lab scenarios, one practical way is browser portal traffic collection:
249
+
250
+
1. Sign in to `https://entra.microsoft.com` (or Azure portal).
251
+
2. Open DevTools -> Network.
252
+
3. Filter for:
253
+
-`oauth2/v2.0/token`
254
+
-`management.core.windows.net`
255
+
4. Identify the brokered token response and copy `refresh_token`.
256
+
5. Use that refresh token with matching BroCI parameters (`brk_client_id`, `redirect_uri`, `origin`) when requesting tokens for target apps (for example ADIbizaUX / Microsoft_Azure_PIMCommon scenarios).
257
+
258
+
### Common errors
259
+
260
+
-`AADSTS900054`: The refresh token context does not match the supplied broker tuple (`brk_client_id` / `redirect_uri` / `origin`) or the token is not from a brokered portal flow.
261
+
-`AADSTS7000218`: The selected client flow expects a confidential credential (`client_secret`/assertion), often seen when trying device code with a non-public client.
From an attackers perspective it's very interesting to know where is it possible to find access and refresh tokens when for example the PC of a victim is compromised:
@@ -233,8 +561,7 @@ From an attackers perspective it's very interesting to know where is it possible
0 commit comments