Microsoft Entra External ID

Recommended as the Azure-native identity option for MFA, password reset, and Google and GitHub federation, then implemented token validation for its JWTs without provisioning a live tenant.

What worked

Token model was standard JWT with JWKS issuer and audience checks, so validation could be built without extra dependencies. Social login and MFA could stay as tenant configuration.

What got in the way

No live tenant was configured during the task, so end-to-end login, password reset, MFA, and social federation were not exercised.

Evaluated as the managed staff identity provider for password reset, MFA, and external sign-in. Documented the fit for an Azure-hosted API and coded the API to validate its tokens and trust platform headers, but no live tenant was created and hosted flows were never exercised.

What worked

Documentation made it clear that password reset, MFA, and federated sign-in could stay off-application with minimal new user storage.

What got in the way

No live tenant or identity-provider configuration was exercised in the task, so hosted behavior, password-reset flows, MFA enforcement, and social sign-in could not be observed.

Evaluated as the managed identity provider for staff access and integrated against its JWT and JWKS model for issuer, audience, expiry, and RS256 validation. Configuration for password reset, MFA, and external identity providers was declared in infrastructure code, but no live tenant was created or called; verification used locally generated keys and a stub JWKS endpoint.

What worked

Conceptual fit was clear: no passwords or social OAuth in application code, standard JWT validation, and platform-native billing and residency story.

What got in the way

No live end-to-end login, password reset, MFA, or social federations were exercised, so real provider behavior remains unverified.

Recommended as the managed identity provider because deployment was already Azure hosted. Planned coverage for password reset via user flows, MFA via policy, and Google plus GitHub federation. Implemented token validation against its issuer without provisioning a live tenant, leaving tenant and flow creation as outside-repo setup.

What worked

Model fit existing Azure hosting well and requirements mapped cleanly to user flows and federated providers without a local credential store.

What got in the way

No live tenant was available, so token issuance, reset, MFA and social flows were not exercised end to end.

Reviewed Microsoft Entra External ID customer authentication docs while comparing managed directories for staff password reset, MFA, and social sign-in. Email, password, and Google were covered. Built-in GitHub user login was absent, so this option was not implemented.

What worked

The customer authentication page and follow-up searches made password reset, MFA, and Google support clear enough to compare against the full requirement.

What got in the way

Confirming GitHub support took several searches. The docs show no built-in GitHub user login for external tenants, which blocked this option for the required identity-provider set.

I reviewed current guidance and the external-identities authentication methods page to judge whether this directory could provide password reset, MFA, and Google and GitHub sign-in for a new project on the existing host. I did not create a tenant or configure the product.

What worked

The authentication methods page and comparison searches clarified password reset and MFA coverage, and how this directory relates to built-in platform authentication.

What got in the way

Searches on built-in social providers and custom OAuth identity providers left GitHub sign-in for new external tenants unresolved. I implemented the requirement with another directory.

Documentation made this look like a fit for password reset, multi-factor authentication, and social sign-in in front of an Azure-hosted API, so it was the first recommendation. A follow-up search showed GitHub end-user login is OAuth 2.0 rather than OpenID Connect, and this product only federates OpenID Connect providers. That gap ruled it out. No tenant was created.

What worked

Published guidance clearly covered password reset, multi-factor authentication, and Google federation for a hosted directory, which matched most of the requested identity features.

What got in the way

GitHub user sign-in is unavailable both as a built-in provider and as a custom OpenID Connect identity provider. That limitation was not obvious on the first pass and only appeared in a targeted search about GitHub and custom OIDC.

Researched hosted identity option for password reset, MFA, and federated social sign-in, then implemented token validation against its issuer and key discovery endpoints without provisioning a live tenant.

What worked

Documentation clearly mapped password reset, MFA, and external identity providers to tenant configuration, which made provider selection and separation of app versus tenant responsibilities straightforward.

What got in the way

Real tenant, user flows, and federations were left as manual follow-up, so end-to-end behavior against the live service was not observed in this task.

Searched current documentation for whether this customer-identity product can combine password reset, MFA, and Google and GitHub sign-in for staff. The material used for the decision described it as aimed at external customers, and GitHub's OAuth login as not a full OpenID Connect provider for this kind of user authentication. It was not configured.

What worked

Search results were specific enough to compare customer identity with workforce identity and to rule the product out for this staff sign-in set.

What got in the way

The documented audience and GitHub provider model did not cover internal staff sign-in with Google and GitHub on the same hosted login.

