Architecture guidance request — GitHub identity for workforce tenant access

Question

We're running a PoC exploring how to enable users authenticated via GitHub credentials to access resources in our Microsoft Entra workforce tenant. We've made progress on the federation chain but are blocked on a specific architectural piece and would appreciate your guidance.

What we've validated so far

GitHub is not a built-in social IdP in workforce Entra tenants (only Google and Microsoft Account are). Custom OpenID Connect IdPs are only configurable in Entra External ID for customers tenants (CIAM), not workforce.

We set up an External tenant (CIAM) with a Custom OIDC IdP that bridges GitHub via Auth0. The federation chain works end-to-end at the External tenant level — the issued JWT shows correct iss, tid, idp, and sub claims pointing at our Auth0 bridge. GitHub users can sign in via the OAuth chain and land as members of the External tenant.

What we're blocked on

Bridging External tenant users to the workforce tenant for resource access is where we're stuck. We've tried:

• B2B invitation by email — Microsoft auto-routes to MSA for users with @outlook/@hotmail/@live emails; the federation chain to External tenant doesn't trigger.
• B2B invitation using the External tenant UPN (<oid>@cpccustomers.onmicrosoft.com) — Microsoft still presents a direct password prompt against the workforce tenant; doesn't route to cpccustomers.ciamlogin.com for federation.
• Cross-tenant access settings: configured workforce inbound trust for the External tenant; enabled "Allow users sync into this tenant"; "Automatically redeem invitations with the tenant" toggle. The federation chain still doesn't trigger when the user signs into workforce resources. And we ever want to configure outbound cross-tenant access in the external tenant, but seems it's not available for a external type tenant.

