FusionAuth provides replay-resistant authentication mechanisms by adhering to industry standards for the technologies it implements. The level of replay resistance depends on the authentication workflow and specific standards followed.

Key Standards:

OAuth 2.0: FusionAuth adheres to RFC 6749, RFC 8628, and OpenID Connect Core, which include mechanisms to mitigate replay attacks (e.g., nonce and state parameters). Documentation: OAuth 2.0 Authorization Code Grant Example Other Standards:
FusionAuth follows established standards for other authentication protocols, such as: WebAuthn: Provides strong, cryptographic-based authentication resistant to replay attacks. SAMLv2: Uses unique assertions and timestamps to prevent replay. OIDC (OpenID Connect): Includes nonce and other mechanisms to mitigate replay.

Replay Resistance Considerations:

Replay resistance is primarily ensured when these protocols are implemented as defined by their standards. FusionAuth provides the tools and configurations necessary to follow these standards. However, deviations from these standards or implementation flaws outside of FusionAuth’s control (e.g., improper handling of state or nonce values) could introduce vulnerabilities.

The sendSetPasswordEmail functionality currently has a limitation in that it doesn’t allow you to pass custom data for use in the email template through the API. However, you can still achieve personalization by configuring the email template directly in the FusionAuth Admin UI.

Steps to Personalize the Setup Password Email:

Edit the Email Template: Navigate to Customizations > Email Templates > Setup Password in the Admin UI. You can either edit the existing default template or duplicate it to create a new one. Use variables like ${user.firstName!'Unknown User'} or any other user data fields to customize the message. Assign the Template to Your Application: Go to Applications in FusionAuth. Edit your application and assign the appropriate template to the Setup Password field. Consider Custom Message Content: Include static or semi-dynamic content like "You were invited by ABC" in the email template. If you have multiple initiators, you might need to create separate templates for each scenario.

Documentation for Reference:

Email Templates and Replacement Variables FusionAuth Email Templates

While the API does not allow for passing custom fields directly for sendSetPasswordEmail, configuring the templates in the Admin UI should allow you to achieve the desired level of personalization.

Yes, this can be achieved using FusionAuth’s Webhooks. You can trigger a Webhook when the user.registration.verified event occurs and send the necessary data to Google Tag Manager (GTM).

Steps to Set Up:

Create a Webhook in FusionAuth: Navigate to Settings > Webhooks in the FusionAuth Admin UI. Create a new Webhook and configure it to trigger on the user.registration.verified event. Enable the Webhook for Your Tenant: Go to Tenant > Webhooks and enable the Webhook for the desired tenant. Integrate with GTM: While FusionAuth Webhooks send data to external systems, ensure that GTM can ingest Webhook data. From my research, GTM supports Webhook ingestion, but you may need to configure a custom setup within GTM to process the incoming data.

Resources for Reference:

FusionAuth Events and Webhooks User Registration Verified Event

This approach allows you to track account verification events seamlessly.

The 11 Lambdas you see are the default ones included with FusionAuth. To create a JWT Populate Lambda, follow these steps:

Navigate to Settings > Lambda in the FusionAuth Admin UI. Click the green + button in the top right to create a new Lambda. In the "Type" dropdown, select JWT Populate. Configure your Lambda logic as needed.

For additional guidance, you can refer to the JWT Populate Lambda documentation, which includes a helpful video walkthrough of the process.

Here’s how you can approach securing access to your FusionAuth instance:

IP Access Control Lists (ACL):
You can define IP Access Control Lists in FusionAuth by navigating to Settings > IP Access Control in the Admin UI. Click the + icon to create a new ACL list. Add entries for each IP address or range you want to allow or block. Assign these ACLs to specific tenants or API keys as needed. Important Note:
IP ACLs restrict access to endpoints like /oauth2/, /account/, /email/, /password/, /registration/, and other user-accessible pages. However, they do not restrict access to the FusionAuth Admin UI unless the Admin UI is accessed via SSO.
Documentation: IP ACL API Overview Secure the Admin UI:
Since IP ACLs do not directly secure the Admin UI, consider the following options: Use a Trusted Proxy:
Place a trusted proxy at the edge of your network to filter incoming traffic before it reaches FusionAuth. The proxy can enforce IP-based restrictions or other security rules. In FusionAuth, configure your proxy under System > Networking, where you can specify the proxy’s IP address. If a request doesn’t go through the trusted proxy, FusionAuth will deny access.
Documentation: FusionAuth Networking Login Lambda for Additional Validation:
Implement a Login Lambda to validate login attempts further. This Lambda allows you to execute custom code during login, such as checking the origin IP or other request details to block unauthorized attempts.
Documentation: Login Lambdas Recommended Next Steps: Configure IP ACLs for your tenants and API keys to secure application-level access. Implement a trusted proxy to filter admin panel access based on source IP. Use a Login Lambda for additional request-level security, if needed.

By combining these approaches, you can enhance the security of your FusionAuth deployment and mitigate unauthorized access.

