Login in Joomla

2. The Backend Login Screen

2.1 What You See

The backend login screen is small on purpose: a username field, a password field, an optional secret key field for multi-factor authentication, and a language selector. There is no registration link and no "create account" option, because the backend is for staff, not for the public.

2.2 The Screen Is Built From a Module

Just like the Control Panel, the login screen is not a hard-coded form. The component view renders an administrator login module (mod_login) and any other modules published to the special login position:

// administrator/components/com_login/tmpl/login/default.php
$loginmodule = LoginModel::getLoginModule('mod_login');
echo ModuleHelper::renderModule($loginmodule, ['id' => 'section-box']);

This means you can add extra boxes (a notice, a logo, a security warning) to the backend login by publishing modules to the login position on the administrator side.

2.3 A Built-in Clickjacking Defence

When the login view renders, the controller sends an extra HTTP header:

$this->app->setHeader('X-Frame-Options', 'SAMEORIGIN');

This stops another website from loading your login form inside a hidden frame and tricking an administrator into clicking on it. It is a small detail, but it shows that login is treated as a security-sensitive screen from the very first request.

4. The Login Modules

4.1 One Name, Two Clients

There are two mod_login modules in Joomla, one for each client:

4.2 The Failsafe That Saves Locked-out Admins

The login model loads the backend login module in an unusual way. It ignores the module's published state and its access level on purpose. The core comment explains why:

"This is put in as a failsafe to avoid super user lock out caused by an unpublished login module or by a module set to have a viewing access level that is not Public."

In plain terms: even if you accidentally unpublish the backend login module or set its access to a non-public level, you can still log in. The login form will always render. This is a deliberate safety net, not a bug.

4.3 Remember Me

The site login module offers a Remember Me checkbox. When ticked, Joomla stores a long-lived cookie so the visitor stays logged in across browser sessions. This feature depends on the Authentication - Cookie plugin being enabled, which the next section explains.

6. Authentication Plugins

6.1 The Plugin Decides, Not the Component

Joomla does not hard-code how a password is checked. Instead it asks every enabled authentication plugin the question "do these credentials check out?" through the onUserAuthenticate event. Each plugin returns success, failure, or "not my job".

Joomla 6 ships three core authentication plugins:

6.2 How Passwords Are Stored

The Authentication - Joomla plugin never deals with a plain-text password in storage. Joomla saves each password as a salted bcrypt hash in the password column of #__users, created with PHP's native password hashing API. A stored value looks like this:

$2y$10$Ux3...   (algorithm, cost, salt, and hash in one string)

Two consequences matter in practice:

• Even a Super User cannot read a user's password. A forgotten password can only be reset, never recovered.
• Joomla rehashes on login. When you sign in, the plugin checks whether the stored hash still uses the current algorithm and cost. If it does not, Joomla transparently re-hashes the password and saves the stronger version. Your stored credentials get safer over time without anyone lifting a finger.

6.3 The Secret Key Field and MFA

The third field on the login form, the secret key, feeds Joomla's multi-factor authentication. After the password is accepted, Joomla can require a second factor (a TOTP code, a passkey, an email code) before the session is fully trusted. This is the captive login flow: a logged-in user with an unmet MFA requirement is held on the verification page until they complete it.

6.4 Single Sign-On and Custom Logins

Because authentication is plugin-based, you can extend it. Need login via Google, Microsoft, SAML, or your own API? You write (or install) an authentication plugin that subscribes to onUserAuthenticate. You never edit com_login itself. This is the same decoupling pattern Joomla uses everywhere: the core asks a question, and plugins answer.

8. Under the Hood (Developer View)

8.1 Component Structure

com_login exists only on the administrator side. There is no frontend folder and no sql/ folder, because the component stores nothing:

administrator/components/com_login/
├─ services/provider.php          (DI container wiring)
├─ src/
│  ├─ Controller/DisplayController.php
│  ├─ Dispatcher/Dispatcher.php
│  ├─ Model/LoginModel.php
│  └─ View/Login/HtmlView.php
├─ tmpl/login/default.php          (renders the login module)
└─ login.xml                       (manifest)

8.2 The Dispatcher Restricts the Tasks

The component will only ever do two things. The dispatcher throws away any task that is not login or logout:

$task = $this->input->get('task');

if ($task != 'login' && $task != 'logout') {
    $this->input->set('task', '');
}

This narrows the attack surface: you cannot trick the component into running some other controller method.

8.3 The Controller: login and logout

The controller is short. The login task checks the CSRF token, reads the credentials from the model, calls $app->login(), then redirects:

