Share your product feedback

Add a new idea Subscribe
Status Future consideration
Categories Builder
Created by Guest
Created on Jul 4, 2026

RELATED IDEAS

Aha Builder Granular Authentication Options

What is the challenge?

  • Aha! Builder authentication methods (Password, Aha!, Google, GitHub, Microsoft, Okta/SAML) can only be toggled at the application level — there is no per-user control over which sign-in method a given user is allowed to use.

  • The current-user API (currentUser() / getCurrentUser(), client and server) exposes no signal for how the current session authenticated — there is no authMethod, identityProvider, ssoProvider, or equivalent field, and no session-level metadata anywhere in the framework's auth API. So an app can't even detect, let alone enforce, which method a user signed in with.

  • The built-in Password method supports no MFA/2FA (no TOTP, no MFA parameters on user creation or password update).

What is the impact?

  • Regulated / enterprise deployments can't reconcile two required goals: SSO-only + MFA for all normal users, and a password-based break-glass account for continued admin access during an SSO/IdP (e.g., Okta) outage. Enabling Password opens it to everyone (weakening the security posture); disabling it removes the break-glass path — there's no middle ground.

  • Because app code can't read the session's auth method, teams cannot build the missing control themselves in-app; the platform gives them nothing to enforce on.

  • The lack of native MFA on the Password method fails common compliance requirements outright, pushing teams to non-standard workarounds (e.g., external, non-federated accounts) or blocking production go-live entirely.

Describe your idea.

  • Add per-user authentication-method control in Builder — a per-user setting (in the app's user admin / Builder Users) for allowed sign-in methods, at minimum a simple "allow password sign-in" on/off flag, so admins can keep everyone SSO-only while permitting password for a controlled few (e.g., a break-glass account).

  • And/or expose the current session's authentication method / identity provider on the current-user object (e.g., getCurrentUser().authMethod / .identityProvider with values like password | saml | aha | google | microsoft), so application code can enforce its own auth policy and audit sign-ins.

  • Add native MFA/2FA (TOTP) support for the Password method, so a password-permitted account can still meet MFA requirements.

  • Any one of these three unblocks a compliant "SSO-only with a hardened break-glass" model; together they give app owners full control over authentication posture.

  • ADMIN RESPONSE
    Jul 15, 2026

    Thanks for submitting this idea! We have implemented the second option described – adding authMethod, currentIdentityProviderId, and identities properties to the user object.

    The type definitions are:

    type RecordId = `${number}`; // Big integer, it's a string to avoid precision loss in JavaScript
    type ProviderType = 'aha' | 'aha_oauth' | 'google' | 'microsoft' | 'github' | 'saml';
    type AuthMethod = 'password' | ProviderType;

    interface User {
      authMethod?: AuthMethod | null; // existing sessions will be null
      currentIdentityProviderId?: RecordId | null;
      identities?: UserIdentity[];
    }

    interface UserIdentity {
      providerType: ProviderType;
      identityProviderId: RecordId | null;
      identityProviderName: string | null;
      lastUsedAt: string | null;
    }


    We'll keep this idea open to collect votes on the other two suggested approaches included here too!

  • Attach files
Idea management by Aha!
Create your own ideas portal to crowdsource feedback
© 2026 Aha! Labs Inc.•All rights reserved