Microsoft documentation on cross-tenant access (Cross-tenant access in Microsoft Entra External ID overview (https://learn.microsoft.com/en-us/entra/external-id/cross-tenant-access-overview)) appears scoped to workforce-to-workforce scenarios. We can't find documented patterns for External-tenant-to-workforce-tenant bridging for resource access.

Proposed alternative — SAML federation with a custom domain

If the External-tenant-bridge isn't viable, we'd like to validate the following pattern:

• Verify a custom domain (e.g., one we own) in the workforce tenant
• Configure workforce tenant SAML/WS-Fed federation for that domain, pointing at Auth0 in SAML mode
• Auth0 internally handles GitHub OAuth and returns SAML assertions to workforce Entra
• Invite GitHub users at <handle>@<our-domain> — they redeem via Auth0 → GitHub authentication chain, becoming federated B2B guests in workforce

We understand the constraints (custom domain ownership; users would have emails on a domain we control rather than their natural GitHub-associated email) but maybe this is the most realistic supported path for "GitHub credential at sign-in time" for workforce tenant resource access.

Questions

• Is External tenant → workforce tenant bridging for resource access a supported pattern, or is it architecturally out of scope for current Entra capabilities?
• Does Cross-tenant Synchronization (CTS) work between an Entra External ID for customers tenant and a workforce tenant? Microsoft docs cover workforce-to-workforce CTS but we haven't found External-to-workforce documentation.
• Are there other patterns we should consider for "GitHub-authenticated users access workforce tenant resources" beyond the SAML + custom-domain approach above?
• Roadmap items that would change this picture? E.g., is there in-progress work to add GitHub as a built-in workforce social IdP, or to support cross-tenant federation between CIAM and workforce tenants?

Answer 1

Hello Kelly Yin

As discussed over teams:-

1. External-tenant → workforce-tenant federation • As things stand today, you can’t point a workforce tenant at an External ID (customer) tenant as a B2B IdP. Built-in cross-tenant federation and Cross-Tenant Synchronization are only supported between workforce (employee) tenants. There’s no documented or supported pattern to “tunnel” a customer tenant into a workforce tenant for resource access.
2. Cross-Tenant Synchronization (CTS) • CTS only works workforce→workforce. You won’t get customer-to-workforce sync.
3. Other patterns • Your SAML + custom-domain approach is exactly the recommended workaround:
   1. Verify a domain you own in your workforce tenant (for example, contoso.com).
   2. Configure SAML/WS-Fed federation on that domain to Auth0 (in SAML mode).
   3. Let Auth0 handle GitHub OAuth and emit SAML assertions back to Entra.
   4. Invite users as <github-handle>@contoso.com so that when they sign in, Azure AD redirects them to Auth0 → GitHub.
   5. They land in your workforce tenant as federated guests and can access resources like any other B2B user.
   • If you need to onboard at scale, you could even pair that with Azure AD’s provisioning (SCIM) connector on the workforce side so that Auth0 automatically provisions the guest accounts under your federated domain.
4. Roadmap • There’s no public announcement about adding GitHub as a first-class social IdP in workforce tenants or about customer-to-workforce federation. If you haven’t already, I’d suggest voting or filing feedback on the Microsoft 365 roadmap/user-voice for a “GitHub social IdP” request.

References

• What is Microsoft Entra External ID for customers (CIAM) overview

https://learn.microsoft.com/azure/active-directory/external-identities/customers/overview-customers-ciam

• Cross-tenant access in Microsoft Entra External ID overview

https://learn.microsoft.com/entra/external-id/cross-tenant-access-overview

• Microsoft Entra External ID deployment architectures (workforce & collaboration)

https://learn.microsoft.com/entra/architecture/external-identity-deployment-architectures#workforce-and-collaboration-oriented-architecture

• Cross-tenant synchronization overview

https://learn.microsoft.com/entra/identity/multi-tenant-organizations/cross-tenant-synchronization-overview

• Authentication and Conditional Access for B2B users

https://learn.microsoft.com/entra/external-id/authentication-conditional-access

Answer 2

External tenant → workforce tenant bridging for interactive resource access is not a supported pattern with current Microsoft Entra capabilities.

From the available documentation:

• External ID (customer/CIAM) tenants and workforce tenants are distinct, with different default configurations and feature sets. External tenants are designed for consumer and business-customer access to apps, not for acting as an upstream IdP into workforce tenants for B2B collaboration.
• Supported identity providers and authentication methods for External ID are scoped to customer-facing scenarios and CIAM user flows. Invited users in External tenants are explicitly “for administrative purposes only” and “not compatible with customer identity and access management (CIAM) user flows,” which reinforces that External tenants are not intended as a federation bridge into workforce tenants.
• Cross-tenant access and collaboration guidance in the referenced architecture content is focused on workforce and collaboration-oriented architectures (workforce ↔ business partners), not CIAM → workforce federation.

Given the context, the specific questions can be addressed as follows:

1. Is External tenant → workforce tenant bridging for resource access supported?
   No supported pattern is documented for using a Microsoft Entra External ID (customers/CIAM) tenant as an identity provider into a workforce tenant for B2B resource access. External tenants are positioned for consumer access to apps, not as a federation hub into workforce tenants.
2. Does Cross-tenant Synchronization (CTS) work between External ID for customers and a workforce tenant?
   The provided documentation on external identity deployment architectures and cross-tenant access focuses on workforce-to-workforce scenarios and business-partner collaboration. There is no documentation in the context indicating that CTS is supported from an External ID (customers) tenant into a workforce tenant. Only workforce and collaboration-oriented architectures and their considerations are described.
3. Other patterns for “GitHub-authenticated users access workforce tenant resources”
   Within the given information, the only clearly supported approaches for external identities accessing workforce resources are:
   • Standard B2B collaboration using supported identity providers for external users in workforce tenants (Microsoft Entra accounts, Microsoft accounts, Google, SAML/WS-Fed, etc.). GitHub is not listed as a supported IdP for workforce tenants.
   • Federation via SAML/WS-Fed or OIDC from an external IdP that the workforce tenant trusts, using domains and federation patterns that are supported for workforce tenants.
   The proposed SAML + custom-domain approach aligns with supported primitives:
   • Workforce tenants can use SAML/WS-Fed federation with external IdPs for specific verified domains.
   • External users can then be invited using identities on that federated domain and authenticate via the external IdP (Auth0), which in turn can handle GitHub OAuth.
   This pattern fits within the documented capabilities (SAML/WS-Fed federation and external IdPs for workforce tenants) and avoids relying on unsupported CIAM → workforce federation.
4. Roadmap items (GitHub as workforce social IdP or CIAM ↔ workforce federation)
   The context only lists current supported identity providers and features and does not mention roadmap commitments to:
   • Add GitHub as a built-in social IdP for workforce tenants, or
   • Enable cross-tenant federation between External ID (customers) tenants and workforce tenants for resource access.
   The documentation instead emphasizes:
   • The separation between workforce and external tenants and their configurations.
   • That External ID is a next-generation CIAM platform with its own feature set and supported identity providers.

Given the available information, the SAML/WS-Fed federation with a verified custom domain in the workforce tenant, fronted by Auth0 handling GitHub OAuth, is the pattern that aligns with supported capabilities for “GitHub credential at sign-in time” to access workforce resources.

---

References:

• Supported features in workforce and external tenants
• Microsoft Entra External ID deployment architectures with Microsoft Entra
• Microsoft Entra External ID frequently asked questions
• Add a Microsoft Entra ID tenant as an OpenID Connect identity provider (Preview)