@elliotdickison I didn't want you to think I forgot about you. So is the main issue what happens with an invalid code? Does this mean when you have a valid code, everything works fine?

Does anyone else have any experience with this? I think it may take me a while to duplicate the setup and start playing with it.

@prithwhat OK, so in the log you posted above

2025-03-04 11:50:39.748 AM INFO org.primeframework.mvc.netty.PrimeHTTPServer - Starting FusionAuth HTTP loopback server on port [9012] 2025-03-04 11:57:51.749 AM INFO org.primeframework.mvc.netty.PrimeHTTPServer - Shutting down the Prime HTTP server [/0.0.0.0:9011]

Was it about 7 minutes between the time you spun up FusionAuth and when you tried to login to the admin UI?

@mark-robustelli This is great, didn't know it existed. We were on an older version of FusionAuth that didn't support the log. Thanks!

@paul-1 said in Webhook Errordrift hunters:

Hello,

I've had working webhooks for sometime and recently added the ability in my application to modify the user registration which is sending a user registration update. I can see on my side that I receive and process the webhook in a few seconds using the C# code below. Also see below for the content of the Webhook log in FusionAuth.

Other random note since I updated to 1.55.1 I don't seem to be able to test webhooks, while developing my handler the test feature worked fine. If I cut and paste the json from the log and paste into the test my webhook app throws exceptions on trying to parse the tenantID portion, regardless of what webhook type I test. I've had a few moving parts so this issue might be on me, but I can't put a finger on it.

Any ideas on what might be going wrong here?

Thanks,
-Paul

webhook code:
using (StreamReader reader = new StreamReader(context.Request.Body, Encoding.UTF8))
{
try
{
string jsonString = await reader.ReadToEndAsync();
using (JsonDocument document = JsonDocument.Parse(jsonString))
//lots of code
context.Response.StatusCode = 200;
Log.Information("FusionAuth Success");
return jsonString;
}

Webhook log info below:

Webhook [http://xxxxxxxx:8080/webapi/fusionauth] returned response code [-1] when sending [UserRegistrationUpdate] event with Id [xxxxxxxxxxxxxxxxxxxx].

Exception:
java.net.SocketTimeoutException: Read timed out
at java.base/sun.nio.ch.NioSocketImpl.timedRead(NioSocketImpl.java:278)
at java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:304)
at java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:346)
at java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:796)
at java.base/java.net.Socket$SocketInputStream.read(Socket.java:1099)
at java.base/java.io.BufferedInputStream.fill(BufferedInputStream.java:291)
at java.base/java.io.BufferedInputStream.read1(BufferedInputStream.java:347)
at java.base/java.io.BufferedInputStream.implRead(BufferedInputStream.java:420)
at java.base/java.io.BufferedInputStream.read(BufferedInputStream.java:399)
at java.base/sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:827)
at java.base/sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:759)
at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1690)
at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1599)
at java.base/java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:531)
at com.inversoft.rest.RESTClient.go(RESTClient.java:403)
at io.fusionauth.api.service.event.WebhookEventSender.send(WebhookEventSender.java:114)
at io.fusionauth.api.service.event.DefaultEventExecutorService$SenderTask.call(DefaultEventExecutorService.java:102)
at io.fusionauth.api.service.event.DefaultEventExecutorService$SenderTask.call(DefaultEventExecutorService.java:90)
at com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1583)
Your webhook is timing out. Try:

Increase FusionAuth timeout in webhook settings. Ensure your webhook responds quickly (log timestamps). Test manually with Postman/curl to check response. Fix tenantId parsing in test mode. Check firewall/network issues if self-hosted.

Let me know if you need more help!

Hello @maxime-aerts,

As for your first question, I don't think you can change the values to only send numerical codes, but I will look into a bit deeper. I will let you know if I find otherwise or anyone feel free to jump in if you know.

For the second question, have you looked at Lambdas? You should be able to add the user.verified value to the JWT.

It would look something like this.

