Two new privacy settings have been added to control whether the disclosure of information about user accounts should be accepted for the sake of usability:

• Show account existence hints: When registering or trying to log in, feedback is displayed indicating whether or not an email address already exists (e.g. “The email is already taken.” or “The email address is unknown.”). When disabled, the system hides this information and behaves identically in both cases to avoid disclosing information about existing email addresses (this has previously been the default behavior).
• Hide unavailable login methods: Only display the authentication methods that are actually available to a user during the sign-in process (e.g. after the user enters an e-mail address as the identifier in the sign-in form, only prompt the user for a password if they actually have one). If disabled, all theoretically possible authentication options are always displayed to avoid disclosing information about existing email addresses (this has previously been the default behavior).

Please note: Full protection against email enumeration attacks is only provided if both settings, “Show account existence hints” and “Hide unavailable login methods” are disabled. Please note that this may result in a poorer user experience, as users will no longer receive direct feedback if, for example, they have entered an incorrect email address, or if they are suggested the option to enter a password even though they do not have one.

‍

Support for HTML email rendering and delivery has been added alongside plain text emails. The changes ensure that both plain text and HTML versions of passcode and notification emails are generated and sent, improving email formatting and readability across different clients. We will further improve the styling of the HTML emails in a future patch.

‍

Hanko's SAML implementation is now able to handle Identity provider (IdP) initiated login requests. This is a key feature for B2B customers that require their own IdP to handle authentication to apps that use Hanko. Now, those B2B users can access apps that use Hanko via their "App directories" or "App launchers" (e.g. Entra, Google Workspace, Okta) and initiate the authentication flow right from there. The existing SAML flow (SP-initiated SSO) can continue to be used.

Hanko Cloud projects can now be configured with a custom domain. That means that your Hanko API URL can be changed from e.g. https://be11cd95-4125-45db-65e7-a62a64dacb97.hanko.io to auth.yourdomain.com.

Setting up a custom domain for a project effectively removes cross-domain from your setup, which has a number of benefits:

1. OAuth consent screen displaying your domain instead of hanko.io. This is a big one and the main reason we're allowing custom domains for all projects, not only Pro subscribers. When your users click on Sign in with Google, they are redirected to a Google login / consent page that shows them which website will be granted access to their Google email address. The domain displayed here should be yours, not us. That's now possible with custom domains.
2. The new device trust feature requires a custom domain to work reliably across all browsers, since Hanko stores the device trust flag in a cookie that cannot be cross-domain in some browsers due to tracking protection defaults.

‍

All projects that have activated either at least one social SSO provider or device trust should configure their custom domain as soon as possible.

This update adds options to allow users to skip 2FA on trusted devices, a “Stay signed in” checkbox, "Last used" labels on social SSO buttons, and improvements to the Admin API.

Device trust

A new device trust feature offers users the option of not having to perform 2FA again for a certain period of time after successful 2FA. Administrators can determine whether device trust should be established automatically, or whether the user should be asked whether they trust the device, or whether trusted devices should never be allowed and 2FA should always be enforced.

Stay signed in

This new option can be used to control whether a persistent cookie or a session cookie should be issued when the user is logging in. Persistent cookies (default) remain valid for the set session duration, i.e. the user remains logged in even if the browser is closed. Session cookies are usually deleted when the browser or browser tab is closed, so users have to log in again the next time they visit the app. A third option adds a “Stay signed in” checkbox to the login screen, which allows the user to determine the type of cookie themselves.

Last used indicators

Social SSO buttons (e.g., "Sign in with Google") now display a "Last used" label to help users remember which provider they chose on their last visit and avoid creating redundant accounts. Note that active Account Linking still allows users to change the login method to some extent, but only if the email address matches.

New Admin API endpoints

The Admin API has been extended with the following new endpoints:

• password (get, create, update, delete)
• webauthn (list, get, delete)
• otp (get, delete)
• sessions (list, create, delete)

User import improvements

User import functionality has been improved. Now, more user data and credentials can be imported, e.g.:

• Usernames
• Passwords (bcrypt hashes)
• WebAuthn credentials
• OTP secrets

This release contains Multi-Factor Authentication (MFA) capabilities for Hanko backend and Hanko Elements.

Hanko has been optimized for WebAuthn and passkey authentication from the very beginning. However, the additional implementation of other, potentially weaker authentication methods such as passwords and email passcodes meant that we also had to add MFA (or 2FA). And here it is: TOTP authenticator apps as well as FIDO security key support.

As a bonus feature, we added the option for MFA enrollment during registration and login flows, allowing admins to easily enforce MFA adoption among their user base if required.

TOTP authenticator apps

As the de facto standard for 2FA, the most obvious benefit of Time-based One-Time Passcodes (TOTP) is their universality. Users can choose from a myriad of authentication apps such as Google Authenticator, Microsoft Authenticator and many more to generate the one-time codes – no special hardware required.

