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:

Navigate to: Application > Registration > Form Settings > User Self Service The default self-service form includes a password field, but you can customize it or create a new form under Customizations > Forms. Once enabled, users can access their account management page to update their password. 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.

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

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.

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.

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, it is possible to configure a custom domain for your SAML audience URL using FusionAuth's Custom Domain feature. This setup allows you to map your desired domain, e.g., https://auth.company.com, to your FusionAuth instance, enabling the SAML audience URL to use your custom domain.

Steps to Achieve This:

Set Up a Custom Domain: Configure a custom domain in FusionAuth (available for production deployments). Once the custom domain is set up, the SAML audience URL will change to reflect your domain, e.g., https://auth.company.com/samlv2/sp/<id>. Update DNS Records: Point the custom domain (auth.company.com) to FusionAuth Cloud using the provided instructions during setup. Verify SAML Configuration: Ensure the custom domain is reflected in the audience URL and SAML metadata. Update your SAML federation partners with the new audience URL.

Additional Notes:

Issuer Setting: The "Issuer" setting on the tenant configuration only affects JWTs and is unrelated to SAML audience URLs. Custom URL Limitation: You’re correct that the login.fusionauth.io option allows for aliases to the default company.fusionauth.io domain but does not impact SAML audience URLs. Setting up a full custom domain resolves this limitation.