@Alex-Patterson No, I've been using 1.50.1 version of FusionAuth (read from the admin panel) all the time. The only thing that changed was provider version. Like I said I can just switch between versions and it will start/stop working immediately, so I assume that version 0.1.106 may add some implicit parameter which changes something.
I just checked it after using docker-compose down -v and docker-compose up (fresh installation) and after running the Terraform the error still persists. What's interesting is that I've checked the diff between 0.1.105 and 0.1.106 on FusionAuth Terraform repo https://github.com/FusionAuth/terraform-provider-fusionauth/compare/v0.1.105...v0.1.106 and it does not seem that anything that could be related was changed there, maybe it is related to Go client or something ?

EDIT:
Ok, I found the culprit, looks like between 0.1.105 and 0.1.106 there is some change that automatically sets this to either false (106) or true (105):

Application -> Scopes -> Provided Scopes
Here there are some default scopes, address, email, phone and profile.

The problem here is that it looks like the Terraform provider currently does not allow to set these variables in schema, so basically we are blocked between older version with unsupported configurations like theme's oauth_consent and newer version which handles these scopes inproperly (we can change it manually, but obviously each deployment will cause the values to reset back to false).

https://github.com/FusionAuth/terraform-provider-fusionauth/issues/277

I hope this will get resolved quickly since right now it is quite a blocker.

@dan Thank you for the prompt response I will give this a try soon.

The suggestions you gave are not very atomic. We have many users with spotty network connections, so we're trying to stick here with 1 API call for registrations.

I hear you. I think we already have some open issues about this, but if you'd like to file an issue outlining your preferred workflow, that'd be great.

@johnathon like you see on the capture i am using the login screen.

@johnathon

One approach would be to append the parameter idp_hint to the login URL to redirect a user to the appropriate IdP login page. Please read the hints section in our documentation for more information.

Another way to disable the password and email login for a user would be to set their password to a random 25-character string. This would make the password essentially impossible to brute force and thus impossible for them to log in via the hosted login page.

@fusionauth007 yo! I filed a Github report on this, check out Trim whitespace from user input on backend (username/emails) #1779

I’ve detailed a workaround we’ve got running in prod 👍

You can't do this with the hosted login pages, but there is an issue to allow/disallow MFA on an application by application basis: https://github.com/FusionAuth/fusionauth-issues/issues/763

Currently, you can't bypass MFA, but you can do an end run around by using the Login API.

You can start multi factor with a code you provide: https://fusionauth.io/docs/v1/tech/apis/two-factor/#start-multi-factor

Then complete the login process with that known code: https://fusionauth.io/docs/v1/tech/apis/login/#complete-multi-factor-authentication .

The short answer is however often you want, but at least once per device.

You basically can set up your refresh token policy to have your refresh tokens live for a very long time (as long as you are comfortable with the security risk; make sure to secure the refresh token carefully). That is controlled in in the application configuration: https://fusionauth.io/docs/v1/tech/core-concepts/applications/#jwt

Then, every time an access token expires, you can mint a new one with the refresh token. Here are the APIs you'd be interested in calling:

https://fusionauth.io/docs/v1/tech/apis/jwt/

With advanced threat detection you can block access to applications via IP ranges (it's touched on briefly here: https://youtu.be/pjGxOXamVfk?t=1209 ).

Advanced threat detection requires an enterprise license. Currently you can't lock a certain user to an IP range, though.

Please feel free to file a feature request with details of this use case if you'd like to see this implemented.

Yes. That’s how it currently works.

We have on the roadmap a more flexible identity system but don't have a current timeline for implementation. Here's the tracking issue: https://github.com/FusionAuth/fusionauth-issues/issues/1

@alessandrojcm,

Sounds good. I have logged a bug report; we should have this one squashed soon!

Thanks,
Josh

Yes, if self service registration is enabled (which is set on an application by application basis) and a user who is already logged in to FusionAuth tries to register for such an application, FusionAuth will automatically register them for the app. It also checks that all required profile information is filled out, which is why adding the required field displays the registration form.

You have a few options to do this. Unfortunately the login page, while very customizable in terms of look and feel via themes, is less customizable in terms of functionality and adding fields. Here are some options:

don't use our hosted login pages, instead build your own login pages (and all the other stuff like reset password, etc) using the Login API. You get total control of the login experience, at the cost of more custom code. check for consent when the application is loaded, after authentication. You could store a consent variable on the user object (in the data field) or use our consent model. Basically, after the user authenticates, take them to an interstitial page unless they have given consent. Put that logic in the application page they first land on. use javascript and customize the theme. Add a consent checkbox to the login form, and set a cookie once the user consented so you don't record the consent multiple times. Make a call via javascript to an API (which you'd have to write) to record when the consent was given.

Another option would be to use advanced registration forms for self registration and create a consent that would be required at sign up. Naturally, this doesn't help if you aren't using self service registration.

Yes, you can disable one or more applications.

This operation can be reversed, and while an application is disabled, login requests to fail with a 400 error for all users.

Navigate to "Applications -> Deactivate (gray button)" to disable/deactivate an application.

To re-enable it from the admin UI, you'll need to 'view inactive', which is the button next to the green '+' sign on the list applications page.

Each user is unique within a tenant by email address. If a user in the same tenant wants to login with Facebook, Google, or LinkedIn, it will be the same User object.