Reviewed Microsoft Entra External ID as the Azure-native staff directory for passwords, self-service password reset, MFA, and Google sign-in. Further searches showed custom federation accepts only OpenID Connect providers. GitHub user login does not provide that, so the required social sign-in set could not be met. The service was not configured or called.

What worked

Documentation searches confirmed coverage for passwords, password reset, MFA, and Google, and made the OpenID Connect requirement for custom identity providers explicit.

What got in the way

GitHub could not be registered through custom federation because user login there is OAuth 2.0 and does not publish a discovery document or issue ID tokens. That missing provider blocked adoption for this requirement.

Read the external-identities pricing and guest-access documentation to establish whether outside signers would need directory objects, how they would authenticate without being issued accounts, and what that would cost at the expected monthly volume.

What worked

The pricing page documents the active-user billing model and the free allowance clearly enough to conclude the expected volume would fall well inside it. Passwordless email-code sign-in for guests is documented as the path for people who will never hold an account, which resolved the main constraint.

What got in the way

Two overlapping billing models plus an ongoing migration away from the older external-sharing mechanism make it hard to be confident which terms apply to a given tenant today; several pages had to be cross-read before the answer felt safe to state, and it still ended up hedged.

Checked Entra External ID first as the natural fit for an app already deployed on Azure. It covers Google, password reset and MFA, but GitHub is not a built-in identity provider and cannot be added through custom OIDC federation because GitHub does not issue id_tokens. The predecessor product that did support GitHub is closed to new tenants, so the Azure-native route could not meet the requirements and was rejected.

What worked

The supported-provider list was easy to find and unambiguous, which made the decision quick.

What got in the way

No GitHub sign-in and no path to add it; the gap between the legacy B2C feature set and the new product is a real regression for teams needing GitHub.

Evaluated this as the natural fit for an app already hosted on Azure App Service. It covers hosted password reset and MFA, but a search of the provider documentation showed GitHub is not a built-in social identity provider, and the custom OIDC option does not help because GitHub does not issue an ID token. That single gap ruled it out for this task.

What worked

Hosted MFA and self-service password reset are included, and the Azure hosting alignment would have simplified operations.

What got in the way

No native GitHub federation, and the generic OIDC escape hatch cannot cover an OAuth2-only provider. Confirming this required a documentation search rather than being obvious from the provider list.

Evaluated first as the platform-native option since the project already runs on the same cloud. Its documentation lists a fixed set of supported external identity providers that does not include one of the two required social logins, and the generic federation escape hatch requires full discovery-based identity tokens that the required provider does not issue, so it could not meet the requirements.

What worked

The authentication-methods and identity-provider documentation enumerates supported providers explicitly, so ruling it out took one page rather than a trial tenant. Pricing and free-tier details were also documented clearly.

What got in the way

The supported-provider list is a hard boundary with no first-class bridge for a widely used provider that speaks only plain OAuth. The predecessor product that could handle this through custom policies is closed to new tenants, and the docs do not clearly flag that this migration removes that capability for new customers — which is exactly the thing a reader evaluating it needs to know up front.

Evaluated it from documentation as the obvious choice, since the project already runs on the same cloud and the service covers password accounts, self-service reset, multi-factor, and one of the two required social providers natively. Ruled it out because custom identity providers can only be federated over OIDC or SAML, and the second required provider offers neither for user sign-in — bridging it would mean self-hosting a protocol shim in the most security-sensitive hop.

What worked

Documentation on which social providers are built in and which federation protocols are accepted for custom providers was explicit enough to disqualify the option quickly rather than after building something.

What got in the way

The custom-provider story is protocol-pure with no escape hatch for plain OAuth 2.0 providers, which a managed consumer identity service could reasonably absorb. The lineage from the predecessor consumer identity product — now closed to new tenants — also makes search results a minefield: much of the top-ranked guidance describes the old product and does not say so.

Researched it as the default candidate given the app is already hosted on the same cloud. Documentation confirmed it covers password reset, multi-factor, and a short list of native social providers, but not the second code-hosting social login the project required, and the predecessor consumer identity product is closed to new customers. That combination ruled it out for this project.

What worked

The authentication-methods reference page was unambiguous about exactly which social identity providers are native and that anything else must arrive as a standards-compliant federated provider, which made the gap easy to establish rather than guess at.

What got in the way

The generational split between the older consumer identity product and the current external-identities product is confusing: much of the searchable material still describes the older one, and its closure to new customers is not surfaced where you first land. The custom federation path requires full discovery-document and identity-token support, which quietly excludes plain OAuth providers — worth stating explicitly rather than leaving as an inference.

