Signing in

Every way a session begins and ends: the sign-in page itself, the hand-over to an identity provider that signs the user in somewhere else, the reduced page a guest gets when they follow a share link, and what happens when a session runs out while the app is still open. What protects the account once the user is inside — passwords, second factors, recovery details, sessions on other devices — is covered under Account and security.

Signing in and out

Summary The page that asks for a user name or email address and a password, and the Sign out entry in the account menu that ends the session again. It is the way in wherever a deployment has no single sign-on, and it is also the page a user lands on when a session ends — with a notice saying so if the sign-out happened on its own.

Why it matters This is the one screen every user meets, usually in a hurry and often on a device that is not their own. What makes it bearable is small and easy to leave out: an error that names the field that was wrong rather than announcing that something failed, a user name already filled in from the link that was followed, the page itself in a language the user reads before the account has told anyone which language that is. Signing out matters for the opposite reason — a session left open on a shared machine is an open mailbox, which is why a deployment can put the button in the top bar and remind the people who keep closing the tab instead.

Description

Enter a user name or email address and a password; empty fields are caught before anything is sent
A failed sign-in is reported in words, next to the field that caused it
The user name field can be prefilled through the login_name URL hash parameter
The sign-in page can be switched to another language before signing in
A deployment can force the page to HTTPS, and can send users to its own sign-in and sign-out locations
After an automatic sign-out the page says You have been automatically signed out
Sign out ends the session from the account menu, and from a dedicated top bar button where the deployment enables one
A small popover beside the account menu asks users who left without signing out to use the button next time

