Customizable authentication should let you control how identity works without requiring your team to rebuild password resets, MFA enrollment, federation, session management, and every other piece attackers enjoy testing for you. This webinar walks through FusionAuth’s architecture and product model, including dedicated instances, deployment choices, hosted login pages, tenant-level configuration, APIs, Lambdas, MFA, identity providers, user management, migration, and scaling.
.png)
Good morning, everyone. We're going to wait a few minutes to make sure everybody can join, and then we'll be ready to kick things off.
By way of intros, my name is Mark Van Oppen, and I'm the Chief Revenue Officer here at FusionAuth. With me is Zoe Farrell — she's one of our solution engineers and also a wonderful person. She'll be touring the product with us today, and I'll talk a little bit about how we're positioned in the market. All things FusionAuth will be discussed, and we'll kick things off in just a minute.
It looks like the slides are now visible, so I might as well kick things off. Thank you for spending the morning with us briefly today. I wanted to introduce FusionAuth as a whole — our perspective on the market, why we're here, and what we're here to talk about today specifically.
At a foundational level, what is FusionAuth? FusionAuth is a customer identity and access management platform that is dedicated to your user set and your business use case. The crux of that is that it is a very lightweight piece of software that can be downloaded and run locally or consumed as a hosted service hosted by FusionAuth.
The differentiating factor is that every one of our customers has a dedicated copy of FusionAuth just for them, and we think that is the correct way to solve a customer identity and access management problem in 2025. One of the reasons we think that's the case requires a bit of context and history.
If we back up to 2015 and think about the problem statement around user identity and customer identity management — and frankly user behavior across many different businesses — it's a fundamentally simpler problem. If you can think back as a consumer ten years ago, it was not necessarily ubiquitous that you were prompted to create an account every time you interacted with anything.
You can't buy a pair of jeans today without being prompted to create a profile and establish an identity with that specific vendor. You can't pay your utility bill without logging into an online portal and claiming that account number tied to your user identity to make a payment. It's a fascinating evolution that has made the problem more critical and more complicated.
Thinking about 2015 itself, the choices were relatively simple and the requirements were quite consistent. This led to the default path and the rise of a multi-tenant SaaS set of auth solutions. The problem statement was basically: I have users, I need to give them an option to create a username, create a password, and have a forgot password flow — occasionally some SSO models. But there were not yet very many options for data isolation or data sovereignty laws that required you to store that data in a specific way or specific place. That all came ten years later.
Alongside this change was the evolution of the infrastructure itself. The underlying dependencies of a modern application delivery became way more fast-paced, way more complicated, and way more inherently difficult to keep pace with. It also became ever more critical. The concept of tracking your users and tracking user identity continually became a critical thing — something that you had no option but to solve cleanly and clearly for your users. It also became further and further from most companies' core competencies.
So it's high stakes, not your core competency, and more complicated than the legacy options were able to solve for. Given that context change, what are the options? There really were three.
The first category — and really the most famous — is multi-tenant SaaS. That gives you a "seat in a stadium" experience, with a one-size-fits-all deployment model and architecture, a versioning experience, and control points around update cadence and maintenance windows that have to be applied to everyone at the same time.
The second path is DIY. DIY gives you foundational control — you have absolute control of everything — but you also take on the operational burden to stay up to date with all of these moving parts and all of the complexities that have come along with a modern application. That means modern application expectations as well as users in many different geos, touching many different areas of the world. That is a monumental lift, and something that not many companies want to take in-house if they have a choice.
And then finally, there's a legacy category of customer identity and access management solutions that are very heavyweight, very difficult to run in a local environment as well as a hybrid or hosted environment, and they're really not meant for the pace of change of 2025. But we have to acknowledge that they are an option and do exist.
Now any one of these three options does have significant value and merit. But we think all three of them missed the mark if you were to start from a blank sheet of paper and say, "How do I solve this problem in 2025 in a way that meets my users where they are and solves for the experience they hope to achieve today?" Enter FusionAuth.
If you think about the Venn diagram on the left — the three different options and the value they bring — we think that a dedicated copy of a full-featured CIAM product that can be consumed in a hosted model or run locally, and integrated into a CI/CD pipeline for example, is the right way to solve this problem. It can be scaled out horizontally. It can be versioned and managed at the same pace and in the same model as the rest of your production application.
If you have seasonal behavior patterns, very spiky traffic, or if you need to store certain customers' data in a specific region or jurisdiction, we can help you do that because the entire application is dedicated to you. That level of control is something that's become critical in 2025, and that's why we think our position as a dedicated offering — one that can be consumed in a very SaaS-like way — is a powerful hybrid model.
To summarize, we really believe that auth should be as local as your databases. We want to give the power and customization of this system to your team. The application owners that serve this app to your customers should be able to work in parallel with the primary production auth system as well as run it in a dev environment or testing environment, just as they would with the rest of your production infrastructure. It's the most secure and performant auth that can be delivered, and we think the way to do that is a single-tenant architecture.
We also think it needs to be foundationally transparent. From the get-go, you know exactly what it costs, and you can work with us to match the behavior pattern that your users require. And we think it's not the right thing to take in-house — it's too critical, too high risk, and too far afield from what makes your business move forward and what brings users to interact with you in the first place. So let us be an extension of your team solving this non-optional problem.
Finally, we think it's really important to list out and think about what this actually means when you think about a dedicated copy of an auth technology. We think you deserve auth so modern you can download it. What does that actually entail? Running it locally, developing it in an air-gapped model like on an airplane, running it in your continuous integration delivery pipeline, giving each developer a copy to run locally, fundamentally owning your data, being able to bring your own hashing algorithm, being able to really embed it in an appliance or test it in a way that is deployed within your customer's customer.
We want to make sure that you have foundational control over the system, and that it's not so burdensome and proprietary that it causes inhibitions in how your team can actually move forward. We're here to make that a reality and help you achieve this modern approach while giving you foundational control.
At this step, we typically dive into a specific use case with the customer — talking about who your users are, what your business is, and what the actual pace and delivery and expectations of your developers look like. But in this case, we're going to walk through the product, open it up to questions, and dive into it from a product and demo perspective.
Thanks, Mark. As Mark said, my name is Zoe. I'm a solutions engineer on our team here, and my role is to support the technical evaluations of FusionAuth throughout the evaluation process. My plan for the rest of this session is to take us on a tour of some of the key features of FusionAuth and also answer questions.
I saw we just got a great question from Evan: will this be recorded? Yes, definitely — this will be sent out to all of you afterward. As more questions come up, please add them into the chat or use the Q&A feature. I'll make sure to pause — I want this to be most relevant to what you're looking for.
Let me go ahead and share my screen. I like to start all of my demos with a really high-level look at what FusionAuth is and how it integrates with your application. Mark talked about some of this already, but it really is unique and core that FusionAuth is a downloadable piece of software at its core. You can run it locally, you can host using our cloud hosting — so you can get that high-availability infrastructure without having to manage anything from a deployment standpoint — or you can run it on-prem with your other mission-critical software. Lots of options, but whichever option you pick, you have your own dedicated instance and your own dedicated database.
There are a lot of benefits to that. Mark touched on data residency from a GDPR compliance perspective — that's super key. Another one I like to speak to is that we're never going to push an upgrade on you. Because you have your own instance, you control when you do that upgrade. A common configuration we see is folks having one instance for production and one for everything pre-production, so you can test a new version in pre-production and make sure it's working as expected before promoting to production — giving you the least chance of impacting your users. And the final thing Mark touched on as well: it's really key from a security perspective — you just have less surface area of attack when it's just your instance versus that multi-tenant SaaS "seat in a stadium" approach.
Love the shout-outs to the community and documentation — that's something I was going to speak to as well, because it really is wonderful. The next thing I like to cover before we dive into configurations is how your application might integrate with FusionAuth — the most typical login flow from a user perspective.
Imagine that this is your web page. The user clicks Log In, they're redirected to one of our FusionAuth hosted login pages, where they log in. Maybe they're using a passkey or a social login, maybe they have MFA enabled. They do all their login there. Behind the scenes, there's some back and forth for the OAuth flow — we're built using standards and best practices whenever possible — and eventually the user is redirected back to your application with an access token, a JWT.
From a user perspective, this feels super seamless. The user doesn't even realize they've gone to a separate application. You're able to have full customization of this page, which I'll dig into when we get to the admin UI. You can customize the domain, and it should feel completely seamless with your application. From your perspective as a customer, you get the advantage of not having to store password hashes or any PII information — you trust that to FusionAuth — and you get to use all of the features of the hosted login pages.
This is the most standard flow that we see folks use, but we're also built API-first. All of the things I'm going to show you today in the admin UI, you can also do via our APIs — and that goes for login as well. You can make use of our APIs if you don't want to redirect folks to the hosted login pages or if you have more nuanced or custom flows. We also support SCIM, if you want to get your users in that way.
These hosted login pages can be served from wherever FusionAuth is hosted — maybe you're running it locally via Docker for development, maybe you're using cloud hosting, maybe you're self-hosting. Lots of options there.
The next stop on our tour is the admin UI. This is what the hosted login pages look like before they've been customized. I'm going to go ahead and log in. And now we're in the admin UI — this is where you configure all your settings within FusionAuth. The first stop on our tour is going to be customizing the theme, so let's make our way into Customization > Themes.
From here, you have two approaches. The first is our advanced theme — this is a preview of one of our advanced themes. If we go into Edit, this is where you have full control over what the hosted login page looks like. You can add your own CSS.
Sorry, I didn't mean to interrupt, but I did want to call out: right when you log in to FusionAuth, the map you see is a map of where users are logging into the system, and then you have a typical navigation bar on the left. You can control all aspects of the FusionAuth system, but this is a fundamentally API-first product — we'll touch on that a little bit later. The idea here is that you have a visual, ClickOps-style UI experience that we can demo, but all of this is foundationally API-first. That leans into our origins as a developer-first organization — something that's been designed to work with extreme customization. With that, let's dive into the customization flow Zoe was starting on.
Definitely. This is one way to use it, but probably more common is to use the APIs via something like Terraform or custom scripts to update things. There's so much flexibility in how you configure this in production — but much easier to demo via the UI components.
So we're looking at the advanced theme. In Edit, you have full control over what your page looks like — you can add your custom CSS, and there's easy localization support if you need to support different languages. These are all of the pages that come as part of those hosted login pages. I like to pause here because it really speaks to the power of using a tool like FusionAuth: you don't need to build the passkey flow or the password reset flows — all of this comes as part of FusionAuth. But where you need customization, it's there when you need it.
The other approach is our simple themes. Let me go into my FusionAuth simple theme example — this is our WYSIWYG-style editor. Really quick to get up and running with a theme, but still a good amount of customization to make it feel like part of your web page. Maybe we'll change the background panel to make it slightly more purple.
Now we've configured our theme through either the advanced approach or the simple approach. The next step is figuring out how to apply it within FusionAuth, which is a great opportunity to talk a little bit about our object model. Let me make my way into our tenant documentation.
As I mentioned at the beginning, FusionAuth is fundamentally a single-tenant solution. But within that single tenant — within your dedicated instance — you can have logical isolation via the tenant object. Tenants allow for that logical isolation. Some common use cases: maybe you as a FusionAuth customer have sub-customers you're serving and you want to private-label your pages. You want separate users — maybe the same human user with different accounts within those white-labeled products. Tenants are perfect for this because it's full logical isolation: separate user objects, separate usernames and passwords.
Another common use case is within your pre-production environment — I see folks having a tenant for staging, for UAT, for dev, making use of one instance but still maintaining different development environments. Tenants are kind of your top-level objects. Within tenants, we have applications — the things that you log into. You can have multiple applications within your tenant and allow folks to single sign-on between those applications.
As with most settings in FusionAuth, you have a lot of flexibility around where you apply those settings. Most of them can be applied at the tenant level and apply to everything in the tenant, or they can be applied to a particular application to override the tenant settings. For theming, we could apply it to all apps in a tenant, or to a particular application. Let's apply this to one application. This is what the page looks like now — if I go ahead and apply my new theme and refresh, now our theme is applied. Pretty simple to just apply that to whichever applications you need.
Let me pause and see if there are any questions related to theming or other things before we continue on with our tour.
This is fantastic so far — I really like the deployment of a theme. One question that did pop up, which I want to make sure we cover later, is a bit more on the authorization elements: everything from entities and groups to role-based access control associations. I'm sure we'll cover that later; it was just brought up by one of the attendees and I wanted to make sure we got to it.
There's the authentication stuff, which we're more focused on today, and then there's the authorization side — roles and groups. We'll touch on that a little bit, but the thing I find with the authorization portion is that it's super dependent on your use case. It's one of those things where we want to understand the use case better before directing, because there are a lot of tools available. So we'll touch on it, but it's best suited for a one-on-one, deeper conversation.
Totally agree. But showcasing the power and the options available is very helpful, and we'll make sure that's something we can dive deeper on if appropriate.
Definitely. One of the other features folks are often looking for is social login — the "Login with Google," "Login with Facebook" side of things. Let's see how you'd implement this in FusionAuth.
You can configure these within Settings > Identity Providers. We call these identity providers rather than social logins because we support more than just social logins. We have a lot of pre-built social login integrations, and we support any user directory or other IDP as long as they support OIDC or SAML.
For us today, let's go ahead and configure LinkedIn login. I'm making my way in here — this is where you would add your client ID and client secret information that you get from LinkedIn, and then you pick which application you want to turn this on for. Maybe I'll turn this on for my application. Making my way back to our login page, you'll see that it's now enabled.
A common theme throughout FusionAuth is that it's really simple to just turn on features — turn on MFA, turn on social logins, or log in with an IDP. But sometimes that default integration isn't sufficient. You need more customization and more control over the integration to meet your use case.
In answer to a question in the chat — are you charged per identity provider connection? No. Fundamentally, FusionAuth only charges for things that actually relate to the underlying cost of delivery, and connecting to an IDP is completely without cost. You can connect to as many as you like, and that varies dramatically based on the different types of businesses that use it. We've seen gaming companies, for example, have a whole list of gaming-related IDPs that show on a very customized and gorgeous theme they've built. And then we've seen banks that have no interest in associating with another IDP. That ability is entirely up to you, and it's something we don't charge for because we think you should be able to make that decision and change without fees.
Going back into our LinkedIn IDP connection — sometimes just turning it on works, but sometimes you need more control, and we have a lot of tools for that. I want to zoom in on this reconcile Lambda, because Lambdas are a really great key for customization within FusionAuth.
A Lambda is just a little chunk of JavaScript that you can put in at different points to add the customization you need. This reconcile Lambda is for configuring how you want to map the object you get back from your IDP to your user in FusionAuth — you get to define how those fields are mapped. At this point I think we have around 26 Lambdas, and you can put in these little chunks of code at a lot of different places.
Let me show you what one of these Lambdas looks like. This is that LinkedIn reconcile Lambda — as you can see, we're just mapping how we want the fields mapped between the LinkedIn user and the user in FusionAuth. I also like to point folks to this registration.data field — it's a free-form field where you can put any values you'd like, whether a single value or a more complex data type. We have something similar on the user object as well, which we'll see a little bit more of later.
Other Lambdas folks make use of often include our populate Lambda, which lets you add custom claims to your JWT, and our login Lambda, which lets you add custom validation before logging in the user. You can even make HTTP requests from a Lambda if you need to call out to some external system for additional validation.
The other thing I like to point to on this page is the debug enabled flag. You'll find this on most objects in FusionAuth — on the IDP, on these Lambdas — and it lets you get really detailed event logs. You wouldn't want to turn it on in production, but if you're running FusionAuth locally and debugging something that's not working, definitely turn on this flag and you'll get detailed logs.
This speaks to one of the reasons I personally like working at FusionAuth — it was developed to be really developer-friendly. Things like this debug feature, the customization with Lambdas, the APIs, and really great documentation all make it smooth to work with as a developer. And none of this is a charged feature.
Related to what Zoe was saying around making the lives of developers easier — that is a common theme both in how you consume FusionAuth, how you download it, and how it's hosted. We really want to meet developers where they are. If this is something they want to run locally, they can. If they want to consume it in a hosted model, they can.
And we are interactive — the whole point is to talk to you. If you have questions about this or want to talk through a specific use case, we're here to work with you both in the community forum and in dedicated Slack channels for our paid customers. You're meeting and discussing with developers that actually speak the language you're living in production.
Yeah, absolutely. Let's continue our tour. The next stop is talking about multifactor authentication.
One question just popped up: how do you version control Lambda code? And also a request that the view is a little small — is there any chance we can zoom in?
That's a great question. I'm sharing my full screen, so I can't zoom in further — but that's useful feedback to have, and you will have the full recording, which should be much easier to zoom in on.
On version control for Lambda code: I know a lot of folks make use of our APIs and tools like Terraform to store their Lambda code locally and add version control that way. I'm not sure if there are other tools available in addition to that, but I know that's one approach folks use.
Alright.
Let's continue on with our tour. The next stop is MFA. Going back to our object model — one of the really unique things about FusionAuth is that you can apply settings at either the tenant or the application level, and this applies to MFA as well.
Imagine you have two applications. One you want really low friction — maybe it's a forum and you want users to get in easily. You could disable MFA for that application. But those same users also need to log into something with a lot more security, like a banking app. You can configure MFA settings for each of those applications independently. Really great for use cases where you need that level of control.
For today, we're going to configure MFA at the tenant level. Let me make my way back to our tenants. There's so much more we could configure here, but we're focusing on a few key highlights for today — when I do demos for customers, I tailor them much more to your specific solution. So definitely talk to us and I can show you more of what's going on here.
For multifactor, you choose which MFA methods you want to support — authenticator, email, SMS — and you have full control over what those templates look like: what your emails or text messages say. Up here is where you set your MFA policy. Right now, it's completely disabled. You can also choose to have it enabled — so if a user has MFA configured, they'll be prompted to use it — or you can change it to required, which means the user has to configure MFA.
Now if I make my way back and try to log in to my application, you'll see that since I don't have MFA enabled for this user, I'm prompted to set it up using those available methods. If I had already had MFA set up, I would be prompted to enter my verification code.
The other thing related to MFA is that you don't want to be in the middle of your users' MFA setup for them. The way we support that is through our user management pages. Let me go ahead and turn this off so you don't need to watch me work through a key — and let me go to the login page here. This is our self-service page, where users can come in and self-serve: reset their password, change their name, and manage their MFA methods, including adding new methods. Another great use for FusionAuth — you don't have to deal with this yourself; just make use of our user management pages.
And as Mark mentioned earlier, everything I'm showing is also available via the APIs — API-first from the start, with UI layers added to make things easier. One great use case for that is step-up authentication with MFA. We often see the use case where folks want to prompt MFA before a sensitive action — changing an address, making a purchase, something like that. You can use our APIs, call the MFA endpoint, and trigger MFA exactly when you need it in your application.
An example that came up in a customer engagement was actually around fantasy football and sports betting. In fantasy football, it's a free service with a huge number of end users where they want a really low-friction experience. But that same business also had a sports betting app, and there was a lot of overlap in the identities of the free users playing fantasy football and those wanting to access a part of the app that touched regulated behavior like sports betting. All of a sudden, they needed to verify age, verify location, enforce stricter password complexity and password control. You could create a step-up challenge based on the behavior — if a user navigated to that part of the application — and that kept friction really low for the massive user population in the free fantasy football product, while providing the necessary control and step-up request if they interacted with the regulated portion.
Yeah, that's a great call-out. I'm going to pause because I see there are a bunch of great questions in the chat.
I like Evan's point about storing Lambda code locally — auto-committing to a git repo on your own side and making use of our APIs to push your Lambdas that way. That totally makes sense. There's just so much flexibility with how you want to do it, because the Lambda code is available via APIs. However you're already configuring things, there's flexibility there.
I also saw a question about having multiple tenants or being limited to a specific number. You have an unlimited number of tenants, and as Mark spoke to earlier, there's no charge based on the number of tenants — because you still have your one instance. If you're cloud-hosted, you pay for the infrastructure for your instance, but the number of tenants within that instance isn't something that affects that. You can have a thousand tenants, whatever you need for your use case.
And beyond that, it's also worth calling out that when you have a paid copy of FusionAuth and you have a license key, you're actually entitled to deploy FusionAuth more than once. You can deploy it as many times as you need for your business.
Now we would love to have a discussion with you to make sure you're deploying this in a way that's actually solving a business problem and adding value, because we've seen some folks begin to deploy completely dedicated copies of FusionAuth instead of using tenants when tenants might solve the problem better. But it's inherently very flexible, and we want to talk about the business outcome you're trying to achieve and make sure we advise on how you can achieve that — making sure the licensing and cost model gets out of the way of the best technical solution for your team.
That's a great call-out. When you purchase a FusionAuth license at whatever tier, you just have that license key — both a production key and a pre-production key — and you can put that wherever you need it. If you have all of your developers running an instance locally in Docker, for example, you can put that pre-production key on each instance and they have full feature access. It's however you need it, wherever you need to put that key. Goes right along with purchasing the license.
There's one more question, which is about attribute-based access control.
That's a great question. I can talk a little bit — I'll zoom back to our object model at the end because we do have roles, groups, permissions, that sort of thing. For more fine-grained attribute-based access control, we definitely want to talk about your use case and look more into exactly what you're thinking, what makes sense to move into FusionAuth, and what makes sense to handle on your own. We want to talk more about that.
Great. Thank you.
Let's continue our tour — we have a couple more stops. The next place I want to take us is webhooks. This is another tool that's very widely used by our customers. Let me make our way into our webhooks.
There are lots of use cases for webhooks. One we often see is wanting to get live data into an analytics platform like Datadog. Webhooks are also great for syncing data between FusionAuth and another system in real time.
Let's take a look at what you have access to here. As you can see, there's a whole bunch of different events you can listen to. A couple I like to draw attention to: these are quite fine-grained — user email update, user email verified — really granular actions that users are taking. Another one I like to point to is user.login.suspicious. This is using our advanced threat detection feature that comes with our enterprise plan, and it looks out for things like impossible travel or other suspicious activities and alerts you when those happen.
What do you mean by impossible travel, Zoe?
Good question. This is when we notice, within a very short time frame, a user logging in from IP addresses that are impossibly far apart to have been the same user. This might not be something malicious — it could be someone using a VPN or something like that — but it does flag as potentially suspicious. And a lot of folks want to be able to notify the user when something looks a little off. I'm sure you've all seen this: if something looks a little suspicious, you get an email letting you know. So if it looks like the person is moving farther than they would be able to in that time frame, we flag it.
Other things you can choose to listen to — I know the font is super small here, but these are events like jwt.refresh, jwt.refresh-token.revoke — really fine-grained events you can turn on for a particular tenant. And the other great thing about webhooks is that you can test them right in the UI. This is an example of the audit log create event that gets sent out — we give you a lot of information, and you can test this right in the UI.
That's all I wanted to cover at a high level around webhooks. Let me check if there are any questions before we continue on.
Looks good so far. Thank you so much.
The next stop on our whirlwind tour of FusionAuth is the user management portion. In addition to handling all the login using those login methods — passkeys, MFA, all of that — FusionAuth is also a great user management portal.
Let's take one example and look at what you would do if you need to manage something about a user. Maybe you need to lock their account, revoke one of their MFA methods, or clear out all of their sessions. And this is that user.data field I spoke to earlier when I was talking about Lambdas — this is where you can add whatever custom attribute information you need. This could be a single value or a more complex data structure. I've seen up to around a thousand of these on a user — you can really flex this for how you need it.
The other great thing about user.data is that as long as you follow the accepted structure and keep your data types consistent, this is all searchable via Elasticsearch or OpenSearch. If we go back to our users tab, all of these users are searchable via Elasticsearch or OpenSearch — you can see the query here, and you can filter down on that user.data field.
Some use cases for this field: I've seen folks store consents there — maybe as part of your login you need to keep track of age gating. I've also seen folks put an external ID in this field for syncing up between FusionAuth and an external system. You can also store loyalty level or loyalty flags. Lots of options for whatever you need to store as part of your user.
With all of this, there's a lot more we could talk about. There's some cool stuff with user management in the admin UI — you can give admin users roles to scope their access within the UI. Maybe you want someone to only be a user manager — you don't want them to be able to edit Lambdas or IDP connections, just users. You can totally do that. You can implement the principle of least privilege and make sure folks don't have more access than they need.
One question that just came up was: can I do basic stuff like reset user passwords in this interface?
Yes, definitely. This is full control over a user — edit their information, change their password, or prompt them to change their password on next login. All that standard user management stuff. Great question.
And I wasn't planning to spend too much time on logging, but we have all kinds of logs available here. This is the recent logs view. We also have full audit logs if you need them for audits or compliance — all of the actions that have been taken in the UI. All of that is fully available in our logs.
And this is exportable to the logging tool of your choice.
Yes, definitely. You can download as a CSV — I think it's a zip CSV — and do it however you need.
Right.
And on streaming logs to a platform — I don't think we have the ability to take the log file and stream it directly. When I see folks needing that, mostly I see them making use of webhooks: listening to particular user changes they care about and getting those into their logging platform that way, like Datadog or other data visualization or logging platforms. But I should look into that more specifically — I'm not entirely sure exactly what we support for logging.
The next thing I wanted to make sure we talk about is migration. This is a super common topic. If you were to go with FusionAuth as your auth provider, what would migrating to that system look like?
The first thing we always like to talk about is whether you have access to your password hashes. If you do, you can import those into FusionAuth, which means you can avoid users having to reset their passwords. First thing to check: are you able to get your password hashes from your current system? The next thing is whether you're able to migrate your refresh tokens, because oftentimes you can migrate those as well to keep a consistent session for users — so they don't even need to log in again, making the transition even more seamless.
Once you've thought through what you have access to, there are three approaches for migrating users. The first we call the big bang approach — migrating all your users at once. You take all your users, clean them up as much as possible, move their password hashes and information into FusionAuth all at once, and make that one cutover to your new auth system.
The second approach is a modified version of the big bang that we call segment by segment. This is great if you have maybe two different applications and want to move over chunks of users in segments. You're still moving them all over at once, just doing it in smaller batches.
The third option is a slow rollout approach. With this, you make use of a connector — the first time a user logs in, the connector makes a call to your old system, confirms the passwords match, and then adds that user into FusionAuth. Subsequent logins go directly through FusionAuth. There's some nuance to talk through with this approach — like what you do with that last 10% of users who haven't logged in yet. But at a high level, those are your three options, and we've seen all of them work really smoothly and successfully.
We have great migration guides for all three of these options with some concrete implementations of what they might look like. We also have specific guides for migrating from the most common other auth providers.
Nothing at this time, but I do want to note — we have about twelve minutes left, so let's leave some room for Q&A. But so far so good.
Yeah, that's what I was thinking. Let me go back and just briefly touch on some of the other things we haven't covered. Thinking back to our object model, we of course also have the ability to group users, add roles to those users, and configure permissions. That's all available — we just don't have time to go into it today.
We also have a tool called entities, which allows you to do more nuanced organizational modeling. Maybe you're trying to model something similar to GitHub organizations — where the groupings of your users aren't tied to a particular application, but you still want the ability to group them, add permissions, and have that fine-grained control. That's what entities are for.
One question that just popped up: do we have support for magic links?
Yes, definitely. Magic links — or that one-time password flow where you want users to never log in with a password and just be able to log in with a magic link — all supported. And happy to go into more demo detail individually if you find time with us later.
Khalil's coming in with all the links — I love it. Khalil is one of my teammates; much appreciated.
With about ten minutes left, I want to make sure we have time for other questions. These were kind of my top hits to make sure we covered — the goal being to give you just a taste of what's possible and available in FusionAuth. The way I think about it: things like magic links, social logins, and that sort of thing are available really quickly out of the box. But where you need customization, it's there — the Lambdas, the ability to call APIs exactly as you need them, all of that is available when you need it. A lot of what I end up talking through with folks one-on-one is making sure we have the best approach for their particular auth situation.
Any other questions or things you'd like us to talk to with these last few minutes?
We'll wait for more questions to be dropped in the chat, but this has been a superb walkthrough, Zoe — thank you so much for taking the time to go through it. I do want to underline for everybody that we're ready to talk through your specific use case. We can make a plan with you on infrastructure strategy, optimal design strategy, and make sure we're set up for success. Because all of this is dedicated to each customer, you don't have to compromise for the most common denominator — and that's what we're here to discuss.
One last question: how scalable or performant is FusionAuth? From a hard numbers perspective, we have many customers with many millions of users, and it really comes down to the behavior pattern of your user set. We have a huge absolute user volume across our customers, but the crux of scaling is logins per second or transactions per second — and that goes to many thousands per second. It depends on how heavyweight that login transaction is, whether it's a full new account creation or otherwise.
We work with a Premier League football club, for example, that streams their games through a proprietary application. They have scheduled international friendlies, and about five minutes before kickoff they have a dramatic surge of millions of users coming in — often creating accounts for the first time to be able to stream their favorite club. That's an example of a use case that required a full copy of FusionAuth running in the UK to serve UK customers who needed their data stored within the UK, while also handling extreme scale that was scheduled in advance with a high watermark. We created a contract structure that worked for them and for us — one that accommodated this very unique behavior pattern with extreme peaks in logins per second at these pre-scheduled events.
Yeah, that's kind of what I speak to when I answer this as well. The other thing I point to is that we kind of cut our teeth in the gaming industry — that's where we came from — and gaming is an industry that needs something similar to the Premier League example: a game launches and you need to support millions of users all at once, a very sharp spike. FusionAuth was built in such a way to handle those sorts of situations, and we're happy to talk more about your particular use cases.
A question just came in around different integrations — Flutter, Android. Let me take us to the portion of our docs where we talk about SDKs and other integration tools. We're built using standards like OIDC and SAML and best practices, so whatever auth library you're already using — if it supports those standards — you'll probably be able to swap it in or out pretty easily. We also have some dedicated SDKs and client libraries for different use cases. I don't know exactly about Flutter specifically, but I do know we have an Android SDK, and the React SDK is super popular. We also have some great example apps. I'd have to look more into the Flutter use case specifically, but there are lots of examples and SDKs to help make integration as smooth as possible.
Would you mind dropping this link in the chat so people can click out and look at it?
Yeah, totally — great call, Mark. Especially with the small font, easier to just send things.
Yep. And we definitely support the SSO experience — being able to use a single login for multiple applications. Many of our customers use that, and as Zoe mentioned, we kind of grew up in the gaming industry, where it's a very common use case to go from title to title and carry the same credentials across each one.
And one of the nice things about using our hosted login pages is the "keep me signed in" button — this is what enables that SSO behavior, letting you log into one application and then automatically be logged into another because FusionAuth is keeping track of that single sign-on session for you. It's like a cookie that we're handling — you don't have to worry about it.
I see another great question about migrating from cloud hosting to self-hosting. Yes, that's definitely doable — and it's actually more straightforward because you have your own database, and we can dump that and move it as needed. And it's one of the really nice things about FusionAuth: you can start with cloud hosting if that seems like the best approach now. If you later have a customer that requires everything on-premise for security reasons, it's not too bad to take all your data and set up a new instance locally. Definitely doable.
Let me see — I see some follow-up questions coming in. One login for multiple apps, migrating... I love these questions. This is great. One about user data being shared across apps.
I think that's probably something we're going to have to talk about in more detail, because it depends on what needs to be accessed and how much information you need to share. There's the ability to have all kinds of data in the custom data field in the JWT itself, but there are some if-then considerations. We'd want to understand the scenario more clearly.
Yeah, that's my thought too — this definitely feels like a conversation we need to have to learn more about your particular setup: what the apps look like, what data you're looking to store. Like Mark said, there's a lot of flexibility. There's the user.data field, there's the ability to add custom fields to your JWT if you need that. There are a lot of tools — it's just about figuring out what serves your need best.
Oh man, so much chatting about gaming platforms.
And Kennedy did notice that we have Sign In with Nintendo as well. That was actually developed for one of our customers who had that need, and we worked with them to make it possible. I believe we're one of the few providers with the ability to log in with Nintendo.
Yeah, that definitely comes from our gaming roots — it's a feature we built for one of our customers. These are great questions. Keep them coming.
I'm appreciative of Josh O'Bannon, who is an iPhone gaming enthusiast — now I'm just curious about his high score in Candy Crush. I think we're nearing the top of the hour here. I'm really looking forward to speaking with all of you. If you have further questions, our team is ready to work with you, and we look forward to making that happen. Reach out — we'll follow up with a link and instructions on how to get in touch with us. Thank you for spending the morning with us, and hopefully you found this useful.
Yeah, thanks so much, everyone.
Alright. Have a wonderful day.
Cool.
Bye, everyone.
