Liigu põhisisu juurde
Alloy.Networks

Using Mailcow Email Accounts to Log In to Nextcloud

This document explains how to configure Nextcloud so that users authenticate using their Mailcow email accounts.

Users log in with their full email address, such as [email protected], and the same password used for their mailbox.

This is shared authentication, not full federated single sign-on. There is no separate identity provider such as OpenID Connect, SAML, Keycloak, or Authelia. Nextcloud simply verifies credentials against the Mailcow IMAP service.

For a small self-hosted organization, this is often the simplest and most practical arrangement.

What This Setup Does

Mailcow remains the system that manages:

  • mailbox accounts
  • mailbox passwords
  • email identity

Nextcloud is configured so that:

  • the username is the user’s full email address
  • authentication is checked against the Mailcow IMAP server

When a user enters their email address and password into Nextcloud, Nextcloud attempts an IMAP login against Mailcow. If that succeeds, the user is authenticated.

What This Setup Is Not

This setup is not:

  • OpenID Connect
  • SAML
  • OAuth login
  • browser-session SSO across services
  • a central identity provider

A user may still need to log in separately to:

  • Mailcow webmail
  • Nextcloud

However, they use the same credentials in both places.

Example Service Layout

Use separate hostnames for each service.

  • mail.example.com for Mailcow
  • cloud.example.com for Nextcloud

Mailcow provides:

  • SMTP
  • IMAP
  • SOGo
  • mailbox authentication

Nextcloud uses the Mailcow IMAP service as the external authentication backend.

Architecture:

Users
  |
  +-- mail.example.com  (Mailcow)
  |     |
  |     +-- SMTP
  |     +-- IMAP
  |     +-- SOGo
  |     `-- Mailbox authentication
  |
  `-- cloud.example.com (Nextcloud)
        |
        `-- authenticates users via IMAP

Why Use This Approach

Advantages:

  • users already know their email login
  • only one password needs to be remembered
  • no extra identity stack is required
  • password control stays with Mailcow
  • simple for small teams
  • easy to understand and troubleshoot

For organizations with around 5 to 20 users, this is usually easier to maintain than deploying a full SSO platform too early.

Authentication Flow

The login flow works like this:

  1. The user opens cloud.example.com
  2. The user enters their full email address and mailbox password
  3. Nextcloud checks those credentials against the IMAP service on mail.example.com
  4. Mailcow accepts or rejects the login
  5. If accepted, Nextcloud logs the user in
  6. If this is the first successful login, Nextcloud can create the user account automatically

In plain text:

User -> Nextcloud login page
     -> Nextcloud sends IMAP auth request
     -> Mailcow IMAP verifies credentials
     -> Success or failure returned to Nextcloud
     -> User allowed in if successful

Required Nextcloud App

Nextcloud needs the External user authentication app.

Enable it from the web interface:

  • Apps
  • Integration
  • External user authentication

Or enable it from the command line:

sudo -u www-data php occ app:install user_external
sudo -u www-data php occ app:enable user_external

IMAP Backend Configuration

Configure an IMAP authentication backend in Nextcloud.

Use values like these:

  • Backend type: IMAP
  • IMAP server: mail.example.com
  • Port: 993
  • Encryption: SSL/TLS
  • Username format: %u

The username should be the full email address.

Example:

This is important because Mailcow mailbox authentication is typically based on the full email address, not just the local part.

Username Mapping

In this setup, the Nextcloud username is the email address itself.

Examples:

This avoids inventing a second username format for Nextcloud.

Automatic User Creation

On the first successful login:

  1. Nextcloud verifies the credentials against IMAP
  2. The user is accepted
  3. Nextcloud creates a local profile for that authenticated user
  4. A home directory and normal Nextcloud storage structure are created

This means you do not need to pre-create every user manually inside Nextcloud.

Password Management

Passwords remain controlled by Mailcow.

Typical behavior:

  1. A user changes their mailbox password in Mailcow
  2. The old password stops working for IMAP
  3. The old password also stops working for Nextcloud
  4. The new password works in both places

This keeps password management centralized.

User Lifecycle

A normal user lifecycle looks like this:

Creating a User

  1. Create the mailbox in Mailcow
  2. Assign the mailbox password
  3. Give the user the Nextcloud URL
  4. The user logs in for the first time
  5. Nextcloud creates the user automatically

Disabling a User

  1. Disable or remove the mailbox in Mailcow
  2. IMAP authentication stops working
  3. The user can no longer log in to Nextcloud

This is one of the main advantages of the arrangement. The email account effectively becomes the controlling identity.

Limitations

This setup is simple, but it has limits.

No Browser SSO

Logging into Mailcow does not automatically log the user into Nextcloud, and vice versa.

No Central Session Management

There is no global logout across services.

No Role Federation

Mailbox existence proves identity, but it does not automatically manage rich application roles in the way a true identity provider can.

IMAP Dependency

If IMAP is unavailable, authentication to Nextcloud may fail.

Because of that, Mailcow uptime directly affects Nextcloud login if you rely entirely on this method.

Security Considerations

Use TLS Everywhere

Both services should be served over HTTPS:

  • https://mail.example.com
  • https://cloud.example.com

IMAP authentication should use TLS on port 993.

Do Not Expose Plain IMAP for Authentication

Use IMAPS rather than unencrypted IMAP.

Use Strong Passwords

Since mailbox credentials are also used for Nextcloud, mailbox passwords become more important.

Consider MFA Separately

This setup does not automatically provide MFA for Nextcloud unless you add it inside Nextcloud itself or move later to a real identity provider.

Limit Admin Accounts

Do not make every mailbox user a Nextcloud admin. Authentication and authorization are separate things.

Practical Example

Assume the following mailbox exists in Mailcow:

The user goes to:

  • https://cloud.example.com

The user enters:

Nextcloud connects to:

  • IMAP host: mail.example.com
  • Port: 993
  • Security: TLS

If Mailcow accepts the IMAP login, Nextcloud logs the user in.

Suggested Deployment Pattern

For a small organization, the clean pattern is:

  • Mailcow on mail.example.com
  • Nextcloud on cloud.example.com
  • full email address used as the username everywhere
  • mailbox passwords managed only in Mailcow
  • HTTPS on both services
  • IMAPS for authentication
  • automatic user creation in Nextcloud enabled

This gives one identity per user without adding a separate identity stack.

When This Approach Is Appropriate

This approach is appropriate when:

  • the organization is small
  • all users already have mailboxes
  • you want to reduce password sprawl
  • you do not need full SSO
  • you want the simplest route away from Google Workspace

When to Move Beyond This

You may eventually outgrow this setup if you need:

  • one-click login across many applications
  • centralized MFA across all services
  • richer access policies
  • group-based authorization
  • identity federation for more than a few services

At that point, it makes sense to introduce a proper identity provider such as Authelia, Keycloak, or another OIDC/SAML solution.

Summary

Using Mailcow email accounts to log in to Nextcloud is a practical and lightweight way to unify user identities in a self-hosted environment.

The core idea is simple:

  • Mailcow owns the user accounts
  • Mailcow owns the passwords
  • Nextcloud authenticates against Mailcow via IMAP
  • users log in with their full email address
  • one credential set works across both systems

For a small organization replacing cloud solutions, this is often the simplest working model.

← Tagasi blogisse