1. Abstract
Cross-Cloud Business-To-Business (CCB2B) enables seamless collaboration across Microsoft National Cloud boundaries (e.g., Azure Global, Azure Government, Azure Germany, Azure operated by 21Vianet) by allowing users whose identity belonging to one cloud to access resources in another Microsoft National Cloud. The central security challenge is protecting refresh tokens issued by the resource owning cloud from exfiltration and replay on unauthorized devices, because the resource owning cloud lacks native knowledge of the user's device. This article presents the protocol designed and implemented to cryptographically bind these tokens to the device, mitigating the various threat vectors that arise from replay and theft of refresh tokens.
2. Introduction
As multinational and public-sector organizations increasingly operate across Microsoft National Clouds (e.g., Azure Global ↔ Azure Government, Azure Global ↔ Azure 21 Vianet), the need for seamless, secure collaboration across clouds has grown. CCB2B addresses this need by enabling invitation, redemption, and access flows across Microsoft National Clouds boundaries, while preserving device-based conditional access parity and delivering consistent user experience. By tying access to the user's home identity, it eliminates the need for separate guest accounts, ensuring that access is automatically revoked when a user loses access to their home tenant. Moreover, CCB2B empowers organizations to enforce modern security controls for external users. Through cross-tenant access settings, resource tenants can require phishing-resistant multi-factor authentication (MFA) (such as FIDO2 keys or certificate-based authentication) and enforce device compliance policies for guests, just as they do for internal users. This unified policy enforcement strengthens the security posture of cross-cloud collaboration. But there lies a security challenge on how to secure the user's cross cloud resources from threats arising from theft and replay of Refresh Tokens (RTs) issued by the resource tenant.
3. Terminology
- Home tenant: The tenant where the user's identity as well as the device identity exists.
- Home cloud: The Microsoft National Cloud where the user's home tenant exists
- Resource tenant: The tenant where the resource exists. In this document's context, it also refers to the tenant where a user from another tenant and Microsoft National Cloud has been invited as a guest.
- Resource cloud: The Microsoft National Cloud where the resource tenant exists.
- Device Transport Key: An asymmetric key pair where the private key is protected by the device's TPM, and the corresponding public key is registered with Entra ID during device registration.
- Session Key (CEK): A symmetric key generated by the resource tenant. It serves as the Content Encryption Key (CEK) when the resource tenant returns a JWE payload containing tokens and refresh tokens, and it is also used by the client as a Proof-of-Possession (PoP) key during the RT redemption flows. To clarify the different roles this key plays, the notation 'session key (purpose)' will be used throughout the document to indicate its specific function in context.
3. Challenge: How to bind the RT issued by the guest /resource cloud to the device?
The enablement of cross-cloud B2B introduces a nuanced security challenge concerning the binding of refresh tokens (RTs) issued by the resource tenant. Within Microsoft's identity architecture, RTs are typically cryptographically bound to a user's device using a Proof-of-Possession (PoP) key called a session key. This binding ensures that even if an RT is exfiltrated, it cannot be replayed from unauthorized devices.
In the home tenant, the session key (PoP) is embedded within the refresh token (RT) and is returned to the client. Alongside the RT, the home tenant also returns a JSON Web Encryption (JWE) object containing the session key (CEK) which is encrypted using the device transport key. In JWE terms, the device transport key functions as the Key Encryption Key (KEK), while the session key serves as the Content Encryption Key (CEK). The client then imports the session key (CEK) from the JWE and uses it as a PoP key for subsequent token requests with the refresh token (RT).
However, in cross-cloud scenarios, the resource tenant lacks intrinsic awareness of the user's device and its associated transport key, as the device is registered exclusively within the home cloud. This separation is intentional and necessary to uphold the strict isolation guarantees across Microsoft National cloud environments which are designed to meet compliance and sovereignty requirements. Consequently, the resource tenant cannot access device-specific cryptographic material from the home cloud without violating these guarantees.
This architectural constraint results in a critical limitation: the resource tenant, which is responsible for issuing and protecting RTs, does not possess the cryptographic means to bind those tokens to the user's device. Without an additional mechanism, RTs minted by the resource tenant remain unbound, exposing them to potential replay attacks if stolen.
4. Solution: Leverage Federation between Microsoft Entra ID in different Microsoft National Clouds
To address the challenge of securely binding refresh tokens (RTs) in cross-cloud scenarios, Microsoft's identity architecture leverages the existing federation between Entra ID tenants across sovereign Microsoft National clouds. Specifically, the resource tenant relies on claims issued by the home tenant within an access token (AT) to establish trust in the user's device identity, without requiring direct integration with the home cloud's device registry. This preserves the compliance-driven isolation guarantees across Microsoft's National Cloud boundaries.
During the authorization flow, the home tenant authenticates both the user, the device, and includes the device transport public key as a claim in the AT issued to the resource tenant. The resource tenant then uses this key to encrypt the session key (PoP) it generates for RT binding. This approach ensures that the RT remains cryptographically bound to the device, while maintaining cloud separation and sovereignty.
4.1 End-to-End Protocol Flow (Narrative)
Authorization Initiation: The Web Account Manager (WAM) initiates an authorization request to a resource tenant located in a cloud distinct from the user's home tenant.
Authentication Redirection: The resource tenant redirects the client to the user's home tenant for authentication.
User and Device Context Propagation: Windows OS appends the Primary Refresh Token (PRT) and Device credential as headers to the redirected request targeting the user's home tenant.
Authentication and AuthCode Issuance: The user's home tenant authenticates the user and the device using the provided SSO headers and issues an authorization code (AuthCode_H) containing the device transport key as a claim.
Client Receives AuthCode_H: The client receives the AuthCode_H from the home tenant with an indication to redirect the AuthCode_H to the resource tenant.
Federation Endpoint Invocation: The client invokes the resource tenant's federated OAuth 2.0 endpoint with the AuthCode_H that it received from the user's home tenant.
AuthCode_H Redemption: The resource tenant sends a service-to-service token request to the home tenant's token endpoint to redeem the AuthCode_H.
Access Token Issuance: Upon verifying the AuthCode_H, the user's home tenant includes the device transport key as a claim in the resulting AT and returns it to the resource tenant.
Client Receives AuthCode_R: The resource tenant validates the AT and extracts the device transport key claim. It then issues its own authorization code (AuthCode_R) to the client, embedding the device transport key.
Device Bound Refresh Token Acquisition: When the client redeems AuthCode_R, the resource tenant generates a session key (PoP), binds it to the RT, and encrypts it using the device transport key to produce a JWE. Both the RT and the JWE (session_key_jwe) containing the encrypted session key (CEK) are returned to the client.
Secure Storage: WAM imports the session key from the JWE and securely stores it alongside the RT using DPAPI.
PoP Enforcement: On subsequent RT redemption requests to the resource tenant, WAM signs the request using the stored session key (PoP). The resource tenant validates the PoP signature and issues a new AT and RT enclosed in a JWE, with the session key used as the content encryption key (CEK) in the returned JWE.
5. Security Analysis
5.1 Threat Vector: Refresh Token (RT) Theft and Cross-Device Replay
Binding RTs to a device-specific session key (PoP) significantly mitigates the risk of token theft. In the absence of the session key (PoP) - securely held by the legitimate device - an adversary is unable to generate valid PoP signatures required for RT redemption. This cryptographic constraint renders stolen RTs ineffective when replayed from unauthorized devices.
5.2 Threat Vector: Man-in-the-Middle (MitM) Attack - Initial Token Request Interception
In scenarios where an attacker successfully monitors HTTPS traffic (such as via SSL stripping techniques) during the initial token request to the resource tenant, the confidentiality of the session key remains intact. The session key is encapsulated within a JWE and encrypted using the device's transport key (Key Encryption Key, KEK). Since the attacker lacks access to the device transport private key, decryption of the session key is infeasible, preserving the integrity of the token binding mechanism.
5.3 Threat Vector: Man-in-the-Middle (MitM) Attack - Replay of RT Redemption Request
An attacker intercepting the RT redemption request may attempt to replay it. However, Entra ID responds with a JSON Web Encryption (JWE) payload containing an access token (AT) and a new refresh token (RT), where the session key (extracted from the original RT used in the request) serves as the Content Encryption Key. Without possession of the session key (CEK), the attacker cannot decrypt the payload, thereby preventing extraction or misuse of the tokens.
6. Future Enhancements
The current security model assumes that, at the time of device registration with Entra ID (and the creation of the device transport key), the device is free from compromise. If this assumption fails (meaning an attacker is already present on the device at the time of device registration) the existing token binding strategy would be insufficient. In such cases, more advanced and resilient token binding mechanisms will be required.
7. Conclusion
In summary, securing access to cross-cloud resources against replay and theft of refresh tokens is a critical challenge in modern identity architectures, especially as organizations increasingly collaborate across sovereign Microsoft National Clouds. The protocol described herein leverages device-bound cryptographic keys and federated trust between Entra ID tenants to ensure that refresh tokens are not only issued securely but are also rendered useless if exfiltrated or replayed from unauthorized devices. By binding tokens to device bound session keys the solution robustly mitigates the principal threat vectors, including token theft, man-in-the-middle interception, and replay attacks.
However, the security model's effectiveness is contingent upon the integrity of the device at the time of registration. As attackers evolve, future enhancements must address scenarios where devices may be compromised prior to device transport key creation, necessitating more resilient token binding mechanisms. Ultimately, the approach outlined in this article not only strengthens the security posture of cross-cloud collaboration but also sets a foundation for future advancements in protecting distributed resources from sophisticated token-based attacks.
8. References
- M. Jones and J. Hildebrand, JSON Web Encryption (JWE), RFC 7516, Internet Engineering Task Force (IETF), May 2015. [Online]. Available: https://datatracker.ietf.org/doc/html/rfc7516
- J. Bradley, H. Tschofenig, and N. Sakimura, "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)," RFC 7800, Internet Engineering Task Force (IETF), Apr. 2016. [Online]. Available: https://datatracker.ietf.org/doc/html/rfc7800
- D. Hardt, "The OAuth 2.0 Authorization Framework," RFC 6749, IETF, Oct. 2012. [Online]. Available: https://www.rfc-editor.org/rfc/rfc6749
- N. Sakimura, J. Bradley, M. Jones, B. de Medeiros, and C. Mortimore, "OpenID Connect Core 1.0," OpenID Foundation, Nov. 2014. [Online]. Available: https://openid.net/specs/openid-connect-core-1_0.html
- R. Goldstein, Collaborate securely across organizational boundaries and Microsoft clouds, Microsoft Entra Blog, Microsoft Tech Community, Feb. 23, 2023. [Online]. Available: https://techcommunity.microsoft.com/blog/microsoft-entra-blog/collaborate-securely-across-organizational-boundaries-and-microsoft-clouds/3094109
About the writer
Srinivasa Ravi Teja Peri is a Principal Software Engineer at Microsoft, where he leads strategic engineering initiatives within the Identity and Authentication Development Platform team. With over 12 years of experience in software engineering, he brings deep expertise in architecting and developing secure, scalable identity platforms and authentication protocols that support millions of users globally, along with a strong background in operating system design and development. In addition to his identity and security work, Ravi has experience in developing enterprise-grade storage solutions. His passion lies in tackling complex engineering challenges and delivering high-impact, secure software solutions. He holds a Master's degree in Computer Science from North Carolina State University.
