Authentication Settings
The Authentication section of the Console controls which authentication methods are available to users of your tenant, and how those methods behave. Validate the effective policy in a test tenant before changing access for existing users.
Sovereign mode (default) is a product posture, not a certification claim. New tenants ship with US social IdPs (Google, GitHub, Microsoft, Apple, etc.) and SMS OTP off. Enabling either is an explicit admin opt-in and is written to the audit log (who / when / what). Customer or EU IdPs via custom OIDC, and national IdPs, remain available.
Social Providers
Auris supports nine OAuth 2.0 / OpenID Connect social providers. Enabling a social provider adds a corresponding login button to the hosted login page.
Supported Providers
| Provider | Protocol | Notes |
|---|---|---|
| OIDC | Most widely used. Requires Google Cloud project. | |
| GitHub | OAuth 2.0 | Well-suited for developer-focused products |
| Microsoft | OIDC | Supports both personal and work/school (Entra ID) accounts |
| Apple | OIDC | Required for iOS apps that offer social login |
| OAuth 2.0 | Requires Facebook app with Login product enabled | |
| Discord | OAuth 2.0 | Popular for community and gaming products |
| OIDC | Professional identity, suited for B2B products | |
| Twitter / X | OAuth 2.0 | Developer API v2 required |
| Slack | OAuth 2.0 | Suited for workspace-based products |
Enabling a Social Provider
Open the Social Providers section
Go to Console → Authentication and open the Social Providers tab.
Enable the provider
Click the toggle next to the provider name to enable it. The configuration fields expand.
Enter application credentials
For each provider, you must obtain a Client ID and Client Secret from the provider’s developer portal:
| Field | Description |
|---|---|
| Client ID | The application identifier from the provider’s developer console |
| Client Secret | The secret used to authenticate token exchange requests |
Store these values in the provider’s configuration fields in the Console. They are stored encrypted at rest.
Configure the callback URL
Each provider requires you to register an Authorized Redirect URI (or Callback URL) in its developer portal. The required value is displayed in the Console next to the provider’s configuration form:
https://[your-auris-domain]/api/auth/social/callbackRegister this URL exactly in the provider’s portal. The URL must match exactly — protocol, hostname, port, and path.
Set optional scopes
By default, Auris requests the minimum scopes needed to obtain the user’s email address and display name. To request additional scopes (for example, calendar.read for Google), enter them in the Additional Scopes field as a space-separated list.
When a user authenticates via a social provider for the first time, Auris creates a new user account using the email address returned by the provider. If an account with that email already exists, the social identity is linked to the existing account automatically (unless the existing account requires a different primary authentication method per your policy).
Passwordless / Magic Links
Magic links allow users to authenticate by clicking a link sent to their email address, without a password. The link contains a short-lived token that is valid for a single use.
Enabling Magic Links
Go to Authentication → Passwordless and toggle Magic Links on.
Configuration Options
| Setting | Description | Default |
|---|---|---|
| Allow Signup | Whether new users can register using magic links | Enabled |
| Redirect URL | The page users are sent to after clicking the link and authenticating | Tenant’s default post-login URL |
| Token Expiry | How long the magic link remains valid (minutes) | 15 |
Allow Signup
When enabled, clicking a magic link for an email address that does not exist in your tenant automatically creates a new account. When disabled, magic links only work for existing users.
Disable this if you want to control user registration through invitation-only workflows or manual user creation.
Token Expiry
Magic link tokens are single-use and short-lived. After the configured expiry time, the link becomes invalid and the user must request a new one. The recommended range is 10–30 minutes.
For implementation details, see Magic Links.
SMS OTP
SMS OTP is off by default under sovereign mode. Enabling it is a non-sovereign admin opt-in (audited).
SMS OTP supports phone verification and permitted second-factor flows. SMS 2FA cannot be enabled while magic-link login is enabled; the enable route returns 409 SMS_2FA_UNAVAILABLE. See the current SMS flow before configuring an application.
Enabling SMS OTP
Go to Authentication → SMS OTP and toggle it on.
Provider Configuration
Auris uses Twilio for SMS delivery in production. Configure your Twilio credentials:
| Field | Description |
|---|---|
| Provider | Twilio (production) or Console Logging (development — codes are printed to server logs, no SMS sent) |
| Account SID | Your Twilio Account SID (starts with AC) |
| Auth Token | Your Twilio Auth Token |
| Sender Phone Number | The Twilio phone number or Messaging Service SID to send from |
Use Console Logging mode during development and testing to avoid Twilio API charges.
Rate Limits
SMS OTP codes have built-in rate limiting to prevent abuse:
| Limit | Value |
|---|---|
| Maximum sends per user per hour | 5 |
| Minimum time between sends | 30 seconds |
| Maximum verification attempts per code | 5 |
If a user exhausts their attempts on a single code, they must request a new one.
MFA Settings
Multi-factor authentication (MFA) adds a second verification step in a supported login or step-up flow. Check compatibility with the primary login method; a pending challenge is not a completed session.
MFA Methods
| Method | Description | Setup Required |
|---|---|---|
| TOTP | Time-based OTP via authenticator apps (Google Authenticator, Authy, etc.) | User scans QR code during enrollment |
| SMS | One-time code sent to the user’s registered phone number | User must have a verified phone number |
| WebAuthn | Hardware security keys (YubiKey) or platform authenticators (Face ID, Windows Hello) | User registers authenticator during enrollment |
Enable or disable each method with the toggle on the MFA Settings page. At least one method must be enabled if MFA enforcement is configured.
MFA Enforcement Policy
| Policy | Behavior |
|---|---|
| Optional | Users can choose to enable MFA in their account settings. It is not required. |
| Required | All users must complete MFA enrollment before accessing the application. Users without MFA configured are redirected to the enrollment flow after their first login. |
| Adaptive | MFA is required dynamically based on risk score. Low-risk logins proceed without MFA; high-risk logins trigger an additional factor. See Adaptive MFA. |
Recovery Codes
Recovery codes are single-use backup codes that allow a user to log in when their primary MFA device is unavailable. Configure recovery code settings:
| Setting | Description | Default |
|---|---|---|
| Number of codes | How many recovery codes are generated per user | 10 |
| Allow regeneration | Whether users can regenerate their recovery codes (invalidates old ones) | Enabled |
Adaptive MFA
When the enforcement policy is set to Adaptive, Auris calculates a risk score for each login attempt based on five signals:
| Signal | Weight | Description |
|---|---|---|
| New device | Medium | Device fingerprint not seen before for this user |
| New IP address | Low | IP address not seen before for this user |
| New country | High | Country of origin is new for this user |
| Impossible travel | High | Geographic distance from last login is physically impossible in the elapsed time |
| VPN / proxy | Medium | IP is identified as a VPN exit node or proxy server |
If the calculated risk score exceeds the configured threshold, MFA is required for that login. The exact weights and thresholds are configurable in Security Settings → Suspicious Login Detection.
Session Policies
Session policies control how long authenticated sessions remain valid and what happens to sessions when certain events occur.
Session Duration Settings
| Setting | Description | Default |
|---|---|---|
| Access Token Lifetime | How long an access token remains valid before expiring | 3600 seconds (1 hour) |
| Refresh Token Lifetime | How long a refresh token remains valid | 2592000 seconds (30 days) |
| Idle Session Timeout | Maximum time a session can remain inactive before expiring | 1800 seconds (30 minutes) |
| Maximum Concurrent Sessions | Maximum number of active sessions per user. 0 for unlimited. | 0 (unlimited) |
Session Behavior on Security Events
| Event | Configurable Actions |
|---|---|
| Password change | Revoke all other sessions immediately / Keep sessions |
| Account disabled | Revoke all sessions immediately (always on) |
| Role change | Token refreshed with new roles on next refresh / Revoke all sessions |
Note: Setting a low Idle Session Timeout (under 15 minutes) will cause frequent re-authentication for users on slow networks or who navigate away briefly. Balance security requirements against user experience for your audience.
Password Policy
The current native login endpoint rejects password authentication. Use the supported passwordless/hosted login flow. Legacy password-policy fields do not establish a supported native password-login path; do not promise password expiry, history or breach checks based on those fields alone.
SMTP Configuration
Transactional emails (magic links, MFA codes, password resets, invitations) are sent via your configured SMTP server. Go to Settings → SMTP to configure:
| Setting | Description |
|---|---|
| SMTP Host | Hostname of your outbound mail server |
| Port | SMTP port (typically 587 for STARTTLS, 465 for SSL) |
| Username | SMTP authentication username |
| Password | SMTP authentication password |
| Sender Address | The From address for all outgoing emails (for example, [email protected]) |
| Sender Name | The display name in the From header (for example, Acme Corp) |
| Encryption | STARTTLS or SSL/TLS |
Use the Send Test Email button to verify your SMTP configuration by sending a test email to your administrator account.
Popular SMTP providers: Amazon SES, SendGrid, Postmark, Mailgun, and self-hosted Postfix.
Related Guides
- Hosted Login — How the OAuth 2.0 PKCE flow works
- Social Login — Detailed social provider integration guide
- Magic Links — Passwordless email authentication
- SMS OTP — Phone-based authentication
- Passkeys / WebAuthn — Hardware and platform authenticators
- Adaptive MFA — Risk-based MFA configuration
Validate the complete integration
Test a new user, an existing user, a denied callback, second-factor recovery and another tenant before rollout. Confirm both HTTP status and the response body when testing configuration changes.
For an API integration, run the signed-token verification example. To review your application and tenant boundaries, request an Auris integration demo .