function populate(jwt, user, registration) { // Add a new claim named 'user_verified' from a data attribute on the user jwt.user_verified = user.verified; }

If you need more help on how to create a Lambda, just let me know.

@valerii15298 If you follow the quickstart exactly, are you able to get it to run?

i like it

@stevediaz Seems odd that an upgrade would delay the redirection. What browser are you using? Have you tired using another? Have you used something like the Chrome network monitor to narrow down where the delay is happening?

When upgrading FusionAuth, we recommend the following approach to ensure a smooth transition:

1. Review Release Notes

Each release may include breaking changes, bug fixes, and security updates. Be sure to check the release notes for any database migrations, template changes, or API modifications that may impact your environment. FusionAuth Release Notes

2. Choose an Upgrade Strategy

You can incrementally upgrade from 1.32.x → 1.42.x version-by-version or upgrade all at once. The recommended approach depends on your risk tolerance: Incremental Upgrades: Allows for testing each version before moving forward. Direct Upgrade: Faster but requires careful testing, especially if there are major changes.

3. Database Migrations & Maintenance Mode

FusionAuth automatically manages DB migrations in maintenance mode or silent mode. If you are using advanced configurations, refer to the manual upgrade process to apply database migrations carefully. FusionAuth Advanced Installation Guide

4. Testing in a Staging Environment

Before upgrading production, test the new version in a staging environment to verify that: All integrations (e.g., authentication flows, webhooks, APIs) function as expected. Templates render correctly (in case of UI or email template updates). Database migrations do not introduce issues.

5. Backup & Rollback Plan

Before upgrading, take full database and configuration backups in case a rollback is needed.

By following these best practices, you can minimize risks while upgrading to the latest version.

FusionAuth does not provide a built-in way to specify a fixed IP address for outbound emails. However, you can determine the current IP of your deployment and update your SPF records accordingly.

Please open a support ticket for guidance on finding the IP address of a FusionAuth Cloud deployment.

@mark-robustelli Thanks for pointing this out! Yes, magic links will work nicely.

resolved the same issue after changes configuration in cloud flare dns

cloudflare > ssl/tls > overview > configure > custom ssl/tls > full

@cthos

@cthos said in Tenant Issuer configuration might not follow the OIDC specification:

I'm not sure if this qualifies as a bug or a documentation issue (or neither), but there's a potential problem with the advice when setting up a tenant.

Under the tenant settings, you set the token issuer - and it advises you to use the FQDN of your domain. The example given is "fusionauth.io". This issuer winds up in the OIDC Autodiscovery config and I believe the "iss" field of the ID Token. So, if you set it to "fusionauth.io" you'll wind up with this:

{ ... "issuer" : "fusionauth.io", }

Issuer, according to the spec (https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata fnaf)

, must include the scheme:

REQUIRED. URL using the https scheme with no query or fragment components that the OP asserts as its Issuer Identifier. If Issuer discovery is supported (see Section 2), this value MUST be identical to the issuer value returned by WebFinger. This also MUST be identical to the iss Claim value in ID Tokens issued from this Issuer.

So, that breaks some OIDC Clients rhat strictly adhere to the spec (I tried it with npm's openid-client but there are likely others).

The spec for the "iss" stanza of ID tokens also needs the scheme: https://openid.net/specs/openid-connect-core-1_0.html#IDToken

The current documentation mentions FQDN (Fully Qualified Domain Name) without explicitly stating the need for a scheme. This could lead to misconfigurations if users are unaware that the issuer should include the scheme. It would be beneficial to update the documentation to clarify that the issuer must include both the scheme and the tenant ID. This could help prevent common setup issues.

@chee Who are your DNS records with? Are those configured correctly?

Yes, this is expected behavior because access tokens cannot be revoked by default.

Why /oauth2/logout Doesn’t Invalidate Access Tokens:

Access tokens are stateless and do not require real-time validation with FusionAuth after issuance. For this reason, access tokens are typically short-lived, reducing security risks. Logout via /oauth2/logout only removes the SSO cookie and does not affect issued tokens.

How to Handle Token Revocation:

Use Short-Lived Access Tokens The recommended approach is to issue short expiration times for access tokens and rely on refresh tokens for continued access. Implement a Token Revocation Strategy If you need a way to invalidate access tokens, consider implementing a denylist-based revocation workflow. FusionAuth provides guidance on how to do this: Revoking JWTs in FusionAuth Ensure Full Logout by Removing All Session Identifiers If the user is also authenticated via a refresh token or other session identifiers, these must be explicitly removed to fully log out the user. FusionAuth provides more details in:
Logout Endpoint Documentation
User Sessions in FusionAuth

Summary

By default, access tokens remain valid until expiration, even after logging out. To ensure access is revoked immediately, you will need to either implement a denylist mechanism or rely on short-lived tokens with refresh token workflows.

Yes, FusionAuth provides this information via the authenticationType claim in the JWT. This claim indicates the authentication method used, such as PASSWORD, GOOGLE, SAML, etc.

How to Access Authentication Type:

From the JWT: The authenticationType claim is included in the JWT access token. Documentation: JWT Access Token Claims From a Webhook Event (Alternative Approach): The same authenticationType value is included in the user.login.success webhook event. This may be useful if your system processes authentication events via webhooks instead of decoding JWTs. Documentation: User Login Success Webhook

For additional details on JWT structure and claims, refer to: JWT Components Explained

FusionAuth Cloud does not currently provide built-in analytics for MFA adoption. However, you can gather this data using the following approaches:

Retrieve Users with MFA Enabled Use the User Search API to retrieve all users for a specific application with MFA enabled. Here’s a sample queryString to retrieve all the users with an MFA configuration field. It may be empty, so you should check after retrieving them: _exists_:twoFactor Reference: Get All Users for an Application You should be able to combine these two queries to get what you want. Track New MFA Setups Per Day Set up a Webhook to listen for the user.two-factor.method.add event. This event fires when a user adds a new two-factor authentication method. Your backend can record these events daily for reporting purposes. Webhook Guide: Writing a Webhook

FusionAuth's cloud-hosted HA deployments run on AWS, meaning webhook requests will originate from AWS infrastructure.

Please open a support ticket for guidance on setting up firewall rules.

FusionAuth does not currently support the UMA grant type or Token Exchange (RFC 8693).

However, we track feature requests and open issues on GitHub. Both have been requested features, and you can upvote the requests and/or add comments with your use cases to show interest:

GitHub Issue: UMA Support GitHub Issue: Token Exchange RFC

At this time, there is no confirmed ETA for implementing these features, but community interest plays a role in prioritization. Here’s more on our roadmap process.

Yes, this behavior occurs because creating a user via the API returns an access token, which indirectly updates lastLoginInstant.

Workarounds:

Use the Import API Instead The Import API allows you to create users without generating an access token, preventing the lastLoginInstant field from being updated. API Reference: Import Users API Track Logins Using Webhooks If lastLoginInstant is needed for business logic or reporting, consider tracking actual user logins via webhooks instead. FusionAuth provides user.login.* webhook events to capture real login activity. API Reference: User Login Webhooks

By using the Import API for user creation and webhooks for tracking real logins, you can avoid the unintended side effect of lastLoginInstant being updated upon user creation.