This release brings several updates to Hanko’s 3rd party (OAuth, OIDC) integration:
A smaller release, but with some important fixes and improvements. Most notably:
prompt parameter to fine-tune the social SSO UX
The main feature of this release is PKCE support for 3rd-party OAuth flows of the Hanko API. When using Hanko with a mobile app, the oauth_state cookie might not be stored, so the thirdparty_oauth action now accepts a code_verifier. When the code_verifier ist set, the state cookie is optional, but the code_verifier is required when exchanging the Hanko token with the exchange_token action.
In case you want to support any SSO provider that is not in the list of pre-built connections (like Apple, Google, Microsoft etc.), Hanko now supports custom social SSO connections, for both OAuth and OpenID Connect (OIDC) identity providers.
Custom Social Connections can be configured in Hanko Cloud Console. Each custom connection will get its own Continue with {provider_name} button on Hanko Elements.
.svg)
Hanko now supports user metadata that can be attached to user profiles and managed via the Admin API. Metadata is organized into three categories:
Private metadata cannot be accessed via the public API and should be used for sensitive data that should not be exposed to the client (e.g., internal flags/ids, configuration, or access control details).
Public metadata can be read via the public API and should be used for non-sensitive information that you want accessible but not modifiable by the client (e.g., certain user roles, UI preferences, display options).
Unsafe metadata can be read and manipulated via the public API and should be used for non-sensitive, temporary or experimental data that doesn’t need strong safety guarantees.
Metadata can be accessed in session JWT templates to map metadata to claims in a session token.
See Metadata docs for full details and examples.
Starting today, Hanko Cloud Pro customers can purchase additional projects for $5/month each, once they’ve reached the included project limit.
Most teams are well-served by the defaults:
We chose these limits because a typical setup includes at least one development and one production project. But as teams grow, so do their requirements, whether it’s supporting multiple apps, dedicated staging environments, or isolated test setups.
Since Hanko is a cloud-native platform, each project is a standalone instance with its own configuration, database, and user pool. This isolation ensures reliability and security, but also means each project consumes infrastructure resources.
To keep things scalable, Pro subscribers can now add as many extra projects as they need for $5/month per project—no upgrade or custom plan required.
Need more projects? Just add them from your dashboard whenever you need.
We’re thrilled to announce the release of Hanko v2.0!
This major update introduces a completely redesigned JavaScript/TypeScript SDK built to work hand-in-hand with our Flow API. It gives developers everything they need to build custom authentication experiences—backed by passkeys and all of Hanko’s powerful features.
When we launched Hanko v1.0 a few months ago, we introduced the Flow API to make our authentication logic more flexible, testable, and robust. While the primary driver for Flow API at the time was to improve the internals of Hanko itself, it quickly drew attention from developer teams wanting to build custom frontends and mobile apps using the raw API.
At the time, our main recommendation for most projects was to use Hanko Elements — a set of Web Components that deliver complete, drop-in authentication flows out of the box. Hanko Elements is built on top of the Flow API and gives teams a fast, no-code path to passkey-first login and account management, with deep configurability.
Under the hood, Hanko Elements has always used an internal SDK to interact with the Flow API. But while that internal SDK helped us ship our own UI fast, it wasn’t yet ready for the outside world. It lacked the simplicity, type safety, and developer experience we wanted to provide to teams building their own UIs.
Over the past several weeks, we’ve focused heavily on rebuilding this SDK from the ground up — and today, we’re excited to make it available to everyone.
The new JavaScript/TypeScript SDK introduced in Hanko v2.0 is designed for developers who want full control over their frontend, while still taking advantage of everything the Flow API has to offer — from passkeys, multi-factor authentication, and optional passwords to social logins, SSO, and more.
It offers a clean, typed interface for managing authentication flows via the Flow API, while taking care of things like:
Example usage:
const hanko = new Hanko({ apiUrl: "https://auth.example.com" });
const state = await hanko.createState("login");
await state.actions.continue_with_login_identifier.run({
username: "maria@example.com",
});
hanko.onBeforeStateChange(({ state }) => {
console.log(`Action invoked: ${state.invokedAction?.name}`);
});
hanko.onAfterStateChange(({ state }) => {
console.log(`Transitioned to: ${state.name}`);
if (state.name === "login_init") {
state.passkeyAutofillActivation();
}
});
This new SDK gives developers full flexibility to design their own user onboarding, login, and account management interfaces — using whatever UI framework they prefer.
One of the standout features of the new SDK is its local State object. Each flow state is modeled as a structured, serializable object that gives developers everything they need to render the UI for that step and trigger the correct actions.
onBeforeStateChange, onAfterStateChange).This makes it easy to create predictable, testable user flows — and integrate authentication deeply into your app’s own state management and UX logic.
If you’re looking to get started quickly with passkey-based authentication, Hanko Elements is still the fastest way. It gives you a fully working, themeable auth UI in minutes.
But if you're building a custom user experience — or you’re working on a mobile app or design system where Web Components don’t fit — the new SDK is for you.
It’s especially helpful if you:
We’ll continue to expand the SDK with more features, helper functions, and tighter integrations with frontend frameworks like React, Vue, and Svelte. We’re also working on updated examples and documentation to help teams get started even faster.
Check out the updated documentation for implementation guides and the complete Flow API reference.
We’d love to hear what you’re building with the new SDK!
Feel free to open an issue, start a discussion on GitHub, or reach out to us on Discord.
Happy building! 🚀
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.