public function login()
{
    $this->checkToken();

    $app         = $this->app;
    $model       = $this->getModel('login');
    $credentials = $model->getState('credentials');
    $return      = $model->getState('return');

    $app->login($credentials, ['action' => 'core.login.admin']);

    if (Uri::isInternal($return) && !str_contains($return, 'tmpl=component')) {
        $app->redirect($return);
    } else {
        $app->redirect('index.php');
    }
}

Two security details stand out. The checkToken() call blocks cross-site request forgery, and the Uri::isInternal() check stops an open-redirect attack: a crafted return URL can never bounce you to an external site after login.

8.4 The Model Reads the Credentials Safely

The model collects the submitted values with strict input filters and decodes the return URL from Base64, again validating that it stays internal:

$credentials = [
    'username'  => $input->get('username', '', 'USERNAME'),
    'password'  => $input->get('passwd', '', 'RAW'),
    'secretkey' => $input->get('secretkey', '', 'RAW'),
];

if ($return = $input->get('return', '', 'BASE64')) {
    $return = base64_decode($return);

    if (!Uri::isInternal($return)) {
        $return = '';
    }
}

8.5 Logging Out in Code

Logout mirrors login. It checks the token, then calls the application:

$app->logout($userid, ['clientid' => $clientid]);

The clientid decides which session to end. If shared_session is on, logging out of one client logs the user out everywhere. The onUserLogout event fires so plugins can clean up, for example removing the Remember Me cookie.

8.6 The Events You Can Hook

For custom login logic, subscribe to these events in a plugin instead of touching the component:

8.7 The Tables Login Touches

The login component owns none of these tables. It only triggers the shared login flow that reads and writes them.

8.8 Logging In From Your Own Extension

The same $app->login() call the component uses is available to your own code. A custom portal, an SSO bridge, or an importer can log a user in programmatically:

$app = Factory::getApplication();

$credentials = [
    'username' => 'john',
    'password' => 'secret',
];

// Fires the same event chain as the login form.
$app->login($credentials, ['action' => 'core.login.site']);

This runs the full authenticate → authorise → onUserLogin chain, so every plugin and permission check still applies. Use it with care: never hard-code real credentials, and always think through the security impact before you sign a user in outside the normal form.

8.9 Session Storage and Performance

A successful login writes a session, and every later request reads it. Where that session lives is a configuration choice under Global Configuration → System → Session Handler:

On a high-traffic site, moving sessions to Redis or Memcached is one of the most effective ways to cut database load, because every visitor, logged in or not, touches the session on every request.

10. SEO and Metadata

Login pages are not pages you want search engines to rank. The backend login at /administrator/ should never be crawled at all, and a frontend login page carries no useful content for search results.

Two practical points matter here. First, set the menu item for any frontend login page to noindex in its Metadata tab, so search engines skip it. Second, keep login behind HTTPS; modern browsers and search engines both penalise password forms served over plain HTTP. A login page does not help your SEO directly, but a secure, well-behaved one protects the trust signals that do.

12. Best Practices

If you remember only a few things from this article, remember these:

• The backend login is com_login; the frontend login is com_users. Know which one you are configuring.
• Never disable the User - Joomla plugin. Without it, login stops working everywhere.
• Control who may log in through the Site Login and Administrator Login permissions, not by editing files.
• Enable multi-factor authentication for every backend user, and enforce it for admin groups.
• Serve every login page over HTTPS, and set frontend login pages to noindex.
• Add new login methods (SSO, social, LDAP) with an authentication plugin; never patch com_login.
• Protect API tokens like passwords, and revoke them the moment they might leak.

14. Summary

Joomla login looks like a single form, but it is a small system of cooperating parts:

• com_login is the tiny admin-only component behind the backend login form; it stores no data and accepts only login and logout.
• com_users and mod_login provide the frontend login, redirects, and the Remember Me option.
• Authentication plugins decide how credentials are checked, so you can add SSO, LDAP, or social login without touching the core.
• Permissions (core.login.site and core.login.admin) decide who may walk through each door.
• Built-in defences (CSRF tokens, internal-only redirects, the clickjacking header, and the lockout failsafe) make login secure by default.
• The Web Services API replaces the form with a personal token.

Once you see login as a component plus modules plus a plugin chain, the whole system becomes predictable. You know where to set redirects, where to grant access, where to add a new login method, and where to look when something breaks.

If your site suffers from random logouts, locked-out administrators, or a login flow you are not sure is secure, those symptoms usually trace back to one of the layers above. Checking them in the right order is exactly the kind of methodical work a Joomla specialist does first, and it is often the difference between a site you can trust and one you cannot.