Single Sign-On (SSO)
Single Sign-On lets your team sign in to your Areious application with your organization's existing identity provider, such as Microsoft Entra ID, Okta, Google Workspace, or Auth0, instead of a separate password. It uses the OpenID Connect (OIDC) standard, works with any OIDC-compatible provider, and runs alongside normal password sign-in. Each company configures its provider independently, and there is nothing to redeploy.
This is a shared article. It applies to every Areious product that supports SSO. Where a path includes a product folder such as /task/, substitute the folder where your product is installed.
- Your Areious application must be served over HTTPS. The sign-in round-trip and its security cookies require it.
- The app encryption key must be set (the
TASK_APP_KEYinconfig.php, or the auto-generated key file). The provider's client secret is stored encrypted with it, the same way two-factor secrets are. - You need administrator access to your identity provider to register a new application and read its issuer, client ID, and client secret.
- In your provider, create a new application (sometimes called an "app registration", "client", or "OIDC integration") for a standard web application.
- When it asks for a redirect URI (also called a "callback" or "sign-in redirect" URL), enter the exact address shown in your product under App Settings › Single Sign-On. It looks like
https://your-site/<app>/sso.php?action=callback, where<app>is the folder your product runs in (for example/task/). - Make sure the application requests the
openid,email, andprofilescopes (most providers include these by default). - Copy the provider's Issuer URL, Client ID, and Client secret.
- Open App Settings › Single Sign-On (SSO).
- Enter a Display name (this becomes the label on the login button, e.g. "Microsoft Entra ID").
- Paste the Issuer URL and Client ID, and paste the Client secret. The Discovery URL is optional, fill it in only if your provider's configuration is not at the issuer plus
/.well-known/openid-configuration. - Optionally set Allowed email domains (comma-separated) to restrict sign-in to your organization's domains.
- Choose whether to Auto-create accounts (see below).
- Select Test connection to confirm your application can reach the provider, then turn Enabled on and save.
- Microsoft Entra ID (Azure AD):
https://login.microsoftonline.com/<tenant-id>/v2.0. Register the app under App registrations, add the redirect URI as a Web platform, and create the secret under Certificates & secrets. - Okta:
https://<your-org>.okta.com. Create an OIDC "Web" app, add the redirect URI as the Sign-in redirect URI. - Google Workspace: issuer
https://accounts.google.com. Create an OAuth client ID of type "Web application" in the Google Cloud console and add the redirect URI as an authorized redirect URI. - Auth0:
https://<your-tenant>.auth0.com/. Create a "Regular Web Application" and add the redirect URI to its Allowed Callback URLs.
Any other OpenID Connect provider works too, as long as you can supply an issuer, a client ID and secret, and register the redirect URI.
When someone signs in through your provider, your Areious application matches them to an existing account by email address within your company. If a match exists, that account is linked to the provider and signs in. If there is no match:
- With Auto-create accounts on (and the email within any allowed domains), a new account is created automatically with the User role. You can change the role afterward under Users.
- With it off, the person is told there is no account yet, and an admin must create one first. Use this when you want to control exactly who has access.
Auto-created accounts sign in only through the provider, they have no separate password. Two-factor codes are not sent for SSO sign-ins, because your identity provider already handled authentication.
Once a provider is enabled, a Sign in with <name> button appears on the login screen beneath the password fields. Password sign-in keeps working, so administrators and any password-only accounts are never locked out.
Areious applications support SSO through OpenID Connect (OIDC). SAML 2.0 is not offered at this time. Most major identity providers, including Microsoft Entra ID, Okta, and Google Workspace, support OIDC.
- "Could not reach the identity provider": check the Issuer URL and use Test connection. The server must be able to make outbound HTTPS requests to your provider.
- "No account here matches your identity provider": the email has no account and Auto-create is off. Create the account first, or turn Auto-create on.
- "Your email domain is not permitted": the email is outside the Allowed email domains list. Adjust the list or sign in from an allowed domain.
- The button does not appear: confirm the provider is Enabled and has a Client ID, and that you are on HTTPS.
- Confirm the redirect URI registered at the provider exactly matches the one shown in App Settings, including
httpsand any subfolder such as/task/.
Two-Factor Authentication
Two-factor authentication (2FA) adds a second step to signing in: after your password, you confirm with a short code so a stolen password alone isn't enough to get into your account. Areious applications offer two methods, and you turn either on from Account Information › Security:
- Authenticator app (recommended). A code from an app such as Google Authenticator, Microsoft Authenticator, Authy, or 1Password. It works offline and does not depend on email delivery.
- Email code. A 6-digit code emailed to your account address at each sign-in. There is nothing to install.
When you set up an authenticator app, it becomes the method used at sign-in. The emailed code stays available as a simpler option and as the fallback for anyone who hasn’t set up an app.
- Open Account Information from the user menu and switch to the Security tab.
- Under Authenticator app, choose Set up authenticator.
- In your authenticator app, scan the QR code. If you can’t scan, choose “enter a setup key” in the app and type the Setup key shown, or use the Open in an authenticator app link on the same device.
- Enter the 6-digit code your app shows, plus your current password, and confirm.
- Save the recovery codes you’re shown (see below). You’re done; the next sign-in will ask for a code from your app.
When you set up an authenticator app, you are shown ten one-time recovery codes. Each works once and lets you sign in if you lose your phone. Copy or download them and keep them somewhere safe, they are shown only once. On the Security tab you can see how many are left and choose Regenerate recovery codes (password-confirmed) to replace the set with a fresh ten; the old codes stop working.
If you’d rather not use an app, open the Security tab and, under Email code, choose Turn on email codes and confirm with your password. From then on, each sign-in asks for a code emailed to your account address.
- Enter your email and password as usual.
- On the verification screen, enter your code: the 6-digit code from your authenticator app (or one of your recovery codes) if you set up an app, otherwise the emailed code.
- An emailed code expires after 10 minutes; if it doesn’t arrive, check spam, then use resend the code. After several wrong entries you’ll be asked to sign in again.
On the Security tab, turn off whichever method you use. Turning off the authenticator app asks for your password and a current code (or a recovery code), so a stolen session alone can’t remove it. Turning off email codes asks for your password. If your organization requires 2FA (below) and email codes are your only factor, the off option is hidden.
A Global Admin can turn on Require two-factor authentication in App Settings. When it’s on, every user must complete a second step at each sign-in. Anyone who has set up an authenticator app uses that; everyone else gets an emailed code automatically, with no setup step. It’s all-or-nothing: on for everyone, or off.
A person can be locked out if they lose the phone with their authenticator app (and their recovery codes), or, with emailed codes, if a code can’t reach them (2FA by email depends on a working SMTP setup). There are several ways back in, from easiest to last resort:
- Recovery code. If they set up an authenticator app, they can enter one of their saved recovery codes on the verification screen instead of an app code. No admin action needed.
- Reset it from Users. A Global Admin opens the Users area, finds the person (a 2FA on badge shows who has it), and chooses Reset 2FA. This clears every factor on the account, the authenticator app, its recovery codes, and the email opt-in, so they can sign in with just their password and set 2FA up again later.
- Turn off the requirement. If 2FA is required for everyone and an admin is locked out, another Global Admin turns the Require two-factor authentication toggle off in App Settings (a per-user reset alone won’t bypass the requirement).
- Server break-glass. If the only Global Admin is locked out, whoever manages the server runs the product’s 2FA reset script from the application folder (in Areious Task this is
php scripts/task_2fa_reset.php). Run it with no options to see usage.
Encourage everyone to save their recovery codes when they set up an app, and confirm a test sign-in code actually arrives before requiring 2FA for everyone, especially for Global Admins.
Open Source & Licensing
A common question when evaluating self-hosted software is whether it is open source, and what that means for security, support, and legal review. This article explains how Areious products are licensed, and why that model is built for confidence rather than secrecy.
This is a shared article. It applies to every Areious product.
Areious products are source-available but commercially licensed, not open source. The full application is delivered as readable code you can inspect (Areious Task, for example, ships as plain, unencoded PHP). What you receive is a license to run the software; the code itself remains the property of Areious Technologies and is governed by your license agreement and the End User License Agreement (EULA).
Yes. The application is delivered as readable source, not obfuscated or encoded, so your security team can review exactly what runs, before and after you deploy it. There is no hidden component and nothing to decompile. For many security-conscious teams, that transparency is the main reason to choose a self-hosted product.
Areious is. Security patches and product updates are a contractual commitment included in your subscription and delivered on a maintained schedule, rather than depending on volunteer contributors who may or may not respond. Support is handled through Areious support tickets. This is the practical difference from community open source: a single, accountable maintainer with defined responsibility for keeping the software current and secure.
Every release ships with a signed integrity manifest. The application verifies it at runtime, so any change to a shipped file causes the application to fail closed rather than run altered code. Releases are signed, and each license is an offline, domain-bound signed key that cannot be forged or moved to another domain. Security rests on cryptography and licensing, not on hiding the code.
Areious products are distributed under a commercial license with an accompanying EULA, and there are no copyleft obligations. Unlike some open-source licenses, such as the GPL or AGPL, the Areious license does not require you to publish or share source code, so procurement and legal review stay straightforward. If your legal team needs the license terms for review, Areious support can provide them.
The application is delivered as readable code so you can review and audit it, but it remains licensed software. Modifying shipped files is not permitted under the license, and the signed integrity manifest means altered files stop the application from running. If you need a change, a new capability, or an integration, contact Areious support or use the documented configuration options and APIs, which are the supported ways to extend the product.
Areious products are self-hosted: your data stays in your database on your infrastructure, and the application does not phone home to operate. You keep full control of your data at all times, which is a core reason teams choose a self-hosted Areious product over a cloud-only service.
SMTP Email Setup
The SMTP Host is the mail server your Areious application connects to when it sends notification emails. It usually looks like smtp.yourdomain.com, mail.yourdomain.com, or a provider address such as smtp.office365.com or smtp.gmail.com.
- Find out who manages the email account that should send notifications: the web hosting company, domain registrar, Microsoft 365, Google Workspace, or another provider.
- Sign in to that provider's admin area or hosting control panel.
- Look for Email Accounts, Email Setup, Mail Client Setup, SMTP Settings, Server Settings, or Manual Configuration.
- Search the provider's help site for "SMTP settings" plus the provider name if the settings are not obvious.
- If the organization has an IT or hosting support contact, ask them for the outgoing SMTP details for the notification email address.
- SMTP Host: the outgoing mail server name, such as smtp.yourdomain.com.
- SMTP Port: commonly 587 for TLS, 465 for SSL, or 25 only when the provider requires it.
- Encryption: usually TLS with port 587 or SSL with port 465.
- SMTP Username: often the full email address that will send notifications.
- SMTP Password: the email password or an app password created for this system.
- From Email: the address recipients will see as the sender.
- From Name: the display name recipients will see, such as Areious Notifications.
- Reply-To Email: optional, but useful when replies should go to a shared inbox.
Some providers do not allow a normal mailbox password to be used by self-hosted systems. If the test email fails even though the host and port look correct, check whether the provider requires SMTP authentication, two-step verification, or an app password for external applications.
- Enter the SMTP details in App Settings.
- Save Email Settings.
- Use Send Test Email and check the recipient inbox.
- If the email does not arrive, read the error message, verify each field, and try again.
- Also check spam or quarantine folders, especially the first time.
Signing In
Everyone reaches your Areious application from the same login screen: enter your email and password to sign in. The screen also handles new accounts, forgotten passwords, and the first sign-in for imported users.
A Create Account button appears on the login screen only when a Global Admin has turned on Allow Registration in App Settings. On a fresh install the very first account to register becomes the Global Admin; every account created afterward starts as a User. When registration is off, a Global Admin adds people from the Users area instead.
- Select Forgot your password? on the login screen and enter your email.
- The application emails a one-time reset link. For privacy it always says a link is on its way, whether or not an account exists for that address, so it never reveals who has an account.
- Open the link and set a new password (minimum 8 characters). The link expires after a short time and can only be used once; request a fresh one if it lapses.
Password reset depends on email, so a Global Admin must have SMTP configured. If no email arrives, check spam or quarantine first, then ask an admin to confirm the mail settings.
People created through a Users CSV import (or otherwise given a temporary password) are asked to set a new password to continue the first time they sign in. Enter and confirm a new password (minimum 8 characters) to finish signing in; this happens once.
For security, your Areious application signs you out after a long stretch with no activity. Shortly before that happens, a “Still there?” message appears with a short countdown. Choose Stay signed in to keep working, and the countdown clears with nothing lost. If you don't respond before it reaches zero, you are returned to the login screen so an unattended session isn't left open.
Simply using the application keeps your session alive, so someone actively working never sees this prompt. If a session does lapse while you're part-way through something, such as after leaving a form open for a while, you are told that your session expired and returned to the login screen. Sign back in and carry on; anything you had already saved is safe.
Account & Password
Open Account Information from the user menu to manage your profile and password. The window has two tabs.
Update your first and last name, email, and timezone. Your timezone is what dates and times are shown in throughout the application. To save any change here, enter your current password in the field at the bottom to confirm it is you.
Switch to the Password tab to set a new password. For your security, changing it signs you in fresh; use a strong, unique password.
The same user menu is where you reach your personal reports and, for a Global Admin, the application’s settings.