Authentication Methods

ActiveManage supports a stack of authentication methods, each suitable for different audiences and security postures. Most deployments mix several — staff sign in with corporate SSO while customers use email-and-password.

Supported Methods

• Local username/password — the built-in method; credentials hashed with Argon2id and stored in the platform's database.
• Microsoft 365 / Azure AD (OAuth2 / OpenID Connect) — sign in with a corporate Microsoft identity.
• Google Workspace — OAuth2 sign-in for organisations on Google Workspace.
• SAML 2.0 — enterprise SSO compatible with Okta, Auth0, OneLogin, ADFS and others.
• Magic link — one-time tokens delivered by email; useful for low-friction customer flows.
• Passkey / WebAuthn — passwordless cryptographic authentication using device biometrics or hardware keys.
• API token — for programmatic access by integrations and headless clients.

Choosing the Right Methods

• Internal staff: SSO (Azure AD / Google / SAML) — minimises password sprawl and inherits the corporate identity lifecycle.
• External customers: Local password plus optional magic-link for password-shy users.
• High-security roles: Local password + mandatory 2FA, or passkey.
• API integrations: Long-lived tokens (rotated) or short-lived JWTs.

Stacking Methods

A single user can have multiple enabled methods. For example a staff member could use Azure AD for daily sign-in and a passkey as a backup for when SSO is down. The login page shows whichever options the user (or their tenant) has enrolled.

Note: When SSO is enabled, you can disable local password sign-in for that user to prevent it being used as a back door. Look for the per-user toggle on the user profile.

Local username-and-password is the built-in authentication method. It works for any user, requires no external provider, and is enabled by default. This article covers how it's configured, how passwords are stored, and the policy levers you control.

How Passwords Are Stored

Passwords are never stored in plaintext. The platform hashes them using Argon2id (the current OWASP recommendation) with a per-user salt. Older hashes from migrated systems (bcrypt, PBKDF2) are accepted on sign-in then transparently upgraded.

Policy Settings

• Minimum length: Default 12 characters.
• Character classes: Require uppercase, lowercase, digits and/or symbols.
• Common password rejection: Reject passwords found in HaveIBeenPwned's top breach lists.
• Password history: Prevent re-use of the last N passwords.
• Maximum age: Force a password change every N days (0 = never).
• Maximum failed attempts: Account auto-block threshold.

Policy by Audience

• Internal staff: 14 chars, all character classes, 90-day rotation, history of 12, hard breach-list rejection.
• External customers: 10 chars minimum, no character class requirements (better usability), breach-list still active.
• High-security (e.g. finance team): 16 chars, mandatory 2FA, 30-day rotation.

Worked Examples

• NIST 800-63B alignment: Drop character-class requirements, raise minimum to 14, rely on breach-list rejection and 2FA — modern best practice.
• Legacy migration: Migrating from a system that stored MD5 hashes — set minimum length to current policy, force-change on next sign-in to upgrade hashes.

Warning: Mandatory 90-day rotation is no longer recommended by NIST. It tends to produce predictable passwords like “Spring2026!”. Rely on length, breach detection and 2FA instead.

External providers offload authentication to a third-party identity provider (IdP) — Microsoft, Google, Okta, ADFS, Auth0, GitHub or any SAML/OIDC-compliant IdP. The user signs in there and the IdP tells ActiveManage who they are.

Benefits

• One password less: Users don't manage a separate credential for your app.
• Centralised lifecycle: Disabling a user in the IdP immediately denies them access here.
• MFA inherited: If the IdP enforces 2FA, you get it for free.
• Audit trail: The IdP's sign-in logs supplement your own.

Generic Setup Pattern

1. In the IdP, register ActiveManage as an application. Note the client ID and secret (or upload the metadata XML for SAML).
2. In ActiveManage, open Architect Panel → Authentication Methods → Add Provider.
3. Pick the provider type and paste the credentials.
4. Map IdP attributes (email, name, groups) to user fields.
5. Define how groups in the IdP map to security groups in ActiveManage — e.g. okta-admins grants the Admin security group.
6. Save, then test by signing out and clicking the provider's button on the login page.

Worked Examples

• Azure AD: Staff log in through Microsoft 365. Engineering group in Azure AD → “Developers” security group inside ActiveManage.
• SAML via Okta: A consultancy uses Okta as IdP, with three SAML role attributes determining which projects each consultant can see.
• GitHub: Open-source contributors sign in with GitHub to a partner portal where their GitHub identity is the source of truth.

Tip: Always create at least one local admin password as an emergency break-glass account in case the external IdP goes down. Store it in your team's password manager and rotate after every use.