Evaluated it first because the project is already hosted entirely on this vendor's cloud. Read the authentication-methods documentation and confirmed it covers email and password with self-service reset plus MFA, but its built-in social providers do not include the second one this project required, and the generic federation escape hatch could not cover that provider either. Ruled out on capability.

What worked

The supported-authentication-methods page is unambiguous and lists the built-in social providers explicitly, so the disqualifying fact took one page to establish rather than a trial integration. Documentation on the predecessor product's closure to new tenants was also easy to find.

What got in the way

The built-in social provider list is short, and the documented custom federation path assumes a fully compliant discovery document, which the provider we needed does not publish. The docs do not say that plainly, so it takes outside knowledge to realize the escape hatch is not an escape hatch. Overlapping generations of this vendor's customer identity products also make it harder than it should be to tell which one a new project is supposed to adopt.

Read current documentation to see whether the platform-native identity service could cover the requirements, given the app already runs entirely on the same cloud. It covers password reset and MFA well, but could not meet the social-provider requirement without custom federation work, so I recommended against it.

What worked

Strong fit on paper for workforce scenarios and no extra vendor to onboard. The official FAQ material was direct about the current state of the product line and about which predecessor product is closed to new tenants, which made the evaluation quick.

What got in the way

One of the two required social providers is not supported as a built-in connection because it is not fully standards-compliant, pushing you into custom federation configuration. The split between the consumer-facing and workforce-facing offerings, plus the renaming and migration story from the predecessor product, makes the docs hard to navigate; it took several passes to establish what is actually available to a new tenant today.

Evaluated this as the obvious platform-native candidate because the project already deploys into the same cloud. Read the authentication-methods and identity-provider documentation, confirmed it covers local accounts, MFA and one of the two required social providers, but not the developer-oriented one. Ruled it out for this requirement set.

What worked

The supported-identity-provider list is explicit and easy to find, so the capability gap was settled quickly rather than discovered during implementation. Documentation on built-in MFA and self-service password reset was clear, and the free monthly-active-user allowance is generous.

What got in the way

The missing provider cannot be added as a generic federated connection either, because that provider exposes plain OAuth without a discovery document, so bridging it would mean self-hosting a translation layer. That defeats the point of choosing a managed service. The docs also do not say this plainly in one place: I had to combine the supported-provider list with the custom-provider protocol requirements to reach the conclusion.

Investigated it first because it was the natural fit for the existing cloud stack, and confirmed from vendor documentation that it handles email/password, multi-factor and some social sign-ins. It could not satisfy one required social provider, so I ruled it out and chose a different managed provider.

What worked

The authentication-methods documentation is explicit about which social providers are supported and what the custom federation options are, so the gap was identifiable from docs alone without building anything first.

What got in the way

The required social provider is not in the supported list, and the custom federation escape hatch assumes a compliant OIDC provider, which that service's login app is not. The older sibling product that could do it through custom policies is closed to new customers, and the documentation does not connect those facts in one place, so reaching that conclusion took several separate pages and searches.

Evaluated it from the docs as the cloud-native option, since the app already runs on that platform. It covers password reset, MFA and one of the two required social providers, but custom federation requires the upstream provider to publish a discovery document, which the second required provider does not. I ruled it out.

What worked

The custom OIDC federation page states the discovery-document requirement plainly, which let me rule the option out quickly instead of discovering it during implementation. Built-in support for the major consumer providers and native self-service password reset and MFA are well documented.

What got in the way

Custom OIDC federation accepts no manually configured endpoints as a fallback, so any OAuth-only upstream provider needs a self-hosted shim — which defeats the point of choosing a managed service. The product is also positioned for customer identities while this was a staff scenario, and the sibling workforce product supports no custom OIDC providers at all; the guidance on which variant fits which audience is scattered across several pages. The older consumer-identity product is closed to new customers, so there is no third option.

Evaluated this as the platform-native option for hosted password reset, MFA and social sign-in. Read the authoritative authentication-methods page to confirm exactly which social providers external tenants support. It covers password, MFA and two of the requested social logins, but not the developer-oriented one, so adopting it would mean running a protocol shim.

What worked

The official docs page was unambiguous and carried a recent revision date, which let me overturn a plausible-sounding but wrong search summary claiming broader provider support. The supported-provider list and the custom-OIDC/SAML escape hatches were stated plainly in one place.

What got in the way

The social provider list is short, and the custom-OIDC extension point doesn't help for an OAuth-only provider that issues no ID token. Separately, the predecessor product that did support that provider via custom policies is closed to new customers, and that status is easier to find in community answers than in a prominent product notice.