You can now bring attributes from your SAML and custom OIDC connections into Hanko as custom claims, with definitions and mappings fully configurable in the Hanko Cloud Console.
Define the claims your application needs, such as department, groups, or employee ID, and map the corresponding attributes from each identity provider. Different providers can use different attribute names while your application receives a consistent set of claims.
Custom claims support typed values, including strings, numbers, booleans, and lists. Values are updated when users sign in through a mapped connection and can be included in session tokens using JWT templates. A new user.update.custom_claims webhook event lets your application react when values change.
Group users into organizations and assign roles within each organization. A user can, for example, be an admin in one organization and a member in another.
You can manage organizations, memberships, and role assignments through the Admin API, and check the current user’s organization roles through a dedicated session-based endpoint.
This feature currently requires a Hanko Cloud Pro subscription and is managed through the Admin API. Support for managing organizations and roles in the Hanko Cloud Console is coming soon.
$2b$ format.
The main feature of this release is support for Firebase Scrypt password hashes, specifically to enable importing Firebase users together with their existing Scrypt password hashes.
This makes it possible to migrate users from Firebase Authentication while preserving their password hashes, as exported via the Firebase CLI.
Beyond that, we updated a number of dependencies as usual.
The main feature of this release is Inactivity Logouts, which allow user sessions to be proactively terminated if no user activity is detected.
This can be configured via a new configuration option. In addition, an idle_expires_at timestamp is now returned by the /sessions/validate endpoint, allowing frontends to react to upcoming idle logouts accordingly.
Beyond that, we updated a number of dependencies and included several small bug fixes.
This release improves user profile handling, enhances session token transparency, and includes important security fixes.
Users can now store name and picture attributes directly in Hanko.
This allows:
These attributes follow standard OIDC conventions, are available via the API, and can be managed like other user properties. The main source for these properties will be 3rd-party accounts like Google or GitHub for now. We will add the required functionality to manage these fields to the profile element in a later update.
Session tokens now include AMR (Authentication Methods References) values.
This enables relying parties to:
The AMR claim follows standard OIDC conventions.
/me EndpointThe /me endpoint has been extended to return additional user information.
This reduces the need for follow-up requests and simplifies frontend integrations that rely on a single user introspection endpoint.
Replaced string concatenation with prepared statements when querying audit_logs.
This prevents potential SQL injection attacks and strengthens overall security.
Security notification webhooks were not triggering correctly in certain scenarios.
This has been fixed and webhooks now work as expected.
This release brings several security, reliability, and usability improvements across Hanko’s authentication stack. It includes stronger passcode options, better key management integration, more robust auth flows in Hanko Elements, improved device trust handling, and expanded localization support:
In addition to numeric passcodes, Hanko now supports optional alphanumeric passcodes. This increases entropy and makes passcode-based authentication more resilient against brute-force and guessing attacks.
Hanko’s token signing engine can now be configured to use external HSMs and Key Management Systems, currently only AWS KMS is supported. This allows teams with higher security requirements to keep signing keys fully managed outside of Hanko.
Hanko now optionally sends email notifications for security-relevant actions (enabled by default), for example when a new passkey is added to an account. These notifications help users detect suspicious activity early and improve overall account security.
Hanko Elements now uses PKCE-based flows by default. This resolves several issues with third-party integrations, especially in setups where the backend is not running on the same domain as the frontend.
Device trust cookies are no longer overwritten on shared machines or when multiple users log into the same application. This improves reliability for shared computers and multi-account setups while keeping device trust intact per user.
Hanko now officially supports Dutch (NL). This includes UI text, backend mailing templates, and security notification emails, providing a more complete localized experience for Dutch-speaking users.
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 is 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.