Hiya @florent-bossuyt ,

Thanks for using FusionAuth.

The upgrade to 1.59.0 added support for phone number as a first class identity. While I don't know for sure, it is possible that impacted lastLoginInstant. I'm not aware of any bug filed.

It's also possible you can find the data previously in the lastLoginInstant in the user.identities[x].lastLoginInstant value, available when you retrieve a user.

Since this is not a known issue, there's no documented procedure for reconciling the data, unfortunately.

Here's one approach, though.

If you have a database backup of the 1.57.0 release, you could stand up a FusionAuth instance pointing to that, and find all the users with a lastLoginInstant that is not null (set A). You'd then run the same query against your prod instance (set B). Then find the folks in set A who are not in set B (call them set C). Set C are the people you need to update.

Unfortunately, you can't update their lastLoginInstant directly. But you can fake a login using the passwordless APIs, which should set it. That is outlined here.

So you'd want to perform that for all the users in set C.

Hope that helps.

As of version 1.59.0, you can create users without passwords.

You can use the linked APIs, and that’s the option most people find first. The step-up flow in the API docs works, but means your app owns the challenge. It has to start it, collect the code, and handle the result. That’s a lot for what is basically “make the user log in again because they are about to do a sensitive thing.”

There’s another way that’s a little different, and it leverages login. Since version 1.60 the authorize endpoint supports the standard OIDC prompt and max_age parameters.

When your app hits a sensitive action, don't call any specific APIs. Instead, it can redirect the user to /oauth2/authorize with prompt=login and/or with a max_age small enough that their existing SSO session doesn’t satisfy it. FusionAuth shows the hosted login page, the user authenticates, and you get a fresh token back. Same code you already wrote for login, with one query parameter added.

Make sure you put the current page/location in the state so you can deliver the customer back to where they were. Here's a video on deep linking.

Using either max_age=0 and prompt=login end up in roughly the same place. I’d use max_age if you want a window like “re-auth if it’s been more than five minutes,” and prompt=login if you want it every time.

A successful redirect doesn’t prove everything. Your app still has to decide whether the token it’s looking at came from a recent authentication.

That’s what the auth_time claim is for. It’s a reserved claim in the JWT body (it moved there in 1.60, and lambdas can’t override it), so your resource server compares it against the clock and rejects beyond your threshold. If it’s too old, send the user back through authorize.

That’s basically the max_age half of RFC 9470, just without FusionAuth issuing the WWW-Authenticate challenge for you. You’d write that 401 yourself.

Caveats:.

• This forces a re-login, not necessarily a stronger one. If the user re-authenticates with a password and nothing else, you’ve proven recency and nothing about strength. If you need the second factor on that re-auth, you need MFA to actually fire. A static policy of Required will do it. On Enterprise, the MFA Requirement Lambda can make the decision per request.
• There’s no acr-style “this was step-up” claim. You get “authenticated at time T,” not “authenticated with a second factor at time T.” If your auditors need the latter, this approach won’t give it to you cleanly, and falling back to the step-up auth API is a better option.
• It’s a full redirect. For a banking-style “confirm this transfer” flow where bouncing the user to another page is a non-starter, the step-up API approach is still right.
• This only works when you are using the hosted login pages, not the Login API.

The short version: if sensitive actions are coarse-grained (“view the billing page,” “change the email address”), the redirect approach might work for you. It’s less code, the hosted pages handle the UI, and you’re not maintaining a custom MFA challenge.

But if you need per-operation binding or proof of which factor was used, look at the step-up API.

I need the user to prove they’re still the user before a sensitive action. Do I really have to wire up the Two-Factor APIs to use step-up MFA auth to do that?

@chatteberg I just saw your post. If you have a paid support plan you can open a ticket. If you do not have a paid support plan, are you still experiencing the issue?

This is going to vary based on your publishing system, but you can use FusionAuth's OIDC prompt=none to see if users have an active SSO session.

If the user has checked remember me and has logged in within the tenant session timeout, the request will succeed, otherwise it will fail.

Step 1: Main Page

This creates the iframe and listens for the result.

On your main page, create the hidden iframe targeting FusionAuth with prompt=none. You also listen for a message event from the iframe to know whether to display or hide the CTA <div>, which needs the id trial-cta:

// 1. Listen for the result sent back from the iframe callback page
window.addEventListener('message', (event) => {
  // Verify the origin matches your application domain for security
  if (event.origin !== window.location.origin) {
    return;
  }

  const ctaDiv = document.getElementById('trial-cta');

  if (event.data && event.data.type === 'SILENT_AUTH_RESPONSE') {
    if (event.data.status === 'authenticated') {
      // User has an active SSO session; keep CTA hidden
      if (ctaDiv) {
        ctaDiv.style.display = 'none';
      }
    } else if (event.data.status === 'login_required') {
      // User is not authenticated; show the trial CTA popup/div
      if (ctaDiv) {
        ctaDiv.style.display = 'block';
      }
    }
  }
});

// 2. Create the hidden iframe to initiate the prompt=none request
const iframe = document.createElement('iframe');
iframe.style.display = 'none';
iframe.src = 'https://<your-fusionauth-instance>/oauth2/authorize?' +
  'client_id=<YOUR_CLIENT_ID>&' +
  'response_type=code&' +
  'redirect_uri=https://<your-app-domain>/silent-callback.html&' +
  'scope=openid&' +
  'prompt=none&' +
  'state=<YOUR_STATE>';

document.body.appendChild(iframe);

Step 2: Callback Page

