Successful OAuth completion should redirect to configured Lobby URL even when invite tenant matches resolved tenant

[woksin]

What happens

When an invitation is completed with OAuth, InviteCompletion.IsTenantIssuedInvite returns true if the configured Invite.TenantClaim value equals the resolved tenant. In that case, TryResolveLobbyRedirect preserves the OAuth challenge returnUrl (containing the original /invite/{token} path) instead of redirecting to the configured Lobby.Frontend.BaseUrl.

For platform-level onboarding invitations (e.g. a JoinAda invite type where the token's tenant claim matches the platform's single fixed tenant), the OAuth flow succeeds but the user is redirected back to the invite path, breaking the setup journey.

Source references (v2.21.0):

• InviteCompletion.IsTenantIssuedInvite: returns true when TenantClaim == resolvedTenant
• TryResolveLobbyRedirect: bypasses Lobby.Frontend.BaseUrl when IsTenantIssuedInvite is true

Evidence

• AuthProxy v2.21.0
• A JoinAda invite with tenant_id claim matching the platform's fixed tenant (both are intentionally identical)
• OAuth/exchange succeeds, signed attestations validate, invitation is accepted
• Post-OAuth redirect returns to /invite/{token} instead of Lobby setup page
• Browser downloads the token file or shows an invalid-link page

What it costs a consumer

Platform-level invitation flows (where there is only one tenant, or where the platform itself issues cross-cutting invites) cannot complete their setup journey. OAuth succeeds but the user cannot proceed. The consumer must work around the check with a distinct claim value and internal remapping.

Suggested fix — the seam

Provide an explicit policy option that forces the Lobby redirect regardless of the tenant-match check. This could be:

1. A configuration option on the Invite or Lobby section (e.g. AlwaysRedirectToLobby, ForceLobbyRedirect, or IgnoreTenantMatchOnInviteRedirect)
2. An invite-type property that opts out of the tenant-match check
3. A distinct TenantClaim vs InviteScope claim design that separates storage tenancy from redirect behavior

The exact naming and shape are open to maintainers. The key requirement is that a consumer with a valid completed invitation can always reach the configured Lobby.Frontend.BaseUrl, even when the tenant claim matches the resolved tenant.

What is explicitly not being asked for

• Removing the existing tenant-match behavior (it may be correct for multi-tenant scenarios)
• Any change to the attestation protocol, signed exchange, or security model
• Any consumer-specific policy or invite-type logic in AuthProxy

[cratis-stagehand]

Thanks for opening this - it has been received and will be looked at.

---

Posted by Stagehand (AI) - an autonomous agent, not a person. Review accordingly.