Security keys

We just had to support security keys as second factors due to their unmatched security benefits. No other MFA method can protect users as reliably against phishing and most other known account takeover attacks.

Hanko 1.1 is here, introducing optional server-side sessions as an alternative to the previous approach of just issuing JWTs, together with a bunch of small improvements and bug fixes.

Server-side sessions

With a new setting located in the Session menu in Hanko Cloud, server-side sessions can be enabled or disabled. Alongside this setting, we've added a /sessions endpoint to the public API.

If server-side sessions are enabled (the default for new projects), sessions are stored in the DB, displayed on the user's profile, and can be revoked by the user. Note: To be able to use the advantages of server-side sessions, it is necessary to always validate JWTs via the new /sessions endpoint.

Active sessions list and revocation

A sessions list has been added to the <hanko-profile> element. Here, users can monitor their sessions and revoke them remotely. The session data displayed includes the operating system and browser used (retrieved from the user agent string), the IP address, and a the date on which the session was last active.

Session limit

Admins can now control how many active session are allowed per user. This can be relevant in certain use cases, e.g. if only a single session should be permitted.

We are excited to release Hanko 1.0 today. After two years in Beta, Hanko 1.0 is more user friendly, more customizable and more mature than any previous release in almost all areas, which is now represented by the 1.0 version number.

Highlights

Options, options, options

• Identifiers and auth methods can be enabled individually and freely combined, no more implicit settings
• Optional passwords that can be deleted by the user, i.e. give users the choice to select a password or a passkey as their preferred authentication method
• Smooth migration of existing users, e.g. transition from a password-based system to passkeys, without overburdening all users at once

Usernames

• Usernames are now supported as identifiers, in addition to email addresses
• Emails and usernames can also be used simultaneously

Privacy

• Configurations that use the email identifier and require email verification now effectively prevent email enumeration, enabling a fully privacy-preserving implementation of login and registration
• A setting to disable "privacy mode" for situations where explicit feedback to the user is preferred (e.g. "An account using this email address already exists.") is planned for a future release

Dedicated login and registration flows

• Login and registration flows have been separated to present only relevant actions to the user, e.g. "Sign in with a passkey" makes no sense for a user who wants to register a new account
• Introducing new elements <hanko-login> and <hanko-registration> that can be placed on separate pages, e.g. /login and /registration
• Combined <hanko-auth> element is still available, allowing users to toggle between login and registration on the same page

Introducing the all-new Flow API

This version contains a new API, which we call Flow API (#1532). With the previous RESTful API of the Hanko backend, it had become very complex to extend the functionality of Hanko. This was mainly due to the fact that most of the state handling was done in Hanko Elements and each endpoint had to be called in a specific order to work properly. The Flow API takes over this complexity completely in the backend and thus enables us to further develop the Hanko system at a higher speed than ever before.

• This 1.0 release includes the Flow API as well as the completely redesigned Hanko Elements to match the Flow API
• Flow API consists of three new endpoints: /registration, /login, and /profile
• A number of new email templates have been introduced to provide better context for users
• Old API endpoints handling login and registration will be deprecated, but will continue to work for the foreseeable future to allow a smooth transition to the Flow API
• A frontend SDK and documentation for the creation of custom frontends for the Flow API will follow shortly

Migration

When migrating your application to the new Hanko 1.0 Elements, be aware of the following changes: 

• onAuthFlowCompleted events have been removed (use onSessionCreated instead)
• onSessionCreated contains the session JWT, but not the user ID anymore

For the self-hosting migration guide see the release notes on GitHub.

Send your own passcode emails with Hanko's new custom email sending feature. Custom email sending allows you to have full control over emails sent to your users. Simply subscribe to the new email webhook and build your own emails. See the custom email docs here.

New features:

• Added the email.send webhook (Project settings > Webhooks)
• New setting to disable email delivery by Hanko (Project settings > Emails)

We've added support for Sign in with Microsoft and Discord to Hanko Cloud. Hanko Cloud admins can find both under the Identity providers section in the project's settings.

Once enabled, the respective "Sign in with..." buttons will be displayed for all users on your <hanko-auth> sign in and sign up page.

Sign in with Microsoft supports both personal and work accounts (e.g. Office 365 or Azure AD / Entra accounts). This feature took a good amount of work and was stalled for a few months because we stumbled upon the "nOAuth" security vulnerability (basically by accident) and had to find a way around it. To make sure your Hanko project is protected when using Sign in with Microsoft, please follow the steps highlighted in the Hanko Docs for the Microsoft identity provider.

Other changes:

• Automatic account linking can now be toggled for each individual identity provider
• Third-party sign-ups are now correctly displayed in the project dashboard statistics