@sergey_smirnov hmmm..Ok can we verify this is 100% not user action? Can you add some logging to your application so we can see what a user is clicking or starting a new session? Then we can compare with the logs in FusionAuth.

@john-0 If you log into account.fusionauth.io and click on Hosting, you should see your instance listed. From there select Custom URL(s) from the Action drop down. If you do not see those options, you may need other permissions.
Screenshot 2025-08-07 at 9.54.42 AM.png

Thanks for your answer. I got it.

@njanaskie You are correct in that magic links are designed to be a one time use. I do not know of any work around for your situation.

It will be interesting to see if others chime in.

Worth re-emphasizing that this voids any warranty you might have from FusionAuth, per the license, exhibit A section 5.1.

You can't get support from FusionAuth if you modify the software.

@mark-robustelli hi Mark! thanks for sharing the link. Yes, I've seen that and in general it should fit. I'm just looking for more details as my use-case is quite specific.

execute a step-up auth flow before a sensitive operation (e.g. transfer of funds), use that specific step-up auth flow to validate and then execute an specific operation (like a step-up ID binding to the operation the user started)

I need a way of validating that a specific step-up auth is bound to a specific operation. I have seen the description of a use case of using trustChallenge and trustToken to validate a FusionAuth change password request. This is kind of what I need to do, but on my API endpoints. I'm wondering if it's possible to validate trustToken using a trustChallenge on my own API.

e.g.
a. call a sensitive request triggering step-up with trustChallenge=1234
b. bind operation with trustChallenge
c. complete step up and receive trustToken
d. validate trustToken using the trustChallenge (this is what I would need to know) and confirm/finalize sensitive operation.

@ezequiel-rebasa If you are just talking about testing, you could just add some data to the Lambda's to see if it works for your needs. This would allow you to test without having to spin up a second Docker instance. If it does work, then you may need to upgrade or figure out if you can use APIs to update the lambdas in the instances with the data you need.

FusionAuth is expecting a timely response. If any part of your code reads the body slowly or delays responding, it might exceed FusionAuth's internal timeout (usually around 5–10 seconds).

@nate Can you successfully Send test email from Tenants -> Select Edit from desired Tenant -> Email in the AdminUI? This will test if your SMTP settings are correct.

@mark-robustelli
Thanks I just did that.
https://github.com/FusionAuth/fusionauth-issues/issues/3113

@mark-robustelli thanks

@pocfused said in Email verification fails in new incognito mode:

https://fusionauth.io/community/forum/topic/1406/link-in-email-verification-not-working-first-time

Glad you were able to solve your issue.

As far as the automatically verify the email part. What settings do you have for Applications -> Your Application -> Registration -> Verification strategy? There is a setting Clickable link. Is that what you are after?

Another thought would simply turning off Verify registrations in the Applications -> Your Application -> Registation tab work for you or do you still want the user to actually have to click on a link? (It would make sense to ensure the user owns the email address.)

You could also do something like provide a custom template and direct them to your application and then automatically verify them using the APIs. Check out this blog post.

Good luck.

Yes. You can use FusionAuth's OpenID Connect Identity Provider.

I did this a few weeks ago, so am writing these instructions from memory.

Prerequisites:

A yahoo account A running FusionAuth instance (localhost is fine)

Steps:

Go to the Yahoo! developer network and create an app. The redirect URI for Yahoo is https://<your instance>/oauth2/callback Save off the provided Client ID (Consumer Key) and Client Secret (Consumer Secret). Then go to FusionAuth and create an OpenID Connect Identity Provider: <your instance>/admin/identity-provider/add/OpenIDConnect Put the Client ID (Consumer Key) and Client Secret (Consumer Secret) into the Client Id and Client secret fields, respectively. Uncheck Discover Endpoints. Manually configure the endpoints: Set the Authorization Endpoint to https://api.login.yahoo.com/oauth2/request_auth Set the Token Endpoint to https://api.login.yahoo.com/oauth2/get_token Set the Userinfo Endpoint to https://api.login.yahoo.com/openid/v1/userinfo Set the Scope to openid email profile and any other scopes you might need. (I was unable to find an authoritative list, but here's info about the mail scopes.) Update the Button text and Button image as needed. Enable it for applications as needed. Save the Identity Provider.

