AxiPassAxiPass
Security

The SWA security model must be explainable before it is convenient

AxiPass operates SSO/OIDC, SAML, SCIM, SWA, and audit logs inside a clear tenant boundary.

Standards-based IdP

SSO and account sync run on proven, standard protocols rather than a proprietary scheme.

  • OIDC/OAuth2 is built on Doorkeeper and publishes OpenID configuration and JWKS at standard discovery paths.
  • The SAML 2.0 IdP provides per-tenant metadata, SSO, and SLO (Single Logout) endpoints.
  • SCIM 2.0 Users and Groups automate account provisioning for joiners, movers, and leavers.

SWA security model

Auto-login for non-SSO apps is handled as part of the access management workflow, not as a convenience-only feature.

  • SWA credentials are stored with Lockbox column encryption on the server side.
  • The extension runs on auto-login target pages, and permission-scope reduction is tracked as a security improvement before production distribution.
  • Credential use, autofill failures, and key activity can connect to audit logs.

Tenant isolation

AxiPass IdP domain models are separated through the Identity namespace and tenant scope.

  • Primary Identity models use acts_as_tenant, and tenant boundaries are drawn by the path-based /t/:tenant_slug scope.
  • Audit logs and app settings are queried by tenant boundary.
  • Company domain ownership is verified with a DNS TXT record, and operator and tenant console authorization boundaries stay separate.

Secret encryption and key rotation

Secrets used for authentication are handled distinctly, from how they are stored to how they can be exposed.

  • Recoverable values such as OAuth client_secret, SWA credentials, and SAML certificates are stored with Lockbox column-level encryption.
  • SCIM Bearer tokens are never stored in plaintext; only a one-way hash is kept, and the token is shown just once at issuance.
  • OAuth and SAML key rotation goes through a dedicated procedure, and rotation history is recorded in the audit log.

Layered MFA policy

MFA is not just a personal setting; it can be enforced as a tenant policy.

  • TOTP-based two-factor authentication and backup codes are provided.
  • Tenant-wide and group-level enforcement can be applied to match your organization's policy.
  • A re-authentication interval and a per-login re-auth option let you tune the trusted session window.

Audit logs and isolated storage

Authentication, authorization, configuration changes, and SWA activity become standard security evidence.

  • Audit logs are kept in a dedicated database separated from service data.
  • Events are stored in UTC and shown in the user's time zone, and CSV exports and ISMS-P PDF reports support internal reviews and security-audit preparation.
  • Secrets such as passwords and MFA seeds are not included in logs, flash messages, or redirect parameters.

Session termination propagation and transport security

Logout does not stop at the IdP; it is designed to reach connected apps as well.

  • On IdP logout, termination of OIDC tokens, SAML sessions, SWA execution tokens, and browser-extension sessions is propagated together.
  • Production enforces HTTPS and applies HSTS.

What we do not claim, and what we must explain

Certification claims stay factual

We do not display external certifications or security audit reports as complete before they are actually complete.

Secrets are stored by the right method

Recoverable secrets use Lockbox column encryption, while verification tokens such as SCIM Bearer tokens are stored as one-way hashes, and no plaintext is retained.

Logs are evidence, not a secret store

Audit logs record who accessed which app or setting and when. Passwords and MFA seeds are not stored in logs.