FusionAuth
    • Home
    • Categories
    • Recent
    • Popular
    • Pricing
    • Contact us
    • Docs
    • Login
    1. Home
    2. wesley
    3. Posts
    W
    • Profile
    • Following 0
    • Followers 0
    • Topics 54
    • Posts 108
    • Best 4
    • Controversial 0
    • Groups 1

    Posts made by wesley

    • RE: Can You Create Read-Only Roles in FusionAuth?
      1. Existing Role Limitations in FusionAuth
      • FusionAuth provides predefined Admin UI roles, which are not modifiable.
      • You can review the available roles here:
        FusionAuth Admin UI Roles
      • The default FusionAuth application roles cannot be changed, which means read-only roles are not currently available.
      1. Requesting Read-Only Roles as a Feature
      • FusionAuth does not currently support read-only access roles for applications or tenants.
      • The likely reason for this is that users who need to view application/tenant properties often also need to update them.
      • However, you can submit a feature request to suggest adding read-only roles:
        Submit a Feature Request
      1. Workaround: Implement a Custom Read-Only View

      If immediate read-only access is required, consider:

      • Using the FusionAuth APIs to create a custom dashboard where users can view but not edit data.
      • Relevant APIs for this purpose:
        • Application API
        • Tenant API

      Summary

      • No built-in read-only roles exist for applications or tenants.
      • FusionAuth Admin UI roles are not modifiable.
      • You can request read-only roles as a feature via GitHub.
      • A workaround is to build a custom, API-based read-only view.
      posted in Q&A
      W
      wesley
    • Can You Create Read-Only Roles in FusionAuth?

      We are evaluating the best permissions to assign different individuals in our QA and Production FusionAuth instances.

      From the documentation, it seems that roles for tenants and applications are either create/update or delete, with no built-in read-only roles. Additionally, it appears that we cannot modify the roles for the default FusionAuth application.

      Questions:

      1. Is there a way to introduce read-only roles in FusionAuth?
      2. If not, is there a plan to add this functionality in a future release?
      3. We want to grant some users view-only access without allowing modifications—how can we achieve this?
      posted in Q&A login logins
      W
      wesley
    • RE: Troubleshooting User Linking and Redirect Issues in FusionAuth Azure SAML Integration

      1. User Linking Issues Between SP & IdP-Initiated Logins

      No, this behavior is not expected—you should not need to drop and re-link users every time they switch login methods.

      Troubleshooting Steps:

      1. Are these configured as two separate Identity Providers in FusionAuth?
        • If so, ensure they are both linked to the same FusionAuth user.
        • If they are separate, FusionAuth may be treating them as different authentication sources, causing conflicts.
      2. Is Azure using the same application for both login flows?
        • If different applications are used in Azure, they may be sending different user identifiers to FusionAuth.
      3. Enable Debug Logging in FusionAuth:
        • Go to System > Event Log and enable Debug Mode in the Identity Provider settings.
        • Compare the SAML attributes (claims) being sent in SP vs. IdP-initiated logins.
        • If they differ, you may need to adjust Azure’s claim mappings to ensure consistency.

      2. Ensuring Correct Redirect URL in IdP-Initiated Flow

      Yes, RelayState works in FusionAuth, but there are specific requirements:

      Check Your FusionAuth Version

      • RelayState support was added in FusionAuth 1.41.0+.
      • If you are on an older version, FusionAuth will default to the first redirect URL in the list.

      Correct RelayState Configuration

      1. Ensure the target redirect URL is listed as an "Authorized Redirect URL" in the FusionAuth application settings.
      2. URL-encode the redirect URL before appending it to RelayState.
        • Example: https://example.com/welcome → https%3A%2F%2Fexample.com%2Fwelcome
      3. Append the encoded URL to the ACS URL in Azure.

      Example ACS URL with RelayState:

      https://your-fusionauth-instance/samlv2/acs?RelayState=https%3A%2F%2Fexample.com%2Fwelcome
      
      1. Test by logging in via IdP-initiated flow and checking if FusionAuth respects the RelayState.

      Additional References:

      • SAML Redirects in FusionAuth
      • IdP-Initiated SAML Login

      Summary:

      • User linking issues are likely caused by different SAML claims or separate Identity Provider configurations in FusionAuth. Enable debugging to check for mismatched attributes.
      • RelayState should work in IdP-initiated logins if you are on FusionAuth 1.41.0+, URL-encode the redirect URL, and ensure it is allowed in the application's settings.
      posted in Frequently Asked Questions (FAQ)
      W
      wesley
    • Troubleshooting User Linking and Redirect Issues in FusionAuth Azure SAML Integration

      We are setting up both SP-initiated and IdP-initiated login flows with Microsoft Azure SAML for the same users.

      We configured two ACS URLs in Azure:

      • SP-initiated: samlv2/acs
      • IdP-initiated: samlv2/acs/4e98800a-7123-479f-ace7-92502a9a47dd/39ad6a2d-2559-4b14-9b3e-a611ec4da66a

      This setup works but introduces two critical issues:

      1. User Linking Issues Between SP-Initiated & IdP-Initiated Logins

      • When a user logs in via SP-initiated login, FusionAuth successfully creates a user link.

      However, when the same user attempts to log in via IdP-initiated login, the system fails with an error:

      "This account is already linked to another user. Unable to complete this login request."
      
      • The only way to resolve this is manually deleting the user link, after which the user can log in again via IdP-initiated flow.

      Questions:

      1. Is this behavior expected? Shouldn't FusionAuth allow a user to log in using both flows without requiring link deletion?
      2. Why doesn't FusionAuth automatically retrieve the IdP user ID during IdP-initiated login to match the user correctly?
      3. Is there a configuration option to change this behavior?

      2. Controlling Redirect URLs in IdP-Initiated Logins

      • Our FusionAuth application has multiple OAuth redirect URLs configured.
      • During IdP-initiated login, FusionAuth always selects the first redirect URL from the list, ignoring RelayState from Azure.
      • We attempted to specify a RelayState parameter in the Azure configuration, but FusionAuth does not appear to recognize it.

      Questions:

      1. How can we ensure FusionAuth uses the correct redirect URL during IdP-initiated login?
      2. Does RelayState work in FusionAuth for this purpose, and if so, what is the correct way to configure it?
      posted in Frequently Asked Questions (FAQ) saml
      W
      wesley
    • RE: Fixing Incorrect Magic Link Domain in FusionAuth Emails

      This behavior is due to FusionAuth’s default settings for email templates. The Magic Link URL is template-driven, and by default, it may reference a local development environment unless explicitly configured.

      How to Fix This:

      1. Customize the Magic Link URL in Email Templates

        • FusionAuth allows you to update the email template directly.
        • You may want to use the FusionAuth CLI and version control to manage email templates.
        • Refer to the note in this documentation for details:
          Email Templates & Replacement Variables
      2. Update the Tenant Configuration

        • If you want to avoid changes to the email templates, you can put the link in the tenant object and have your template pull from there. To ensure Magic Links point to the correct domain (auth.example.com), update your tenant’s data object using the Tenant API:
          Update a Tenant API
        • This API allows you to populate the tenant.data object.
        • Then you can use it in your email templates.

      Summary

      • Magic Links use email templates, which may default to localhost:9011.
      • Updating tenant settings allows you to set the correct domain dynamically.
      • Use the Tenant API to configure the Magic Link domain properly.
      posted in Frequently Asked Questions (FAQ)
      W
      wesley
    • Fixing Incorrect Magic Link Domain in FusionAuth Emails

      I’m just starting to work with Magic Links in FusionAuth.

      Our FusionAuth service is hosted at company.fusionauth.io, but the Magic Link being generated contains localhost:9011 as the domain.

      Is there a configuration setting I’m missing?

      posted in Frequently Asked Questions (FAQ) login
      W
      wesley
    • RE: Determining if a User Has Set a Password in FusionAuth

      There is no direct way to determine from the user object whether a password has been set.

      1. Tracking Login Method (But Not Password Status)

      • You can determine how a user logged in by using the authentication_type field in the user.login.success webhook event.
      • This will tell you if they authenticated via Google, Password, or another IdP, but it does not indicate whether a password exists.
      • Webhook Reference: User Login Success Event

      2. Allowing Users to Set or Update a Password

      If you want IdP users to be able to set a password, you can enable the User Self-Service Form in FusionAuth.

      How to Enable Self-Service Password Management:

      1. Navigate to: Application > Registration > Form Settings > User Self Service
      2. The default self-service form includes a password field, but you can customize it or create a new form under Customizations > Forms.
      3. Once enabled, users can access their account management page to update their password.
      4. The Account URL can be found by "Viewing" the FusionAuth Application in the UI.

      FusionAuth Account Management

      Summary

      • FusionAuth does not provide a direct flag to check if a user has a password.
      • You can track login methods via webhooks but not password existence.
      • The best approach is to enable self-service password management, allowing users to set a password themselves.
      posted in Frequently Asked Questions (FAQ)
      W
      wesley
    • Determining if a User Has Set a Password in FusionAuth

      How can we determine whether a user has set a password?

      The passwordLastUpdateInstant field contains a timestamp, but in cases where a user signed in using a Google Identity Provider (IdP), this does not indicate whether they ever set a password.

      Our goal is to allow users who originally authenticated via Google IdP to add a password to their account if they don’t already have one.

      posted in Frequently Asked Questions (FAQ)
      W
      wesley
    • RE: Troubleshooting Empty Results from FusionAuth User Search API

      Your request body looks correct for a basic search by email and should return a result if a user with that exact email address exists in your system.

      1. Ensure You Are Using POST (or Use GET with Query Parameters)

      • The /api/user/search endpoint supports both POST and GET, but they expect different input formats.

      If using GET, you must provide query parameters, such as:

      GET /api/user/search?ids=<user_id>
      

      2. Searching for Partial Matches

      If you want to find all users with a certain email domain, try using a wildcard search:

      {
        "search": {
          "queryString": "*@email.com"
        }
      }
      

      3. Verify API Key Permissions

      If you still get empty results, ensure that:

      • Your API key has sufficient permissions to query user data.
      • The user records exist in the database.

      4. Further Reading on User Search

      For more details on how to construct search queries, refer to:

      • Elasticsearch Search in FusionAuth
      • User Search with Elasticsearch
      posted in Frequently Asked Questions (FAQ)
      W
      wesley
    • Troubleshooting Empty Results from FusionAuth User Search API

      I'm trying to retrieve a list of all users stored in FusionAuth using the /api/user/search endpoint but keep getting empty results.
      To troubleshoot, I tested the request in Postman, sending a POST request to /api/user/search with the following body:

      {
        "search": {
          "queryString": "email@email.com"
        }
      }
      

      However, the response I receive is:

      {
        "expandable": [],
        "total": 0,
        "users": []
      }
      

      Am I doing something wrong? Is there a better guide on how to format and send this request correctly?

      posted in Frequently Asked Questions (FAQ) search
      W
      wesley
    • RE: Constructing a PKCE-Compliant Registration URL in FusionAuth

      Yes, you can manually construct a registration URL that includes PKCE values.

      1. Understanding the Registration URL with PKCE

      The /oauth2/register endpoint works similarly to the /oauth2/authorize endpoint but is used for user registration. Both support PKCE.
      Example URLs:

      • Standard Authorization URL:
      https://your-fusionauth-instance/oauth2/authorize?
      client_id=yourClientId&
      response_type=code&
      redirect_uri=https://yourapp.com/oauth-callback
      
      • Registration URL (Same Structure, Different Endpoint):
      https://your-fusionauth-instance/oauth2/register?
      client_id=yourClientId&
      response_type=code&
      redirect_uri=https://yourapp.com/oauth-callback
      

      Since PKCE is enabled, you must append PKCE parameters:

      • code_challenge (derived from code_verifier)
      • code_challenge_method=S256

      2. Generating PKCE Parameters

      Your application must generate a code_verifier and code_challenge before redirecting to FusionAuth’s registration page.

      Node.js Example:

      const crypto = require('crypto');
      
      function base64URLEncode(str) {
        return str.toString("base64").replace(/\+/g, "-").replace(/\//g, "_").replace(/=/g, "");
      }
      
      function sha256(buffer) {
        return crypto.createHash("sha256").update(buffer).digest();
      }
      
      function generateVerifier() {
        return base64URLEncode(crypto.randomBytes(32));
      }
      
      function generateChallenge(verifier) {
        return base64URLEncode(sha256(verifier));
      }
      
      // Generate PKCE values
      const codeVerifier = generateVerifier();
      const codeChallenge = generateChallenge(codeVerifier);
      
      console.log("Code Verifier:", codeVerifier);
      console.log("Code Challenge:", codeChallenge);
      

      3. Constructing the Registration URL

      Once you have the code challenge, construct the registration URL as follows:

      https://your-fusionauth-instance/oauth2/register?
      client_id=yourClientId&
      response_type=code&
      redirect_uri=https://yourapp.com/oauth-callback&
      code_challenge=yourGeneratedCodeChallenge&
      code_challenge_method=S256
      

      4. Completing the PKCE Flow After Registration

      After the user completes registration, FusionAuth will redirect them to your app with an authorization code.
      Your app must then exchange this code for an access token by sending the code_verifier to /oauth2/token.

      For full details on the PKCE flow, see:

      • Using OAuth and PKCE with FusionAuth

      Summary

      • There’s no auto-generated PKCE registration URL, but you can manually construct one.
      • Generate the PKCE values before redirecting users to /oauth2/register.
      • Complete the PKCE flow by exchanging the authorization code with the code_verifier.
      posted in Frequently Asked Questions (FAQ)
      W
      wesley
    • Constructing a PKCE-Compliant Registration URL in FusionAuth

      We want to add a Sign-Up button on our non-FusionAuth-hosted website that redirects users to the FusionAuth registration page.

      Since we have PKCE (Proof Key for Code Exchange) enabled, we cannot use the standard registration URL provided in the FusionAuth UI, as noted in GitHub Issue #686.

      Questions:

      1. Is there a FusionAuth-generated URL that automatically includes the required PKCE parameters, cookies, and redirects users to the registration page?
      2. If not, how can we correctly construct a PKCE-compliant registration URL?
      posted in Frequently Asked Questions (FAQ) login oauth
      W
      wesley
    • RE: Best Practices for Upgrading FusionAuth to the Latest Version

      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.

      posted in Q&A
      W
      wesley
    • Best Practices for Upgrading FusionAuth to the Latest Version

      We are currently running FusionAuth 1.32.x and noticed that 1.42.x has been released.

      Questions:

      1. What is the recommended upgrade strategy to move to the latest release?
      2. Are there any potential pitfalls, such as database changes or template updates, that we should be aware of before upgrading?
      posted in Q&A
      W
      wesley
    • RE: Managing SPF Records for FusionAuth Password Reset Emails

      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.

      posted in Frequently Asked Questions (FAQ)
      W
      wesley
    • Managing SPF Records for FusionAuth Password Reset Emails

      When sending password reset emails from a FusionAuth email template, is there a way to specify the IP address used for sending?

      We’re seeing some emails land in Spam because the sending IP address changes, making it difficult to properly configure SPF records to allow FusionAuth as a permitted sender.

      posted in Frequently Asked Questions (FAQ)
      W
      wesley
    • RE: Handling Access Token Revocation After Logout in FusionAuth

      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:

      1. 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.
      2. 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
      3. 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.

      posted in Frequently Asked Questions (FAQ)
      W
      wesley
    • Handling Access Token Revocation After Logout in FusionAuth

      It appears that calling the /oauth2/logout endpoint does not invalidate the access token.

      Steps to Reproduce:

      1. Complete the OIDC flow and retrieve an access token.
      2. Validate the token using the /oauth2/introspect and /oauth2/userinfo endpoints.
      3. Call /oauth2/logout, passing the tenant ID and client ID, with the access token included as a cookie or in the Authorization header.
      4. After logout, call the /oauth2/userinfo or /oauth2/introspect endpoints again and observe that the access token still validates.

      Is this expected behavior, and how can we fully revoke an access token on logout?

      posted in Frequently Asked Questions (FAQ)
      W
      wesley