First check out the information you are getting from the docker log. Look at the log from the spin up and search for "kickstart." Was the container able to find the kickstart.json file? (In this case yes.)

If the kickstart file was found, continue searching through the log for a potential error in the running of the kickstart. You might see something like.

fusionauth-1 | 2025-07-02 05:14:05.177 PM ERROR io.fusionauth.api.service.system.kickstart.KickstartRunner - Failed to execute request to [PATCH][/api/user/registration/000000000001] Status [404] fusionauth-1 | Request body: fusionauth-1 | { fusionauth-1 | "registration" : { fusionauth-1 | "applicationId" : "e72dca1d-626c-4f4b-8f36-b7c8c2c0af33" fusionauth-1 | } fusionauth-1 | } fusionauth-1 | 2025-07-02 05:14:05.177 PM ERROR io.fusionauth.api.service.system.kickstart.KickstartRunner - Error response: fusionauth-1 | null

This will let you know there was an error and you need to resolve it. In this specific case, The PATCH request should have been a POST. Once that was changed, the kickstart ran fine.

@jakub-hajto , you may want to check out the Google Reconcile Lambda documentation. I also found this post that may be useful for you.

@mark-robustelli said in Logout with multiple subdomains:

@ext_figuvini after reading your post again, I think I read it differently. The way the SSO logout works is that on logout, FusionAuth calls all the logout urls for each applications. It would seem that you are correct in that creating an application for each subdomain makes sense and would work. (You can create applications through the API so you should be able to automate this.) Can you try this for a few domains and confirm it works?

Your point is correct. Creating a separate application for each subdomain is a reasonable and correct solution.
When a user logs out of the SSO system, FusionAuth will call the logout URLs defined in each configured application in turn. This allows each application to clean up its own session. Pretty good solution

Yes—using FusionAuth access tokens to secure partner-facing APIs is a solid approach. The key is ensuring the tokens contain the right claims to enforce proper authorization for your endpoints.

Separating partners into a different tenant or application can improve security and simplify management. Different tenants fully isolate users and tokens, but would require duplicating application configs. Alternatively, you could keep partners in the same tenant and distinguish them via roles, claims, or separate applications.

If partners are accessing APIs server-to-server, the client credentials grant (Entities in FusionAuth) is the correct choice. Be sure to carefully scope each partner’s access to avoid over-permissioning.

More on these topics:

API Authorization with FusionAuth Tenants Overview JWT Anatomy Authorization Models

Yes—you can safely add a fourth custom URL. The “replace” label appears because the system expects you to submit the entire list of domains each time. To avoid losing any URLs, make sure all four domains—including your existing three—are entered in the form before you submit. Only custom domains omitted from the list will be removed.

More details here:
Updating Custom Domains

Yes! FusionAuth stores MFA details on the user object, and you can search for users with MFA enabled using Elasticsearch queries.

For example, in the Admin UI’s User search, you can run:

_exists_:twoFactor

This returns all users with at least one MFA method configured. You can also perform similar searches via the User Search API to build custom reports. For more details on searchable user fields and Elasticsearch queries, see:

User Fields Reference User Search with Elasticsearch

This is definitely an uncommon scenario, so there’s no out-of-the-box flow documented for it, but here’s one way to handle it:

Create a second Google IdP: FusionAuth supports only one native Google IdP, but you can set up an additional Google connection as a generic OpenID Connect (OIDC) IdP. This second IdP can request the elevated scopes you need for email access. See the OIDC docs here: OpenID Connect IdP in FusionAuth. Trigger reauthentication: When a user opts into the email client feature, redirect them through the second IdP’s OAuth flow to acquire the elevated scopes. This effectively escalates their session without forcing all users through additional authentication unnecessarily.

This approach allows you to avoid reauthentication for users who don’t need the extra scopes while supporting a higher-privilege flow for users who do.