Configure this page as an authorized redirect URI in your FusionAuth application [Request Parameters].

When FusionAuth redirects back with the authorization code code or error=login_required, this page parses the URL and communicates back to the parent window:

// Parse query parameters from the redirect URI
const params = new URLSearchParams(window.location.search);
const code = params.get('code');
const error = params.get('error');

if (code) {
  // Session exists: notify the parent window
  window.parent.postMessage({
    type: 'SILENT_AUTH_RESPONSE',
    status: 'authenticated',
    code: code
  }, window.location.origin);
} else if (error === 'login_required') {
  // No active session: notify the parent window to show CTA
  window.parent.postMessage({
    type: 'SILENT_AUTH_RESPONSE',
    status: 'login_required'
  }, window.location.origin);
}

Cautions And Additional Considerations

This won't work across all browsers, especially those with privacy features or if your FusionAuth instance isn't on the same root domain as the application. More details here.

Test the scenarios you need to support.

The CTA should include information about how to sign up or log in if the user already has an account.

You may want to add server or client side logic to obfuscate the page contents.

How can I add a CTA to get users to log in to my news site, like this one from vox?

Both entry points, and especially the anti-enumeration behavior on the known-tenant path, are best built by calling FusionAuth's passwordless APIs directly from your own UI rather than relying on the hosted login pages. Here's more on the difference.

Using the API is the only way to get full control over what the UI shows on a failure.

Known-tenant entry (acme.ourapp.com)

• Maintain your own slug/domain → tenantId table (outside FusionAuth), populated when you provision each tenant via the Tenant API. FusionAuth has no built-in hostname-to-tenant mapping. You can learn more in the multi-tenant guide.
• At request time, resolve the subdomain to a tenantId from that table (outside FusionAuth). If nothing matches, show "Workspace not found" — this never touches FusionAuth.
• Build your own "enter your email" screen for this workspace (not FusionAuth's hosted page — you need to control what's shown on failure, which the hosted page won't let you do).
• When the user submits an email, your backend calls /api/passwordless/start with that tenantId + your Universal Application id + the email as loginId. Universal Application docs here.
• Branch on the response, entirely inside your backend:
  • 200, code sent → hang onto the returned code value, respond to your frontend with a generic "we sent you a code" message, and show your own "enter the code" screen.
  • 404, no user found → this is the real signal Slack is hiding. FusionAuth returns a 404 with an empty body when no user matches the tenant. Instead of surfacing that: send your own "no account with this email in this workspace" notice through your own transactional email provider (outside FusionAuth or using the send email API), then respond to your frontend with the exact same "we sent you a code" message. Show the identical "enter the code" screen either way.
• Completing the challenge:
  • Real branch: verify the code the user types via /api/passwordless/login (tenantId + code), which returns tokens; pair this with the Hosted Backend / BFF if it's a SPA. Alternatively, redirect the browser to /oauth2/passwordless/{code}?tenantId=<tenantId>&client_id=<id> and let FusionAuth's hosted page take over the code-entry step. This is the URL FusionAuth's own passwordless email template constructs for the "click to log in" link, so redirecting there yourself just skips the email round-trip.
  • Fake branch: there is no FusionAuth code to hand off, so there's nothing to redirect to on FusionAuth's hosted domain — you have to own the "enter code" screen yourself here. Whatever the user types, respond with the same generic "invalid or expired code" error you'd give a real wrong code; never a distinct message. If you're using the hosted-page redirect for the real branch, don't try to fake that redirect for this branch — just render your own equivalent screen and always reject, rather than attempting a look-alike hosted destination.
  • Pad the fake branch's response time to roughly match a real Start call, so the two paths don't diverge on timing, which would leak the same thing you're hiding in the UI.

Generic entry (ourapp.com/login)

• Call /api/user/search with a global (not tenant-scoped) API key and no tenantId filter, searching by the submitted email. Each matching User record already includes its own tenantId, so this single call tells you every workspace the email belongs to. This pattern (global key, /api/user/search?queryString=<email>, results include per-tenant matches) is answered on the forum. Keep the key server-side only.
  • If you'd rather not run a global-key search on every anonymous request (latency, or wanting the key confined to a webhook receiver instead of a public endpoint), you can maintain your own email → tenantId[] table fed by FusionAuth's user.create / user.update / user.delete webhooks instead. Docs at https://fusionauth.io/docs/extend/events-and-webhooks/. Either is fine — this is a trade-off, not a hard requirement.
• Branch on the result (outside FusionAuth):
  • No match → "No account found," stop there.
  • One match → continue with that tenant.
  • Multiple matches → show a workspace picker, then continue with the chosen one. This is currently functionality you have to build yourself, though there is an open issue.
• Once a tenant is resolved, it's the same steps as section 1 from "build your own enter-email screen" onward — including the fake-challenge branch, if you want the same anti-enumeration behavior here too (Slack's generic "find your workspaces" entry also avoids confirming or denying a match directly, for the same reason).

A few things worth flagging

• FusionAuth users are tenant-scoped records — the same person needs a separate User object per workspace they belong to.
• API key scope matters: the cross-tenant search in section 2 needs a global key; the tenant-specific calls in section 1 can safely use a tenant-scoped key. [Docs](Docs at https://fusionauth.io/docs/apis/api-keys).
• The SSO session cookie isn't tenant-aware across hostnames — FusionAuth doesn't currently support true multi-tenant SSO through the hosted pages, so the user behavior when switching tenants requires another login. Always pass tenantId explicitly on every call.
• Passwordless API reference for the exact Start/Login request and response shapes: