Authentication Security
Munera uses industry-standard cryptographic controls for all authentication. This page covers password policy, JWT token handling, SSO, and 2FA.
Password policy
| Requirement | Value |
|---|---|
| Minimum length | 12 characters |
| Uppercase letters | Required (at least 1) |
| Lowercase letters | Required (at least 1) |
| Numbers | Required (at least 1) |
| Special characters | Required (at least 1) |
| Password hashing | Argon2 (memory-hard, resistant to GPU cracking) |
JWT token handling
Munera issues two tokens on login:
- Access token — 30-minute lifetime, used to authenticate API calls
- Refresh token — 7-day lifetime, used to issue new access tokens without re-login
Both tokens are delivered exclusively as httpOnly; Secure; SameSite=Lax cookies. They are never exposed to JavaScript or stored in localStorage, making XSS attacks unable to steal session tokens.
Single Sign-On (SSO)
Munera supports SAML 2.0 SSO with Okta, Microsoft Azure AD, Google Workspace, OneLogin, Ping Identity, and any SAML 2.0-compliant identity provider.
Service Provider endpoints
| Endpoint | URL |
|---|---|
| Entity ID | https://munera.cloud/api/v1/sso/<org-slug>/metadata |
| ACS URL | https://munera.cloud/api/v1/sso/<org-slug>/acs |
| SLO URL | https://munera.cloud/api/v1/sso/<org-slug>/slo |
When Enforce SSO is enabled, password-based login is disabled for all members. Users who attempt to log in with a password are redirected to the IdP.
Two-factor authentication (2FA)
Munera supports TOTP 2FA compatible with Google Authenticator, Authy, 1Password, Bitwarden, and any TOTP-compliant app.
Enabling 2FA
- 1Go to Profile → Security → Enable 2FA
- 2Scan the QR code with your authenticator app
- 3Enter the 6-digit code to verify setup
- 4Save your 10 backup codes in a secure location — each can only be used once
Admins can enforce 2FA for all organisation members under Settings → Security → Require 2FA. Members who haven't set up 2FA are prompted on their next login.
API key security
API keys are hashed with Argon2 before storage — the server never holds the plaintext key after creation. Only the first 8 characters (the prefix) are stored for identification purposes. Keys expire after a maximum of 1 year and must be rotated.