Group Details Private

administrators

  • RE: Adding a 'sign up or login CTA' to your pages for unauthenticated users

    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.

    posted in Q&A
  • Adding a 'sign up or login CTA' to your pages for unauthenticated users

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

    Screenshot 2026-10-03 at 6.37.05 AM.png

    posted in Q&A cta paywall
  • RE: Slack-style multi-tenant login: resolve the tenant, then send (or fake) a passwordless code

    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:
    posted in Q&A
  • Slack-style multi-tenant login: resolve the tenant, then send (or fake) a passwordless code

    We're building a multi-tenant app where each customer is a FusionAuth tenant, similar to how Slack has one "workspace" per customer. We'd like two entry points, like Slack has:

    • A known-tenant URL (acme.ourapp.com) that takes returning users straight to their workspace's login.
    • A generic entry point (ourapp.com/login) where someone just types an email — if it doesn't match any tenant, show "No account found"; if it does, send them a one-time code.

    We'd also like to match Slack's exact behavior on the known-tenant URL: even if the email typed in isn't a member of that workspace, still show the same "enter your code" challenge screen. The "no account" information should only ever reach the person by email, never through the UI — that's what lets someone try a few email addresses if they forget which one they used for a given workspace.

    What's the current best practice for doing this with FusionAuth?

    posted in Q&A slack magic link multi-tenant
  • Seeking product feedback on FusionAuth's logging

    FusionAuth's logging isn't one system, it's three: system/app logs on disk or stdout (monitor docs, troubleshooting), audit logs for admin UI changes via webhooks or the Audit Log API, and event logs for debugging surfaced through webhooks or the Event Log API.

    None of them ship anywhere on their own, so if you want this in Datadog or Splunk, you're polling the API or writing your own ingester (by following doc, but still).

    We're looking for feedback on this.

    What's great about FusionAuth's logging, and what sucks or needs to be improved?

    posted in Announcements
  • RE: Invalid login credentials.

    @anarelynevarez, Thanks for looking us up. While Buckeye Union High School District may use FusionAuth, they own the implementation of FusionAuth. You will have to reach out to them for this kind of assistance.

    posted in Comments & Feedback
  • RE: What are the use cases for the user.data.email field?

    It is useful in a few scenarios.

    • When you have users that share an email address, but are in the same tenant and have distinct accounts. FusionAuth enforces uniqueness on user.email per-tenant.
    • When your users have a username (such as an account number) as a main unique identifier, but need self-service account recovery.
    • When you have duplicate email addresses in a legacy system and are migrating them to FusionAuth, whether they point to the same account or not. You can move the users over and address email updates or account merges later.

    Not all email related functionality is available when using user.data.email, but common workflows like forgot password are.

    posted in Q&A
  • What are the use cases for the user.data.email field?

    I see the user.data.email field is used when it is present and user.email is not present. From the doc:

    This field will be used as the email address if no user.email field is found. This field may be modified by advanced registration forms or the API. Setting this value to another account's email address allows that account to, in some cases, access information about this user.

    What are the use cases for that field?

    posted in Q&A
  • RE: What are FusionAuth entities good for?

    Entities are one of the most flexible parts of FusionAuth and can be used to represent links and/or permissions between domain objects and users.

    Entity types are like classes in an object-oriented programming language, which define the permissions that an entity can have.

    Entities are similar to objects, in that they are an instantiation of an entity type. No behavior though, and no inheritance.

    Entities are connected to users and other entities via grants. You can think of this setting up a directed permission graph that can be traced.

    0 to N permissions are attached to each grant.

    There are three major uses for entities:

    • the client credentials grant (agentic, machine to machine or service account authentication)
    • building limited fine grain authentication (FGA-ish) systems that don't need full ReBAC, but do want to use a permission graph or dynamically add and remove permissions
    • modelling permissions on something you don't log into

    A few notes about entities:

    • you'll want to get familiar with the API or the client libraries; entities are managed in code. Both in creating the graph and reading it from your application.
    • each entity has a data field which can handle arbitrary JSON and is searchable
    • the graph can be cyclic if you make bidirectional grants between entities. Users cannot accept grants, they can only be granted permissions to entities.
    • if you need full ReBAC or ABAC, you want FusionAuth FGA. More functionality, including automatic relationship graph traversal. The downside is you have to sync data and run a separate service.
    posted in Q&A
  • What are FusionAuth entities good for?

    I'm curious about entities. What are they good for?

    posted in Q&A entities