The postMethod variable can be null or missing in certain scenarios (such as when a verification link is clicked multiple times), causing the FreeMarker template to fail.

To fix this, you need to provide a safe fallback for the postMethod variable. Update line 16 in your registration/verify.ftl template from:

[#if verificationId?? && postMethod]

To:

[#if verificationId?? && (postMethod!false)]

The !false syntax provides a default value of false when postMethod is null or missing, preventing the FreeMarker exception.

Steps to apply the fix:

Navigate to Customizations → Themes in the FusionAuth admin UI Edit your theme Locate the registration/verify.ftl template Update the conditional check as shown above Save the theme

This pattern can be applied to other templates where variables might be null or missing in certain execution paths.

Why this happens:

According to the FusionAuth documentation, the postMethod variable is not a standard template-specific variable for the /registration/verify template. It is typically available on other verification templates like /email/verify (where it defaults to true). The registration verify template is rendered when a user clicks the URL from the verification email and the verificationId has expired or is invalid. In these scenarios, postMethod may not be set in the template context, which causes the FreeMarker error when attempting to evaluate it as a boolean.

Related Documentation Theme Template Variables - Verify Registration - Documents the variables available in the registration verify template Theme Template Variables - Email Verification - Shows that postMethod is documented for email verification but not registration verification Theme Template Variables - Complete reference for all template variables across different templates

This is the expected behavior in FusionAuth. During first-time registration, when a user completes the MFA challenge (e.g., entering an email-based code), the Last used field for that MFA method is not populated immediately. It remains null after the initial registration flow.

The Last used timestamp is only set on subsequent authentications after the user has been registered. Once the user logs out and logs back in (triggering a new authentication flow), the MFA method's Last used field will populate correctly with a timestamp.

Important clarification:
Even though Last used shows null after registration, the user is still required to complete the MFA challenge during the registration process. The null value does not indicate that MFA was bypassed — it simply means the "Last used" tracking starts from the second authentication onward, not the registration itself.

Regarding registration abuse:
If you're experiencing self-service registration abuse, the null Last used field is not the cause. Consider these mitigation strategies:

Identity Pre-Verification (available since v1.62.0): Use the Identity Pre-Verification Using Email Verification Form feature to require email verification before completing registration.

Third-party identity verification: Implement a self-service registration lambda that calls an external identity verification service via REST API before allowing user creation. Fideo is a documented example, but any identity verification system with a REST API can be integrated.

Rate limiting and CAPTCHA: Consider additional anti-abuse measures at the application level to prevent automated registration spam.

The user.update.complete event intentionally does not fire when the verified flag changes through email verification. This is by design.

Email verification is considered a distinct workflow separate from the general user update process in FusionAuth's event model. As noted in a related GitHub issue, the decision was made to introduce dedicated verification events rather than triggering user.update.complete because email verification "does not occur due to the Update User API, but because of a separate workflow." The user.update.complete event is reserved for changes made through the Update User API, while verification-specific changes trigger their own dedicated events.

Recommended Solution

You should listen to these specific webhook events for verification state changes:

user.email.verified — fires when an email address is verified (available since 1.8.0) user.identity.verified — fires when an identity (email or phone number) is verified (available since 1.59.0) Handling Race Conditions

If you're concerned about race conditions when multiple events fire simultaneously:

Adjust your Kafka partitioning strategy to key on userId — this ensures all events for the same user go to the same partition and are processed in order Use event timestamps in your downstream consumers to deduplicate or order events correctly. Each event includes a createInstant field in the event object that can be used for ordering Design your sync logic to be idempotent so that processing events out of order doesn't cause inconsistent state

The separate user.email.verified and user.identity.verified events provide more granular control over what verification changes you respond to, which is generally more useful than a generic user update event.

Related Documentation User Update Complete Event — documentation for the user.update.complete event User Email Verified Event — documentation for the user.email.verified event User Identity Verified Event — documentation for the user.identity.verified event Kafka Integration — comprehensive guide to FusionAuth's Kafka integration for consuming webhook events Webhook Event Log — review events sent by FusionAuth with timing and result information

Hiya @benjamineroommen ,

I'm not sure what you mean? Are you talking about the JWT generated for a login event?

ok main thing is, is it ok to use header ES256 for jwt created using secp256k1 keys?

https://datatracker.ietf.org/doc/html/rfc8812 says, secp256k1 curve should only be used with ES256k header, but in authfusion even if we give k1 pair keys and then use sign and encode a JWT using EC, it will come as ES256 only, is that okay?

Another doubt is, those jwt (k1 curve keys + ES256) created in authfusion is only able to verify in jose4j with .setRelaxVerificationKeyValidation() //needed if the key is smaller than 256 bits.

Without it we get the error:

JWT processing failed. Additional details: [[17] Unable to process JOSE object (cause: org.jose4j.lang.InvalidKeyException: ES256/SHA256withECDSA expects a key using P-256 but was null):

Description inside setRelaxVerificationKeyValidation :

Bypass the strict checks on the verification key. This might be needed, for example, if the JWT issuer is using 1024-bit RSA keys or HMAC secrets that are too small (smaller than the size of the hash output)

Is it the correct way to validate jwt created using ec in authfusion?

@gokul-mahajan20

Can you add ----BEGIN to the JWKS certs?

We have the exact same issue. If this was solved (hopefully) could you please provide a brief description on the fix?
Thanks!

If you are using email verification, you can check this user state within your own app. (So, don't allow the attacker to access anything until their email address has been verified.)

In version 1.27.0 you can configure a gated login flow when the user is not verified (this is a 'reactor' feature requiring a paid license). This will enforce email verification before we even redirect to your app. You can then also configure FusionAuth to delete users after N number of days if the user has not verified their email address. This can assist with build up of accounts that are not actually in use.

@alessandrojcm,

Sounds good. I have logged a bug report; we should have this one squashed soon!

Thanks,
Josh

Yes. As of 1.27, you can use a verification strategy of FormField. This is configured on the tenant: https://fusionauth.io/docs/v1/tech/apis/tenants/

You then provide the one time code in the oneTimeCode request body parameter. More about this in the email verification docs: https://fusionauth.io/docs/v1/tech/apis/users/#verify-a-users-email

Note that this feature only works with email gating at the current time, which is a reactor feature requiring a paid license.

You are correct. The verified flag exists on the corresponding user and the registration. You could optionally use the "verify registration" templatefor this purpose.

If you then ignored the verified: false flag on the registration in your code, it should not impact you.

Another option would be to listen for the user.registration.create event and then fire off an email on your end, or call the Email Send API to send a pre-made FusionAuth email template as a welcome event: https://fusionauth.io/docs/v1/tech/apis/emails/#send-an-email

You could use the skipVerification parameter (set it to true) on the user or registration create statement, and then the https://fusionauth.io/docs/v1/tech/apis/users#resend-verification-email call with sendVerifyEmail set to false.

This would give you a verificationId you could use with this API call: https://fusionauth.io/docs/v1/tech/apis/users#verify-a-users-email

It looks like the issue was our mail server. We are using Mailgun SMTP service for our mail sending and this offers a tracking feature.

This tracking feature adds a invisible image to the html code in order to get request for stats. If I deactivate this feature, the HTML_IMAGE_ONLY_12 error is gone and the mail are no longer marked as SPAM. We don't have any issues with our other applications because sent emails are bigger in text content.

The JWT (id_token or access_token) will contain the email_verified claim with a value of true or false, so if you wish to limit privilege based upon this state, that would be a good way to do it.