Availability Since 7.10.6 or earlier. The dedicated button (io.ox/core//features/dedicatedLogoutButton) and the reminder (io.ox/core//features/logoutButtonHint/enabled) are both off by default; custom locations come from io.ox/core//customLocations/login and io.ox/core//customLocations/logout. The parameters the page understands are listed under Sign In. Resetting a forgotten password and ending sessions on other devices are described under Account and security.

Stay signed in between visits

Summary A Stay signed in checkbox under the password field. Ticked, it remembers the session in a cookie, and the next visit from the same browser goes straight into the app instead of showing the form. The browser is offered the credentials as well, so it can remember them itself.

Why it matters Webmail gets opened many times a day, and a password typed that often is either a weak one or one that lives on a note beside the screen. Remembering the session takes away the reason to pick a bad password, and takes away the habit of leaving the tab open all day rather than signing in again. It is equally the control a deployment needs in the other direction: an organization that cannot accept remembered sessions on shared machines switches automatic sign-in off outright, instead of asking people not to tick a box.

Description

A Stay signed in checkbox on the sign-in page, remembered in a cookie
On the next visit the app attempts an automatic sign-in before the form is shown
The deployment sets the default state of the checkbox, and can switch automatic sign-in off entirely
The credentials are submitted so that the browser's own password manager can store them

Availability Since 7.10.6 or earlier. Automatic sign-in is skipped where OpenID Connect is in use, because the provider decides whether the user is still signed in.

Automatic sign-out after inactivity

Summary After a stretch without activity the session ends by itself. Shortly before it does, a dialog counts the remaining seconds down and offers to stay signed in, or to sign out immediately. The user chooses the timeout in Security settings, from the list of intervals the deployment offers.

Why it matters The session that leaks is almost never the one somebody attacked; it is the one left open on a laptop in a meeting room, on a shared terminal, or on a desk in an open-plan office. A timeout closes it without anyone having to remember to. The countdown is what keeps the measure from being resented: someone who is reading rather than typing gets a chance to say they are still there, instead of losing the screen mid-sentence. Where a timeout has to apply to everyone, the deployment removes the Never option, so the length stays the user's choice but the exposure does not.

Description

A countdown dialog shortly before the session ends, offering to stay signed in or to sign out now
The timeout is picked in Security settings, from a list of intervals the deployment defines
Removing the Never option from that list makes a timeout compulsory
The timer is shared across open tabs, and paused where tab handling is active
The sign-in page afterwards states that the user was signed out automatically

Availability Since 7.10.6 or earlier. The timeout is io.ox/core//autoLogout and the choices offered are io.ox/core//autoLogoutOptions, both described in the list of settings.

Summary When a session ends while the app is open, a dialog appears over the blurred window and asks for the password. The user name is already known, so the password is all that is needed, and signing in returns the user to exactly where they were rather than to a freshly loaded app.

Why it matters The cost of an expired session is hardly ever the sign-in. It is the half-written message, the appointment filled in but not saved, the reply composed over lunch in a tab nobody touched for an hour. Being thrown out to the sign-in page loses all of it, and the user only finds out when they come back to an empty compose window. Keeping the app loaded behind the dialog means the expiry costs the few seconds it takes to type a password, and nothing else.

Description

The dialog says why the session ended — it expired, or the IP address changed
Only the password is asked for; the user name is already known
Requests that failed while the session was gone are retried once sign-in succeeds
Switched off, or in a single sign-on deployment, the user is sent to the sign-in page instead
Guests who were never given a password are not asked for one

Availability Since 8.27. Feature toggle reloginPopup, on by default. It switches itself off in SAML and OpenID Connect deployments, where the identity provider renews the session instead.

Summary Where the deployment uses SAML, no sign-in form is shown here at all. The user is taken to their organization's own sign-in page, signs in there, and comes back already signed in. The same route renews the session when it runs out, and — where single logout is configured — signing out ends the session at the identity provider too.

Why it matters A separate password for webmail is a password that gets reused, written down, or reset every few weeks, and it has to be revoked separately when somebody leaves. Handing sign-in to the identity provider leaves one account to manage, one place where a second factor or a device policy is enforced, and one place to close when access should stop. The user sees the side of that which matters to them: the account they already sign in to everything else with works here as well, and keeps working once it has.

Description

Sign-in is redirected to the identity provider, and the session is established on the way back
An expired session is renewed through the same provider rather than with a password prompt
Single logout ends the identity provider's session as well, where it is configured
A connection error can be shown as a page of its own, or redirected to an error page the deployment names

Availability Since 7.10.6 or earlier. SAML is set up on the Middleware side rather than in the UI, and the client follows what the server configuration announces. Single logout additionally requires the saml-single-logout capability. The inline sign-in dialog above is not used here.

Summary The same hand-over, for deployments that use OpenID Connect. The user is sent to the provider's sign-in page and returns signed in. Expiring sessions are renewed quietly in the background, so a long day in the app usually passes without a second prompt, and signing out ends the session at the provider as well.

Why it matters Renewal is where this one shows its value. The session is refreshed in a hidden frame while the user carries on working, so the familiar symptom of a timed-out session — a password dialog over a half-written message — simply never appears. The number of silent attempts is capped, which matters more than it sounds: a browser that blocks the hidden frame's cookie would otherwise leave a user in a loop that never resolves. Once the cap is reached they get an ordinary interactive sign-in and carry on.

Description

Sign-in is redirected to the provider, and the session is established on the way back
An expired session is renewed silently in a hidden frame, with a limited number of retries
When silent renewal does not succeed, the user is sent to an interactive sign-in instead
Signing out ends the session at the provider as well
Automatic sign-in from a stored cookie is skipped, because the provider decides

Availability Since 7.10.6 or earlier. OpenID Connect is set up on the Middleware side rather than in the UI, and the client follows what the server configuration announces. As with SAML, the inline sign-in dialog is not used.

Open the app from another application without signing in again

Summary Another application can hand a user straight in. It passes a pair of tokens, or an existing session id, in the URL; the app exchanges that for a session and starts up signed in. From the user's side there is nothing to do — a link or a button somewhere else opens the app, and they are already in.

Why it matters Users meet this as the absence of something. A portal, a native client or a provider's own start page opens the web app and no second sign-in appears. Without it, every hand-over ends at a password prompt the user has arguably just passed, which is an interruption and a bad habit at once: people used to being asked for their password after following a link are exactly the people phishing works on. Passing a short-lived token rather than credentials is what makes the hand-over safe to build in the first place.

Description

A pair of server and client tokens in the URL is exchanged for a session
An existing session id can be handed over in the URL instead
Every hand-over parameter is stripped from the URL once the session is established

Availability Since 7.10.6 or earlier. Token login must be enabled on the Middleware (com.openexchange.tokenlogin); those settings are described under Authentication.

Summary Someone who follows a share link gets a reduced sign-in page instead of the usual one. Depending on how the share was made they sign in with a guest password against the address they were invited at, with only the password that protects the link, or with nothing at all.

Why it matters The person at the other end of a share link has no account here and no particular wish for one. Asking them for a user name they do not have is how a shared folder quietly turns back into a file emailed around — the very thing the share was meant to replace. Keeping the page to the one field that actually applies, and letting a guest set or reset their own password for the share, is what makes sharing outside the organization work without a support request behind every link.

Description

Guest sign-in shows only the password field, with the invited address filled in and not editable
Anonymous sign-in asks only for the password that protects the link
A guest can have a password reset mail for the share sent from the same page
The reset link opens a Set password form that asks for the new password twice
A guest can add or change the password for the share later from the account menu

Availability Since 7.10.6 or earlier. Requires guest. A deployment can point guests at its own sign-in location with io.ox/core//customLocations/guestLogin.

Summary Almost everything about the look of the sign-in page comes from the deployment's configuration rather than from a theme: the logo, the background, the colors and shape of the form, the layout, the footer links, and an optional notice above the form. Smartphones can be given a set of values of their own.

Why it matters This is the one screen a user sees before anything else has loaded, and it is frequently reached from a link rather than from the provider's own site — which makes it the screen on which they decide whether they are in the right place at all. A generic form at an unfamiliar address is hard to tell from a phishing page; the provider's own logo, and its imprint and privacy links in the footer, are what say otherwise. Keeping this in configuration rather than in a theme also lets one deployment give each tenant a page of its own.

Description

Logo, background image or color, form colors, border radius and shadow
Layout variants — the form centered, to the left, to the right, or a split screen beside a teaser text
A footer carrying copyright, version, privacy policy and imprint links, each translatable
An information message block above the form, in one of a set of preset styles
Custom CSS, scoped to the sign-in screen
A separate set of values that applies on smartphones

Availability Since 7.10.6 or earlier. It is configured in as-config.yml rather than in the UI and supports multi-tenancy; the properties are listed under Login page.