Identity, Authentication, and Access Management Questions

Direct answer

The pattern for this is OAuth 2.0 Token Exchange (RFC 8693): instead of creating a local user account for each external partner, the partner authenticates against their own identity system and presents that assertion to your authorization server's token-exchange endpoint. Your authorization server validates it, checks it against a pre-registered, scoped entitlement for that specific partner, and mints a new, narrowly-scoped, short-lived token constrained to exactly the subset of your APIs the partnership actually covers, rather than ever handing the partner a token indistinguishable from an internal user's or a durable standing credential.

Structured elaboration

Trust establishment. Before any exchange happens, your authorization server needs a pre-registered, out-of-band-verified relationship with the partner's identity system: register the partner as a known subject-token issuer, record their signing keys or a JSON Web Key Set (JWKS) endpoint you fetch and cache, and record which specific scopes and audiences this particular partner is contractually allowed to request. The trust relationship itself has to be scoped to match the actual partnership agreement; treating "any validly signed token from this partner" as automatically trusted for everything skips the one check that keeps a partner-side mistake from becoming your own over-grant.

Assertion validation. When the partner presents their subject token, the token being exchanged in RFC 8693's terminology, validate it as rigorously as any bearer credential: signature against the registered key, issuer matching the registered partner, expiration and not-before claims honored. Because this assertion comes from another organization's identity system, validation has to assume that system could itself be compromised or misconfigured, so the asserted identity and scope must be cross-checked against your own registration of what that partner is actually entitled to, not accepted just because the signature is technically valid.

Scoping and audience. The exchange is allowed to mint a token with a narrower audience and scope than what the partner's subject token originally asserted, and that narrowing is the entire point of the pattern. The exchanged token's audience claim should name the specific API this partner integration covers, and its scope should be the intersection of what the partner requested, what their registered trust entitlement allows, and what was actually approved for this integration, never simply whatever the partner's request happened to ask for.

Token issuance and exchange flows. Mechanically, per RFC 8693: the partner's system calls your token endpoint with grant_type=urn:ietf:params:oauth:grant-type:token-exchange, presenting its subject token along with the scope and audience it is requesting against your API. Your authorization server validates the subject token, checks the request against the registered entitlement, and if both pass, issues a new access token representing this specific partner integration acting within this specific scope, which the partner's backend then uses to call your actual API.

Replay protection. A captured subject token or a captured exchange request should not be indefinitely reusable. Give the subject token a short validity window and a unique identifier your server can track, so a second exchange attempt using an already-consumed identifier shortly after the first is a signal worth flagging, though not necessarily blocking outright on a single occurrence, since legitimate retries after a network blip do happen; escalating on repetition is more realistic than either ignoring the signal or hard-blocking the first occurrence. Encrypting the transport for the whole exchange call is the more common real defense, since it prevents the interception in the first place, and because the resulting exchanged token is itself short-lived, even a successful replay produces a bounded-lifetime credential rather than a durable one.

Rate-limiting. Apply limits at two separate granularities: on the token-exchange endpoint itself, per partner, so a compromised partner credential minting an unusual burst of new tokens is caught even before any of those tokens are used; and separately on the downstream API calls the exchanged tokens are then used for. A spike in exchange calls specifically, even when each individual exchange looks valid on its own, is an unusual shape for legitimate integration traffic and deserves its own alert, independent of whatever the downstream API usage looks like.

Auditing for partner activity. Every token-exchange event is itself a security-relevant event and should be logged with enough detail to reconstruct which partner, using which subject-token issuer and subject identity, requested which scope and audience, and whether it was granted or denied and why. Tag the downstream API calls the exchanged token is later used for with the same correlation identifier, so an auditor or incident responder can trace a specific API call all the way back to the specific exchange event and the specific partner-side identity that originated it, rather than only knowing "some validly-scoped token called this API."

sequenceDiagram
  participant Agent as Northwind agent
  participant NW as Northwind IdP
  participant AS as Acme authorization server
  participant API as Acme shipment API

  Agent->>NW: Authenticate locally
  NW-->>Agent: Signed subject token (Northwind's own JWT)
  Agent->>AS: POST /token, grant_type=token-exchange, subject_token, requested scope+audience
  AS->>AS: Validate subject token signature against registered Northwind JWKS
  AS->>AS: Check requested scope/audience against Northwind's registered entitlement
  AS-->>Agent: New exchanged access token (narrow scope, short-lived, tagged with exchange_event_id)
  Agent->>API: Call shipment-status API with exchanged token
  API->>API: Log call tagged with exchange_event_id
  API-->>Agent: Shipment status

Worked example

Acme has a partnership with Northwind Logistics, whose customer-service agents need to call Acme's shipment-status API on behalf of Northwind's own customers, without Acme ever creating local accounts for Northwind's staff.

Trust establishment: Acme registers Northwind's identity provider as a known subject-token issuer, records Northwind's JWKS endpoint, and records that Northwind's integration is entitled to request at most the shipments:read scope for the api.acme.com/shipments audience, regardless of what Northwind's own tokens happen to assert elsewhere.

A Northwind agent authenticates locally against Northwind's own identity provider, which issues a signed subject token. Northwind's backend calls Acme's token endpoint with grant_type=token-exchange, the subject token, and a requested scope and audience matching exactly what was registered. Acme validates the subject token's signature against Northwind's registered JWKS, confirms the issuer and expiry, checks the requested scope and audience against Northwind's registered entitlement (an exact match, so it is approved), and mints a new, opaque, five-minute access token scoped to shipments:read on api.acme.com/shipments, internally tagged with partner=northwind and a correlation identifier exchange_event_id=evt_48213.

Northwind's backend calls Acme's shipment-status API with that token; Acme's resource server logs the call tagged with evt_48213. Months later, if a specific shipment's status was queried unexpectedly, Acme can trace that exact API call back to the exact exchange event, and from there back to the specific Northwind-side subject-token identity that originated it.

For rate-limiting, Acme caps Northwind's token-exchange calls at a rate sized to Northwind's expected concurrent-agent count, tracked separately from a broader downstream-API rate limit sized to expected shipment-query volume. A sudden spike in exchange calls specifically, even if every individual exchange still passes validation, pages Acme's security team, since that shape of traffic does not match how a legitimate integration behaves regardless of the downstream API's own volume.

Trade-offs and pitfalls

• Granting the exchanged token the same scope the partner's own subject token asserts, instead of intersecting it with your registered entitlement, turns a mistake on the partner's side into your own over-grant. The registered-entitlement check exists specifically to stop a partner's identity-provider misconfiguration from becoming your authorization failure.
• Treating trust establishment as a one-time decision made at onboarding, with no periodic re-review, misses that partnerships and their scope change over time. A registered entitlement that was correct at signing may no longer match the actual, current agreement a year later.
• Rate-limiting only the downstream API calls and never the exchange endpoint itself leaves a blind spot exactly where a compromised partner credential minting excess tokens would show up first. The exchange endpoint is the earlier and cheaper place to catch that pattern.
• Logging only that an exchange succeeded, with no correlation identifier linking it to the downstream calls it produced, makes the exact audit trail this design exists to provide unusable during an actual incident. The shared identifier is what turns two separate logs into one traceable chain.
• Calibrating replay handling to either extreme is a mistake in both directions: silently ignoring a repeated subject-token presentation treats a real signal as noise, while hard-blocking on the very first duplicate breaks legitimate retries after an ordinary network blip. Flagging, correlating, and escalating on repetition is deliberately less simple than either extreme, but it is the version that does not trade a working system for a checkbox.

Direct answer

Sequence the onboarding so each piece unblocks the next: get federated authentication (SAML or OpenID Connect) working first since everything else depends on a trustworthy identity assertion, then automate provisioning (SCIM, System for Cross-domain Identity Management) for account lifecycle, then map the customer's directory groups to product roles, then wire up reporting, with error handling and a rollback plan threaded through every stage rather than bolted on at the end.

Structured elaboration

Authentication (SAML or OIDC). Let the customer's identity provider (IdP) drive the choice: Security Assertion Markup Language (SAML) 2.0 is XML-assertion based and still the default for many established enterprise IdPs, while OpenID Connect (OIDC), built on OAuth 2.0 and JSON Web Token (JWT)-based, tends to be simpler to integrate and maintain going forward, especially for anything touching mobile or API clients. Support both as first-class options rather than forcing one, since the customer's existing IdP configuration is usually a fixed constraint, not a negotiable one. Onboarding here means exchanging metadata (a SAML metadata XML document, or an OIDC discovery document), configuring the entity ID and assertion consumer service URL (SAML) or redirect URIs and client ID (OIDC), and validating that the required claims (email, name, group memberships) actually arrive signed and correctly formed before moving on.

Provisioning (SCIM). Expose a SCIM 2.0 endpoint (per RFC 7644) implementing the Users and Groups resource types, which the customer's IdP calls as a SCIM client to push create, update, and deactivate events. Match incoming resources on the IdP's own stable external identifier, never on email or username, since either can be reassigned or changed and using them as the join key silently orphans or duplicates accounts. Deactivation and deletion are different events: deactivating should immediately suspend access while keeping the account and its audit history intact; a hard delete should only happen after a defined retention window, never as the immediate response to an offboarding signal.

Consent flows. In a business-to-business context, consent is normally given once by the customer's IT administrator on behalf of the whole organization, not negotiated per employee, since individual employees don't opt out of their employer's chosen provisioning. Document exactly which attributes will be received via SCIM and let the admin review that scope explicitly during onboarding; this is distinct from any individual sign-in consent prompt a user might separately see on first login.

Role mappings. Map the customer's IdP-asserted groups or claims to the product's internal roles via an explicit, per-customer configuration table, never a hardcoded assumption that a group named "Finance-Admins" means the same thing at every customer. Default any unmapped or newly-seen group to a safe, minimum-privilege role rather than silently granting either nothing (breaks the user's day) or the broadest role available (an access-control failure). Support updating a user's effective role when their group membership changes, either via a SCIM-pushed update or a just-in-time reassignment at next login as a supplement to the SCIM push.

Reporting integration. Give the customer visibility into who has access and what role, typically through both a scheduled comma-separated-values (CSV) export for manual review and a documented application programming interface for automated ingestion into the customer's own security-reporting tooling. At minimum, include current access, role, last login, and last provisioning change, since this is exactly what enterprise buyers routinely audit for compliance.

Error handling. A failed SCIM push (a malformed payload, a missing required attribute) has to surface as a correctly-formed SCIM error response the customer's IdP admin console can actually display, not disappear silently, since a silent failure means an employee believes they have access that was never actually granted. A failed SAML or OIDC assertion validation should fail closed (deny the login) with a message that distinguishes "your identity provider configuration is wrong" from "our service is unavailable," since those require completely different next steps from the customer. Large group synchronizations should use SCIM's own bulk operations and pagination rather than a single all-or-nothing request, so a failure partway through a large directory sync doesn't require restarting from zero.

Milestones, dependencies, and pitfalls. A realistic sequence: metadata exchange and an authentication test in a sandbox tenant; SCIM endpoint validation, ideally against the IdP's own SCIM compliance test suite where one exists; the role-mapping table signed off by the customer's admin; a pilot with a small cohort of real users; full directory synchronization and reporting cutover; decommissioning of any legacy access path. The critical-path dependency is almost always the customer's own IT admin availability, not engineering effort, and the role-mapping sign-off blocks the pilot from starting. The most common pitfall is assuming a one-to-one attribute-name match will hold across every customer, which breaks the moment a second customer uses different group naming; a close second is skipping the pilot cohort and running a full-directory sync on day one, which multiplies any mapping mistake across the whole customer organization at once instead of catching it on twenty users first.

flowchart LR
  IdP["Customer IdP"] -->|SAML or OIDC| Auth["Authentication"]
  IdP -->|SCIM push| Prov["Provisioning service"]
  Prov --> DB["App user/role store"]
  Auth --> App["Product"]
  DB --> App
  App -->|CSV + API| Report["Customer reporting"]

Worked example

Onboarding "Acme Corp," 500 employees, via their existing Okta tenant: exchange Okta's SAML metadata and configure the assertion consumer service URL; validate that Okta's assertions carry email, displayName, and groups. Stand up the SCIM endpoint and confirm Okta's SCIM provisioning app can create, update, and deactivate a test user correctly, matching on Okta's externalId. Build the role-mapping table for Acme's actual groups, for example Acme-Finance maps to Billing Admin and Acme-IT maps to Org Admin, reviewed and approved by Acme's IT admin. Pilot with a 20-person cohort from one department for a week, watching for mapping mistakes or login failures, before pushing the full 500-person directory sync. Reporting is wired up in parallel once authentication is stable, giving Acme's security team a weekly CSV plus an API endpoint for their own audit tooling.

Trade-offs and pitfalls

Relying on just-in-time provisioning at login without SCIM is simpler to build but leaves stale accounts behind after offboarding, since it only ever creates or updates access, never proactively removes it; SCIM push alone is stronger but depends entirely on the customer's IdP connector actually firing every event correctly, which argues for a periodic reconciliation job to catch drift from a connector that silently stopped working. The admin-consent model trades individual per-user consent granularity for enterprise practicality, which is the right trade for this context but requires clear, explicit data-processing disclosure to the admin to hold up under a compliance review. Finally, resist the temptation to skip the pilot cohort under launch-date pressure: a full-directory sync on day one turns any single role-mapping mistake into an organization-wide incident instead of a twenty-user one.

Direct answer

For most organizations, the right default is active-active: every region runs a full, locally-writable copy of the identity provider (IdP, the service that authenticates users and issues tokens) and directory service, with each identity's canonical record "homed" in one region to avoid write conflicts, and global DNS routing sending each client to its nearest healthy region. Active-passive (one primary region takes all writes, others are cold or read-only standbys) is only the better choice when the directory cannot tolerate any risk of a stale or conflicting write, such as a single break-glass emergency-access store, and a slower, human-verified failover is acceptable. The two hard constraints in this question, sub-5-second local authentication and surviving a full region loss, both point toward active-active plus stateless session validation, because a passive standby cannot serve local reads while it is cold and its promotion time directly becomes your outage window.

Structured elaboration

The topology below is the shape the rest of this answer argues for: three regions, each a full read/write replica, reached through geo/latency-based DNS, with a thin cross-region layer carrying only home-region writes and a replicated revocation list (explained in the sections that follow).

flowchart TB
  Client[Client]
  DNS[Geo/latency-based DNS]
  Client --> DNS
  DNS --> R1
  DNS --> R2
  DNS --> R3
  subgraph R1[us-east region]
    IdP1[IdP + directory replica]
  end
  subgraph R2[eu-west region]
    IdP2[IdP + directory replica]
  end
  subgraph R3[ap-southeast region]
    IdP3[IdP + directory replica]
  end
  IdP1 <-.->|home-region writes + minimized cross-region replication| IdP2
  IdP2 <-.->|home-region writes + minimized cross-region replication| IdP3
  IdP1 <-.->|home-region writes + minimized cross-region replication| IdP3
  RevList[(Replicated revocation list)]
  IdP1 --- RevList
  IdP2 --- RevList
  IdP3 --- RevList

Active-active vs. active-passive. Active-active means two or more regions each accept live authentication traffic and directory writes simultaneously. To avoid the classic multi-master problem (two regions independently updating the same user record and disagreeing), the practical pattern is "multi-master infrastructure, single-writer-per-record": each identity has a home region that owns writes to that specific record (password changes, attribute updates), while every region can serve reads and validate tokens for any identity. This gets you local low-latency authentication everywhere without needing a general conflict-resolution algorithm for the common case. Active-passive instead designates one region as the sole writer; other regions replicate asynchronously and only start accepting writes after a manual or automated promotion. Its main advantage is a simpler consistency story (there is only ever one writer, so there is no reconciliation logic to get wrong); its cost is that failover has a real recovery time (the time to detect the primary is down and promote a replica, often called RTO, recovery time objective), during which no new writes anywhere in the world are possible, and any user whose local replica lagged the primary may briefly authenticate against stale data.

Consistency trade-offs. This is a direct instance of the CAP trade-off (a system split across a network Partition must choose between Consistency and Availability for the affected data): when the link between regions is down, active-active must decide whether to keep serving local authentication with a possibly-stale replica (available, eventually consistent) or to refuse requests until the replica is confirmed current (consistent, less available). For identity systems specifically, the right answer is not the same for every write:

• Authentication reads (does this password/hash match, what groups is this user in) are the hot path and should be served locally with bounded staleness, typically single-digit seconds. A local read that is a few seconds stale is a rounding error against a 5-second latency budget and is what makes the budget achievable at all.
• Security-critical revocations (disable an account, kill a session, revoke a privilege) are the one class of write that should propagate synchronously to at least a quorum of regions, or be enforced through a separately-replicated, low-latency revocation/negative cache, precisely because an eventually-consistent disable command creates a window where a compromised account still authenticates successfully somewhere in the world.

Session state handling. There are two designs. A stateful session store (a session ID that maps to server-side state) must itself be replicated multi-region, which re-imports the entire consistency problem one layer up and adds a network hop to every request. A stateless session (a signed token, containing identity claims and an expiry, that any region can verify locally using a shared or per-region-replicated signing key) avoids that hop entirely: any region can validate any token issued anywhere, including one issued moments before the client's home region went down. The remaining gap is revocation: a stateless token is valid until it expires even if the underlying account was just disabled. The fix is to pair stateless tokens with a small, fast-replicating revocation list (a negative cache keyed by token ID or user ID) so the common case (99%+ of requests) is a local, stateless verification, and only the rare revoked case needs the cross-region signal to have arrived.

DNS/routing strategies. Route clients to the nearest healthy region using latency-based or geo-proximity DNS routing (or an anycast IP announced identically from every region, which lets the network layer itself route to the nearest point of presence without relying on DNS caching behavior at all). Health-checked failover records remove a region from rotation automatically once it stops passing checks. The design tension is DNS time-to-live (TTL, how long resolvers are allowed to cache an answer before re-querying): a long TTL (minutes to hours) means fewer DNS queries and better client-side caching, but a dead region stays in rotation for that whole window after it fails; a short TTL (30 to 60 seconds) speeds up failover at the cost of more DNS traffic and less caching upstream, and even then, some resolvers and corporate networks ignore TTLs and cache longer, so DNS failover alone is not a hard guarantee, only a fast default path.

Data residency constraints. Some jurisdictions (the EU under GDPR, the General Data Protection Regulation, and various national data-localization laws) require that a specific person's personal data, or its authoritative copy, physically stay within that jurisdiction. This directly shapes which regions can be "home" for which identities: an EU user's canonical record must be homed in an EU region, and you cannot casually replicate the full record to every region "for availability" without violating residency. The resolution is to replicate only what cross-region authentication actually needs (a minimized identity assertion: subject ID, a few claims, a public key or hash sufficient to validate the user elsewhere) globally, while keeping the full attribute set durably stored only in the home region(s). This turns the architecture from "one global directory" into "federated regional directories plus a deliberately thin, minimized cross-region layer," which is a real cost (some data literally cannot follow the user to whichever region is fastest) but is not optional where the law applies.

Worked example

Take three regions: us-east, eu-west, ap-southeast, each running a full IdP and directory replica, active-active, with per-identity home regions (an EU-domiciled user is homed in eu-west for residency). Authentication is a local directory lookup plus a signature check, both served from the nearest region, so the within-region path (tens of milliseconds for a lookup and a cryptographic signature check) is comfortably inside the 5-second budget with wide margin even before accounting for network transit.

Now size the failover path with the parameters you would actually configure, and derive the numbers rather than assert them:

• Health checks run every 10 seconds, and a region is marked unhealthy after 2 consecutive failed checks.
• DNS record TTL is set to 30 seconds.

Detection time is bounded by (checks needed - 1) x interval + one more check to fail = 1 x 10s + 10s = 20 seconds worst case for the check itself to observe the failure twice, plus up to one more health-check interval before the monitoring system reacts, giving a detection window of roughly 20 to 30 seconds. Once the unhealthy region is pulled from the DNS answer, a resolver that cached the old answer at the worst possible moment (just before the outage) holds it for up to the full 30-second TTL before re-querying. Adding detection and propagation conservatively (worst case, not typical case) gives roughly 20 to 60 seconds before all new login attempts are routed only to healthy regions. That is your realistic recovery time for new authentications, an explicit function of the two numbers you chose (check interval, TTL), not a measured result, and it is the number to defend or tighten in a design review, not "sub-5-second," because 5 seconds is the local-latency budget for a healthy region, not the cross-region failover budget.

Sessions that were active against the now-dead region are unaffected during that whole window, because the stateless-token design means us-east or ap-southeast can validate a token the dead region issued without ever calling back to it; only brand-new logins are impacted, and only until DNS reroutes them.

Trade-offs and pitfalls

• Naive multi-master is a trap. If every region can write every attribute of every record without a home-region rule, you get silent conflict resolution (commonly last-writer-wins by timestamp), and a clock skew or a delayed replication event can un-revoke a privilege that was correctly revoked moments earlier. Single-writer-per-record is what makes active-active safe, not incidental.
• DNS TTL is a lower bound, not a guarantee. Client OS resolvers, corporate DNS forwarders, and some ISPs cache longer than the TTL you set. Treat DNS-based failover as the fast common path and pair it with client-side retry-on-failure logic (try the configured endpoint, fall back to a documented alternate) for the tail.
• Data residency can bite you at the log layer, not just the directory. Authentication logs and audit trails frequently contain the same personal data subject to residency rules as the directory record itself; a design that carefully homes directory data correctly but ships all authentication logs to one global logging region can reintroduce the same violation one layer removed.
• Active-passive is not simply "worse." It is the right, deliberate choice when correctness must dominate availability, such as a small, rarely-used break-glass identity store where a brief outage during a true regional disaster is acceptable but a split-brain (two regions both believing they are the authoritative break-glass store) is not. The pitfall is defaulting to active-passive for the whole IdP out of caution and then failing the 5-second local-latency requirement for ordinary users during any single-region slowdown, not just a full outage.

Direct answer

A B2B SaaS product's multi-factor authentication (MFA) enrollment and recovery flow has to work for two structurally different user populations at once, users who sign in through their employer's federated single sign-on (SSO, one login session trusted across many applications) and users who hold a local account directly with the product, and it has to treat losing your only authenticator as an expected event, not an edge case, by requiring at least two registered authenticators before self-service recovery is even offered. The design principle that separates a secure recovery flow from a phishable one is that every recovery path must re-establish identity to roughly the same strength as the enrollment it is replacing; a recovery path that is easier to pass than enrollment is simply a second, weaker authentication method in disguise.

Structured elaboration

Enrollment UX. At first successful login (whether through the federated SSO path or a local account), the user is prompted to enroll at least one authenticator and, importantly, is not allowed to finish onboarding with only one, since a single-authenticator user has no self-service recovery path available to them by construction. The UX should recommend two different authenticator types (for example, a platform passkey plus a hardware key, or an authenticator app plus a passkey), not two copies of the same type, since two TOTP apps on the same phone both disappear together if that phone is lost.

Device attestation. During enrollment of a hardware-backed authenticator (WebAuthn/FIDO2, an open passwordless and multi-factor authentication standard), the registration ceremony can request attestation, cryptographic evidence from the device or platform about what kind of authenticator it is. Attestation lets a security-conscious tenant enforce a policy like "only accept hardware security keys from an approved vendor list for administrative accounts" rather than accepting any WebAuthn-capable device indiscriminately, at the cost of extra enrollment friction and a maintained allowlist.

Registering multiple authenticators per user. Each user's account holds a list of registered authenticators, not a single credential, and any registered authenticator can complete a login independently. This is the structural prerequisite for self-service recovery: losing one authenticator only removes one item from that list, and the user can still complete the removal-and-add flow using any of the others.

Verification steps. Adding a new authenticator, removing an existing one, or initiating a recovery flow are all themselves sensitive operations and should require a fresh, successful MFA challenge with an existing authenticator immediately beforehand, not merely a valid active session. A stolen active session should not be sufficient on its own to add an attacker's own authenticator to the account.

Self-service recovery (lost device). If the user still holds at least one working authenticator, recovery is simple: authenticate with the remaining one, then remove the lost authenticator and enroll a replacement, exactly the "verification steps" flow above applied to the recovery scenario rather than a separate mechanism.

Admin-assisted recovery. If the user has lost every registered authenticator, self-service is not possible by design (there is nothing left to authenticate with), and the flow must fall back to an administrator or help-desk process that re-establishes identity through an out-of-band channel, a manager confirmation, a pre-registered recovery contact, or an identity-proofing step, before an administrator can reset the account's authenticator list. This path is inherently weaker than self-service (it ultimately depends on a human judgment call), so it should be logged and reviewed with extra scrutiny, and for privileged accounts specifically, may require a second administrator's sign-off rather than one person's discretion alone.

Risk-based re-enrollment triggers. Certain events should force re-verification of enrolled authenticators even without a lost-device report: a login from a new device combined with a new geography, an administrator manually flagging an account after a suspected compromise, or a long period of dormancy followed by sudden activity. The response does not have to be "wipe all authenticators," a lighter-weight step-up challenge on the existing ones is often sufficient, reserving full re-enrollment for cases with a corroborated compromise signal.

Audit logging for critical events. Every enrollment, removal, and recovery action (self-service or admin-assisted) is logged with who performed it, which authenticator was added or removed, what verification step preceded it, and, for admin-assisted recovery, which administrator approved it and what identity-proofing evidence was recorded. This is the same category of event a broader identity audit-logging design would flag as high-priority (a role or credential change), and it deserves the same tamper-resistant handling.

Worked example

stateDiagram-v2
    [*] --> Unenrolled
    Unenrolled --> Enrolling: user starts enrollment
    Enrolling --> Enrolled: authenticator registered and attested
    Enrolled --> Enrolled: register additional authenticator
    Enrolled --> RecoveryRequested: lost device
    RecoveryRequested --> SelfServiceVerify: alternate factor available
    SelfServiceVerify --> Enrolled: verified, new authenticator bound
    RecoveryRequested --> AdminAssisted: no alternate factor
    AdminAssisted --> Enrolled: identity proofed, admin re-enrolls
    Enrolled --> ReEnrollment: risk-based trigger
    ReEnrollment --> Enrolled: re-verified

A new employee at a customer tenant signs in through the tenant's federated SSO and enrolls a platform passkey on their laptop plus a hardware security key kept in a drawer as a backup, both attested during registration. Three months later, the laptop is lost. The employee still holds the hardware key, so self-service recovery applies: they authenticate with the hardware key, remove the lost passkey from their account, and enroll a new passkey on their replacement laptop; this whole sequence is logged as a single correlated event (remove-authenticator, verify, add-authenticator, all tied to one recovery session ID). Six months after that, the same employee loses the hardware key on a trip and, separately, their new laptop is stolen the same week, leaving zero working authenticators. Self-service is not available (there is nothing left to authenticate with), so the flow routes to admin-assisted recovery: their manager confirms the request over a separate channel, the help desk verifies the employee's identity against the pre-registered recovery contact, and only then does an administrator reset the account's authenticator list, an action logged with the administrator's identity, the manager confirmation, and a fresh enrollment forced at next login. If, in the same week, the account also shows a login attempt from a country the employee has never used before, that combination (recent admin-assisted reset plus an unfamiliar-geography login) is exactly the kind of risk-based trigger that should force a step-up re-verification on the newly-enrolled authenticator before the account is treated as fully recovered, rather than trusting the admin reset alone.

Trade-offs and pitfalls

The central trade-off is recovery-path strength versus support burden: a strict admin-assisted recovery process (multiple confirmations, identity proofing, a second approver for privileged accounts) is harder for an attacker to social-engineer but slower and more expensive for the help desk to run at scale, while a lightweight process (a single support agent resetting authenticators on request) is fast but is exactly the path real-world attackers have repeatedly targeted through help-desk social engineering. The mitigation is not to weaken the process for convenience but to make self-service recovery robust enough (via the two-authenticator-minimum enrollment rule) that admin-assisted recovery is genuinely rare rather than the common path.

The most common design mistake is allowing a single active session to add or remove an authenticator without a fresh MFA challenge; a stolen session cookie should not be enough on its own to let an attacker register their own device and lock the real user out, which is why the "verification steps" requirement above applies specifically to authenticator management, not just to login itself. A second pitfall is enrolling only one authenticator type per user (two TOTP apps on the same phone, for instance), which looks like redundancy but provides none, since the single point of failure (the phone) still takes down every registered factor at once. A third pitfall is treating admin-assisted recovery as a purely support-team process outside security's visibility; because it is the weakest link in the whole design by construction, it needs the same audit rigor and anomaly monitoring as any other privileged action, not less.

Direct answer

There are two fundamentally different architecture patterns for connecting on-premises Active Directory (AD, Microsoft's on-prem directory service for user, group, and computer objects) to a cloud identity provider (IdP): directory synchronization, which copies user and group objects into the cloud directory so authentication happens entirely there, and federation, which keeps authentication on-premises and has the cloud IdP redirect every login back to an on-prem federation server for a signed assertion. Synchronization itself splits into two sign-in modes, password hash sync and pass-through authentication, each trading availability against how much credential material ever leaves the premises. Getting this right also means tracking where each identity actually originated, correctly expanding nested group membership during sync, and reconciling two systems' password policies so a user is never told their password is valid by one and rejected by the other.

Structured elaboration

Architecture patterns: synchronization versus federation. In synchronization, a sync agent running on-premises periodically pushes user and group objects from AD into the cloud directory; once synced, the cloud IdP is authoritative for its own sign-ins, and legacy on-prem apps that authenticate directly against local AD via SAML or Kerberos keep working unmodified since only the cloud-facing identity gets copied out. In federation, the cloud IdP stores no validated credential at all: every sign-in is redirected, via SAML or a similar protocol, to an on-prem federation server that authenticates the user against live AD and hands back a signed assertion the cloud IdP trusts. The architectural difference that matters: synchronization makes the cloud directory authoritative over synced data, while federation keeps on-premises authoritative and makes every single cloud login dependent on the on-prem federation server's availability.

Security trade-offs: password hash sync vs. pass-through authentication vs. federation. Password hash sync (PHS) sends AD's password hash, already one-way hashed, re-hashed again for cloud storage, to the cloud directory, which then validates sign-ins entirely on its own; cloud services keep working even if the on-premises network is unreachable. The cost: an on-prem password change, account lockout, or disablement can lag behind the actual state until the next sync cycle, and hash material now exists in two systems instead of one, giving a cloud-side breach something to attack that would not exist under the other two patterns. Pass-through authentication (PTA) has a lightweight on-prem agent validate each cloud sign-in against live AD in real time, so no password hash ever leaves the premises, but cloud sign-in now depends on that agent and its network path being available; an on-prem outage takes cloud sign-in down with it. Federation stores no credential material in the cloud at all and instead trusts a signed assertion from an on-prem federation server, which gives the strongest "nothing leaves on-prem" guarantee but the heaviest operational load (federation servers, their certificates, and their own high-availability design) and the hardest on-prem dependency of the three. In short: PHS optimizes for availability at the cost of hash material existing in two places; PTA and federation optimize for credential material never leaving on-premises at the cost of making on-premises a hard dependency for every cloud login.

Account provenance. For every identity in the cloud directory, you need to know whether it originated on-premises (synced from AD) or was created natively in the cloud, and govern the two differently. A synced object should be treated as effectively read-only in the cloud for anything AD already owns, password state, group membership, disabled status, because editing it cloud-side gets silently overwritten by the next sync cycle or produces a split-brain state where the two systems disagree about the same account. The practical mechanism is tagging every synced object with an immutable source-anchor value derived from its on-prem object identifier, and building offboarding and access-review automation around that tag, so disabling a user in AD reliably disables their cloud access on the next sync, and so a cloud-native account (a contractor or partner provisioned directly in the cloud, never in AD) is never mistaken for an AD-governed one during an audit.

Synchronizing groups and nested groups. Syncing only a user's direct group memberships silently drops access for anyone whose permission actually comes through a group nested two or three levels deep, which is routine in a large AD forest built up over years. The sync agent has to expand nested membership during sync, or the receiving cloud directory has to evaluate nested groups natively, or the migration quietly breaks exactly the access it was meant to preserve. Deep or circular nesting is a genuine operational hazard on top of that: cap how many levels of nesting the sync will expand, and audit periodically for nesting cycles, because a naive recursive expansion can either loop indefinitely or produce a flattened membership list large enough to exceed the cloud directory's per-object limits.

Handling password policy differences. On-prem AD's password policy (complexity rules, lockout thresholds, password history) and the cloud IdP's own default policy will not automatically agree, and under password hash sync or pass-through authentication, letting the cloud enforce a second, conflicting policy on the same credential is how users end up told their password is fine by one system and rejected by the other. The working pattern is to make on-prem AD the single source of truth for password policy in a hybrid design, and either disable the cloud directory's native password-policy enforcement for synced accounts, or configure it to mirror AD's rules exactly. Anywhere the cloud IdP legitimately needs a stronger control than on-prem enforces, most commonly multi-factor authentication (MFA, requiring a second proof of identity beyond the password) on risky sign-ins, that control should layer on top of the existing password check rather than replace or duplicate it, so the two systems compose instead of contradicting each other.

Worked example

"Northwind," a company with a three-domain on-prem AD forest built over a decade of acquisitions, adopts password hash sync for cloud sign-in and federation-free simplicity, since its cloud services need to stay available even during on-prem maintenance windows.

flowchart TB
    subgraph Sync["Synchronization: password hash sync or pass-through auth"]
        AD1[On-prem Active Directory]
        Agent[Sync agent]
        CloudDir[Cloud directory]
        AD1 -->|sync objects, hash or live check| Agent
        Agent --> CloudDir
    end
    subgraph Fed["Federation, the alternative Northwind rejected"]
        AD2[On-prem Active Directory]
        FS[On-prem federation server]
        CloudIdP[Cloud IdP, trusts assertion only]
        CloudIdP -->|redirect| FS
        FS --> AD2
        AD2 -->|signed assertion| FS
        FS -->|assertion| CloudIdP
    end

During sync setup, Northwind discovers its "Finance-AllAccess" group is nested four levels deep (Finance-AllAccess contains Finance-Regional-Leads, which contains Finance-EMEA, which contains Finance-EMEA-Payables, and the individual users actually sit in that innermost group). A flat, direct-membership-only sync would have shown zero members of Finance-AllAccess in the cloud directory, silently breaking access for every finance analyst whose permission depended on that chain. Northwind's sync agent is configured to expand nested membership up to five levels and alert if it ever detects a cycle. Every synced user object carries a source-anchor value tied to its AD object identifier, so when a departing employee is disabled in AD, the next sync cycle disables their cloud access automatically, and a security review can immediately tell that account apart from the twelve contractor accounts Northwind provisioned directly in the cloud IdP, which have no AD source anchor at all. Finally, Northwind finds its on-prem policy requires 14-character passwords with no reuse of the last 24, while the cloud IdP's default policy allows 8-character passwords; rather than let the cloud enforce its weaker default (which would let a user set a password AD's own policy would have rejected) or its own separate stricter rule (which could reject a password AD already accepted), Northwind disables the cloud directory's native password-policy checks for every synced account and leaves AD as the sole authority, layering step-up MFA in the cloud IdP only for sign-ins flagged as high-risk.

Trade-offs and pitfalls

Choosing password hash sync purely for its availability benefit, without accounting for the sync interval, means an account disabled or locked out on-prem can still authenticate successfully in the cloud for as long as one sync cycle, a gap that matters in an active offboarding or compromise scenario and needs its own compensating control (a fast, on-demand sync trigger for exactly those events) rather than being accepted silently. Federation's strongest selling point, that no credential material ever reaches the cloud, is also its biggest operational liability: it makes every cloud sign-in depend on an on-prem service that now needs its own redundancy, certificate rotation, and monitoring, and an outage there takes down cloud access even though nothing in the cloud itself failed. The most common nested-group pitfall is discovering the broken access only after go-live, because a small pilot group rarely reaches the deeper end of an old AD forest's nesting; the fix is to explicitly test the sync against the forest's actual deepest nesting chains, not just a handful of well-behaved top-level groups. On password policy, a frequent wrong turn is letting both systems enforce independently "for defense in depth," which sounds safer but produces exactly the contradictory-rejection experience the single-source-of-truth pattern above is designed to prevent; additional strength belongs in an additional control like MFA, not in a second, uncoordinated password policy.