Name: Meet FusionAuth: The Most Customizable Auth Solution on the Market
Uploaded: 2025-02-12T19:16:09.585Z
Duration: 58 min 28 s
Description: Meet FusionAuth: The Most Customizable Auth Solution on the Market

Transcript for "Meet FusionAuth: The Most Customizable Auth Solution on the Market": Good morning, everyone. We're gonna wait a few minutes to make sure that everybody can join and then be, ready to kick things off. My way of intros, my name is Mark Van Hopin, and I'm the chief revenue officer here at FusionAuth. And with me is Zoe Ferrell, and 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 where how we're positioned in the market and, all things FusionAuth will be, will be discussed. So we'll kick things off in just a minute. Right. It looks like the, slides are now visible, and I I might as well kick things off. So thank you for spending the morning with us, briefly today. I wanted to kick things off and just introduce FusionAuth as a whole, our perspective on the market, why we're here, and what we're here to talk about today specifically. So 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. And the crux of that is that it is a very, very lightweight piece of software that can be downloaded and run locally or consumed as a hosted service and hosted by FusionAuth. But the differentiating factor here 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 in history. So if we back up to 2015 and we 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. Right? If you can think back just 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 a pair of jeans today without being prompt to create a profile and create a an identity with that specific vendor. You can't pay your utility bill without logging into an online portal and claiming that account number to be tied with your user identity to make a payment. It's a fascinating evolution that has made the problem more critical and more complicated. So thinking about 2015 itself, the choices were relatively simple and the requirements were quite consistent. This led to the default path and the kind of arise 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 out there 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. So the underlying dependencies of a modern application delivery became way more way more fast paced, way more complicated, way more inherently difficult to keep pace with. It also became ever more critical. As we mentioned earlier, the concept of tracking your users and tracking user identity continually became a a critical thing and 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 we're able to solve for. So given that context change, what are the options to solve it? There really were three. The first category that's really the most famous is multi tenant SaaS. That gives you a a seat in a stadium experience, has the concept of a one size fits all deployment model and architecture and, versioning experience as well as, basically the level of control points around around update cadence and maintenance windows really 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 the operational burden to stay up to date with all of these moving parts and all of the complexities that that has come along with a modern application and modern application expectations as well as users in many different geos. They're 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 actually have significant value and significant 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 sir solves for the experience that they hope to achieve today? Enter FusionAuth. If you think about the the Venn diagram on the left here, 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 CICD pipeline, for example, is the right way to solve this problem. It can be scaled out horizontally. It can be, versioned and managed in the same pace and in the same, model as the rest of your production application. If you have seasonal behavior patterns, if you have very, very spiky traffic, or if you need to solve and store certain customers' data in a specific region or a specific, jurisdiction, we can help you do that because the entire application is dedicated to you. And that level of control is something that's just become critical in 2025, and that's why we think our position as a dedicated offering for every one of our customers that can be consumed in a very SaaS like way is a powerful hybrid model. So 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 and production auth system as well as run it in a in a dev environment, a testing environment, as you would with the rest of your production infrastructure. And 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 also think that 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 like to we think it's really important to kind of list out and think about what that actually means, when you think about a dedicated copy of an auth technology. We think that 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 an airplane, running it in your 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 wanna make sure that you have foundational control over the system, and it's not something that's so burdensome and so, 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 sort of modern approach while giving you foundational control. So at this step, we typically dive into a specific use case with the customer. We want to talk about what who are your users themselves, what is your business, what is the actual pace and delivery and expectation of your developers. But in this case, we're gonna walk through the product, we're gonna open it up to questions, and we can really dive into it from a product and demo perspective. Alright. Thanks, Mark. As Mark said at the beginning, my name is Zoe. I'm a solutions engineer on our team here. My role is to support the technical evaluations of FusionAuth all the way 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 get sent out afterwards to all of you. And as more questions come up, please do add them into the chat, or you can use the Q and A feature. I'll make sure to pause, wanna make sure this is is most relevant to to what you're looking for. Alright, let me go ahead and, share my screen. Here we go. Alright. So I like to start all of my demos with talking really high level with what FusionAuth is and how it integrates, with your application. Mark talked about some of this already, but, it is really unique and really core that, like, FusionAuth is a downloadable piece of software at its core. Right? 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 a deployment standpoint, or you can run it on prem with your other, mission critical software. So lots of options, but whichever option you pick, you have your own dedicated instance, your own dedicated database. And there's a lot of benefits to that. Mark touched on some of them, the data residency, from like a GDPR, data residency compliance perspective, super key. Another one I like to speak to is, like, we're never gonna push an upgrade on you. Right? Because you have your own instance, you get control when you do that upgrade. So kind of common configuration we see, is that folks will have one instance for production, one instance for everything preproduction. And that way you can test a new version in preproduction, make sure that's working as expected before promoting to production, just to make sure that you have, least chance of of impacting your users. And then the final thing, Mark touched on this as well, but, really key from a security perspective, right? You just have less surface area of attack if it's just your instance versus that multitenant SaaS, seat in a stadium approach. Let me see if there are any questions. Awesome. Love the shout outs, to the community and documentation. That's something I was gonna speak to as well, because it is is really wonderful here. Alright. The next thing I like to start my demos with before we really dive into, configurations and that sort of thing, is how your application might integrate with FusionAuth. So kind of the most typical login flow from a user perspective. So imagine that this is your web page here. The user clicks log in. They would be redirected to one of our FusionAuth hosted login pages. Here they would log in. Maybe they're using a passkey or a social login. Maybe they have MFA enabled. They do all their login here. 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 with a JWT. So from a user perspective, right, this feels super seamless. The user doesn't even realize that they've gone to a separate application. You're able to have full customization, of this page, which I'll I'll dig into when we we get get to look at the admin UI. You can customize the domain, and really it should feel completely seamless with your application. But from your perspective as a customer, right, you get the advantage of not having to store, password hashes, any of that, PII information. You don't have to store that. You trust that to FusionAuth, and you also, yeah. So you you kind of get to use all of the features of the hosted login pages as well. So this is kind of the most standard flow that we see folks use, but we're also built API first. So all of the things I'm gonna show you today in our admin UI, you can also do via our APIs, and that goes with, login as well. So you can make use of our APIs as well if you don't wanna redirect folks, to the hosted login pages or have, more nuanced or custom flows. The final thing I'll speak to is we also support SCIM, if you wanna get your users in that way. So lots of flexibility here. And again, these hosted login pages, they can come 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 for where where these, hosted login pages can be served from. Great. Let me just see if there any other questions. Great. Let's continue onwards. So the next stop, on our tour is the admin UI. So this is what the hosted login pages look like, before they've been customized. I'm gonna go ahead and log in. And now we're in the admin UI. This is where you configure all your settings, within FusionAuth. And the first stop on our tour, is going to be customizing the theme. So making our way into customization themes. And from here, you have two approaches that you can take. The first is our advanced theme. So let me show you what that looks like. So this is a preview of one of our advanced themes. Kinda see what that looks like. And then if we go into edit, we can see this is where you have that full control over what the hosted login page looks like. You can add your own CSS. Yeah. Sorry. I didn't mean to, to interrupt, but I did wanna call out. Right when you log in to FusionAuth, the map you see is a map of where users are that are logging into the system, and then you have a typical navigation bar on the left, And you can control all aspects of of the FusionAuth system, but this is a fundamentally API first product. And we'll touch on that a little bit later, but the idea here is that you have a visual and a ClickOps sort of UI experience that we can demo, but all of this is foundationally API first. And that leans into our origins as a developer first organization, something that's been designed to work with, extreme customization. So with that, then you dive into the actual, customization flow that you were starting to. But I I really like to set that expectation for everybody across the board. Yeah. Definitely. This is one way to use it, but, like, probably more common is to use the APIs via something like Terraform or custom scripts to update things. There's there's so much flexibility there with how you, configure this in production. Yep. A great call out. Cool. But much easier for demoing to see, via the the UI components. So let's make our way into, back into the themes. So we're looking at the advanced theme here. If I go into edit, yeah, this is where you have your full control over what your page looks like. So adding your custom CSS, easy to add localization if you need to support different languages. And then these are all of the pages that you get as part of those hosted login pages. And I like to pause here because I think it really speaks to the power of using a tool like FusionAuth. Right? You don't need to build the, passkey flow, the password reset flows. Yeah. This all all comes as part of FusionAuth. But then where you need the customization, it's there when you need it. Right? You can go in, and and customize as needed. So this is one approach for theming. This is our advanced theming. And the other approach you can take, is our simple themes. So let me go into my Fusion on simple theme example, and this is our WYSIWYG style editor. So really quick to get up and rolling with this with a theme, but still a good amount of customization, to make it really feel like, it's part of your web page. Cool. Maybe let's let's go ahead and change the background panel. Maybe you wanted to make it slightly more purple. Alright. So now we've configured our theme either through the advanced approach or the simple approach. And the next step is to figure out how to apply this, within FusionAuth. This is a great opportunity for me to talk a little bit about our object model. So making 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 a logical isolation, via the tenant object. So tenants allow for that logical isolation. Some common use cases we see for this, maybe you, a FusionAuth customer, has sub customers that you're serving. Right? Maybe you are private labeling your pages. So you want to be able to have separate users. So maybe the same human user but have different accounts within those white labeled products. And tenants are are perfect for this because it's full logical isolation. Those different accounts, they're separate user objects, separate usernames and passwords. Yeah, complete logical isolation with that tenant. Another common use case for this, is maybe within that, preproduction environment. I'll see folks have a tenant maybe for staging, for UIT, for dev. Yeah, making use of one instance but having still different, development environments, another common use case. So tenants, kind of top level objects. And then within tenants, we have applications. And applications are the things that you log into. So you can have multiple applications, within your tenant. You can allow folks to single sign on between those applications, things of that nature. And as with most settings in FusionAuth, you have a lot of flexibility of where you apply those settings. So most of them can be applied either at the tenant level and applied to everything in the tenant or they can be applied to a particular application and override the tenant settings. So for theming, we could do either. We could apply it to all all apps in a tenant, or a particular application. But for us, let's let's apply this to one application. We go into an application. And, right now, if I look here, this is what the page looks like for this application. If I go ahead and apply my new theme and refresh, now our theme is applied. So pretty simple to just apply that to whichever applications you need to. Alright. Let me pause and see if there are any questions related to theming, or other things before we we continue on with our tour. Well, I think this this is fantastic so far. I really like the, deployment of a of a theme. One question that I do wanna make sure we cover in future that did pop up is a little more of the authorization elements. Right? Oh, everything from, entities and groups and, all the the role based access control, associations, but I'm sure we'll cover that later. I it was just brought up by one of the attendees. Wanted to make sure we covered it. Got it. Yeah. So because there's that the authentication stuff, which we're more focusing on, and then there's the authorization of, like, roles and groups. We'll touch on that a little bit, but the thing that I find most with the authorization portion is it's super, dependent on your use case. It's one of those things that, like, we want to understand the use case better to be able to direct because there's a lot of tools available. So we'll touch on that a little bit, but best for a kind of one on one digging deeper conversation, the authorization part. Totally agree. But, showcasing the the power and the options available is very helpful, and and we'll make sure that's, something we can dive deeper on if appropriate. Yeah. Definitely. Alright. Cool. Let's continue onwards. One of the other features that folks are often looking for, is social login. Right? The login with Google, login with Facebook, that part of things. So let's see how, how you'd implement this InfusionAuth. Alright. So you can configure these, within settings identity providers. Make our way in here. And we call these identity providers versus social logins because we support more than just the social logins. So, if you take a look here, we have a lot of prebuilt, social login integrations, or we support, any user directory or any other IDP, as long as they support OIDC or SAML. So yeah. For us, let's go ahead and, configure for LinkedIn. So Let's add link login with LinkedIn, to our login page. So I'm making my way in here. This is where you would add your client ID, kind of client secret information that you get from LinkedIn, and then you kick which application you want to turn this turn this on for. So maybe I'll turn this on for my application. And then making my way back here to our login page, you'll see that now it's enabled. So common theme throughout FusionAuth, really simple to just turn on these features, turn on MFA, turn on social logins, or log in with an IBP. But then we know, right, sometimes that default integration isn't sufficient. You need more customization, more control over the integration to to meet your use case. In in answer to a question in the chat, are you charged per identity provider connection? No. Fundamentally, FusionAuth only charge for things that actually relate to the underlying cost of delivery, and connecting to an IDP is completely without cost. So you can connect to as many as you like, and that actually varies dramatically based on the, 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 sort of gorgeous theme that they have built. And then we've seen banks that have no interest in associating with another IDP, but that ability is entirely on you and something that we do not, we do not charge for because we think you you have the ability to make that decision and change without without fees. Mhmm. Yep. Exactly. Very good question. Alright. So, going back into our LinkedIn IDP connection, what I was saying is, right, like sometimes that default just turn it on works, but sometimes you need more control here. And we have a lot of tools for that. So, there's a lot of different settings here you can configure, but I wanna zoom in on this reconcile Lambda, because Lambdas are a really great key for customization within FusionAuth. And what a Lambda is is it's just a little chunk of JavaScript that you're able to put in at different points, to add the customization that you need. So this here is our reconcile Lambda. And what this is for is, configuring how you wanna hook up the object that you get back from your IDP with your user infusion auth. So you get to say, how those fields are are mapped. And I think at this point, we have, I think, 26 Lambdas, and you're able to put in, these little chunks of code at a lot of different places. Actually, let me let me show you what one of these Lambdas looks like so we can make this even more concrete. So this is that LinkedIn reconcile Lambda. As you can see, we're just mapping how we want these fields to be mapped between the LinkedIn user and and the user infusion auth. I also like to point folks to this registration dot data field. This is a free form field where you can put any values that you'd like, whether it be like a single value or a more complex data type. We have something similar for a user object as well, that we'll see a little bit more later. But lots of, ability to store whatever you need on the registration or the user object. And these Lambda's super great. There's a bunch of them, I think, around 26 at this point. Other ones that folks make use of often are our populate Lambda that allows you add, custom claims to your JWT. Also our login Lambda that lets you add some custom, validation before, logging in the user. You can even make HTTP requests from the Lambda if that's something you need. Maybe you need to call out to some external system, for some additional validation. Yeah. Lots of flexibility here. And then the other thing I like to, stop and point to you on this page, is this debug enabled flag. You find this on most of the objects in FusionAuth. It was on the IDP. It's also on these Lambdas. And this allows you to get really detailed event logs for this. So you wouldn't wanna turn it on in production, but if you're maybe running FusionAuth locally, you're just debugging, something's not working, definitely turn on this debug enabled flag and you'll get detailed logs. And this speaks to just one of the reasons why I personally like working at FusionAuth, and that's that FusionAuth was developed to be really developer friendly. We have things like this debug feature, like the customization with the Lambdas or making use of our APIs. We have really great documentation. Just a lot of things that make it smooth, to work with as a developer. Great. I think those are all the things I wanted to talk to, related to Lambda's IDP connections. And, yeah, definitely key that none of this, is is a charge for feature. Yes. We do love docs. Related to what you were saying around making the the lives of the underlying developers, easier, That is a common theme both in how you consume it, how you download this, as well as how, it's hosted. We we really want to bring up the, the fact that, we meet the developers where they are. If this is something they wanna run locally, they can. If there's something they wanna consume, in a hosted model, they can. And we are interactive. Like, the whole point is to talk to you. So if there's if you have questions about this, if you wanna talk through a specific use case, we're here to work with you both in the the community forum as well, as dedicated Slack channels for our paid customers, and that is a common, a common theme. Right? You're you're meeting and discussing with developers that actually speak the language that you're living in production. Yeah. Absolutely. Alright. Let's continue our tour. The next stop that I wanna take us to, is talking about multifactor authentication. So that's a One question one question that just popped up says, how do you version control Lambda code? And also a request that it's a little bit small. If there's any chance we can zoom in a little bit on this, this view. That is a good question. I don't think so. I'm sharing from my full screen, but we'll, yeah, that's a great, just like, information for us to know that this is a little bit small. And you will have that full recording, which I assume a lot easier to zoom in when you have that. Oh, version control Lambda code. That's a great question. I know that a lot of folks make use of, like, storing like, again, make use of our APIs and using things like Terraform to store their code locally so they can add that version control. Yeah. I'm not sure if there are any other tools available in addition to that, but I know that's one thing folks make use of. Alright. Alright. Let's, let's continue on, with our tour. So next stop talking about MFA. And again, back to our kind of object model here. One of the really unique things, that you have with with Fuzhant is you can apply settings at either the tenant or the application level, and this goes with MFA as well. Right? And this is kind of unique. So imagine that you have two applications. One application you want really low friction, maybe it's like a forum post or or something like that. You want really low friction to be able to get into your application. You could disable MFA for that application. But then you have the same users that you also want to log into, something that has a lot more security like a banking app or or something of that nature. You're able to configure these settings like MFA for each of those applications uniquely. So really, really great for for use cases like that, where you need that control. For us today, we're gonna configure MFA at the tenant level. So let me make my way back to our tenants. And again, there's so much more that we can configure here. But for us, we'll just kind of continue on with, multifactor. But when I do demos for, customers, I wanna make sure that I'm tailored more to your solution. So definitely talk to us. I can show you more, what's going on here. But for us, we're just focusing in on on a few key highlights for today. Alright. So for multifactor, you have some options here. So, you can choose which MFA methods you wanna support, authenticator, email, SMS, and then you have full control over what those templates are as well. So what your emails or what your text messages look like. And then, up here is where you get to say, what you want your MFA policy to be. So right now, completely disabled. You can also choose to have it enabled. So if, a user has MFA, they'll be prompted to use it, or we can change it to required, which means that a user has to configure MFA. And then now if I make my way back, and I 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. And then if I don't and if I, already had MFA set up, I would be prompted to put in my verification code here. Other thing related to MFA is, you you don't want to be in the middle of your users setting up their MFA methods. Right? So the way that we support that, is through our, user management pages. So, let me go ahead and turn this off so you don't need to watch me muck muck with a key. And let me go to log in here. And this is our self-service page. Right? So the user can come in here. They can self serve, resetting their password, changing their name, and they can also self serve managing their MFA. So adding new methods and things like that. So another great, use for FusionAuth. You don't have to deal with this, make use of our, user management pages. And then the other thing I like to speak to with MFA, Mark mentioned this as well earlier, but every everything here, that I'm showing is also available via the APIs. Just API first by the start, we just provide these additional UI layers, to make things easier. And one of the great use cases for that is using step up, authentication with MFA. So we often see the use case where folks want to prompt MFA before some kind of changing address or making a purchase, some kind of, more sensitive activity. And so you can use our APIs, call the MFA endpoint, and trigger MFA exactly when you need it in your application. An example of that that that came up in a customer, engagement was actually around, fantasy football and then sports betting. So in fantasy football, it's obviously a free service that has a huge number of end users, and they wanna enable 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 that played fantasy football and then wanted to travel to a different part of the app that touched a regulated behavior like sports betting. And all of a sudden, they needed to verify age, verify location, enforce a stricter, level of of password complexity and password control, and you could create a step up challenge based on the behavior if an app, or if a user went to that part of the application. And that removed friction or kept the friction really low in this massive user population in a free, gamification of tennis football, but then provided the necessary control, and step up request if they interacted with the part of the, regulated behavior. Yeah. Yeah. That's a great call out. I'm gonna pause because I see there's a whole bunch of great questions, in the chat. I like Evan's point around, like, maybe having, like, something running and, like, auto committing to a git repo kind of on your own side of things and then making use of our APIs, to add your Lambda's that way. Yeah. That totally makes sense to me. There's just there's so much flexibility with how you wanna do it because the Lambda code is available via APIs. So wherever you wanna put things, however you are already configuring things, Yeah. There's lots of flexibility there. I also saw a question in here around, having multiple tenants or limited to a specific number. Yeah. Absolutely. You have an unlimited number of tenants and like Mark spoke to earlier, there's no, like, charging based on the number of tenants because you still have your one instance. You have to pay for if you're cloud hosting, you have to pay for the infrastructure for your instance. But within that instance, like, that's not really something that affects us. You can have a thousand tenants, whatever you need for your use case. And beyond that, I think it's also worth calling out that when you have a a paid copy of FusionAuth and you have a license key, you're actually entitled to deploy FusionAuth more than one time. You can deploy it as many times as you need that works for your business. Now we would love to have a discussion with you to make sure that, you're deploying this in a way that's actually solving a business problem and actually adding value, but because we've seen some folks begin to deploy completely dedicated copies of FusionAuth instead of using things like tenants when tenants may solve the problem better. But it's inherently very, very flexible, and we wanna talk about the business outcome you're trying to achieve and then make sure we advise on on how you can, you can achieve that. But we wanna make sure the licensing and the cost model gets out of the way from the best technical solution to solve the problem on behalf of your team. Yeah. That's that's a great call out. Right? Like, when you purchase a FusionAuth license of whatever tier you purchase, you just have that license key, both the production key and the preproduction key, and you can put that wherever you need it. Right? If you need like, you have all of your developers developing locally, with an instance, like, maybe running in Docker, you can just put that preproduction key and they have the full feature access. It's however you need it, wherever you need to put that key. Yep. Goes along with purchasing the license. A great call out. There's one more question, which is attribute based access control. Yeah. That's a great question. I can talk a little bit. Like, I'll I'll zoom back to our kind of object model at the end because we do have, like, roles, groups, permissions, that sort of things. For that more, like, fine grained attribute based access control, we definitely wanna talk about your use case, and look more into, like, exactly what you're thinking, what makes sense to move into fusion off, what makes sense to handle on your own, that that sort of thing. We wanna definitely talk more about that. Great. Thank you. Great. Let us let us continue our tour. We have a couple couple more stops. The next place I wanna take us, is looking at webhooks. This is another, tool that's very very widely used by our customers. So let me make our way into our webhooks. Lots of use cases for webhooks. One of them we often see is wanting to, get live data into an analytics platform, maybe like Datadog. This is also webhooks are great for if you need to sync your data between FusionAuth and another system. So if you need to sync that up, in real time, webhooks excellent for that. Yeah. Let's just take a look at what what you have access to here. So as you can see, whole bunch of different events, that you can listen to. A couple I like to to draw attention to, these really are are quite fine grained. Right? User email update, user email verified, like, really fine grained actions that the the users are taking. To to to, user login suspicious is another one I like to point to. This is using our advanced threat detection feature that comes with our enterprise plan, and this is looking out for things like impossible travel or other suspicious activities, and alerting you when when those happen. So lots of What do you mean by impossible travel, Zoe? A good question. So, this is when we noticed, like, in a time frame that's very close, a user logging in from IP addresses that are in, like, impossibly far apart for it to be the same user. So this might not be like like something malicious. This could be someone using a VPN or something like that, but it it does flag as potentially suspicious. And a lot of folks want things like, like, you wanna be able to notify the user. Like, you'll you'll have you've I'm sure you all have seen this. Right? Like, if if something looks a little suspicious, you get an email letting you know that and and alerting you to that. So if there's anything where it looks like the person is moving farther than they would be able to in the time frame, we wanna let folks know. Yeah. Understood. Thank you. Yeah. Good question. Alright. Other so again, like, you can choose which of these events you're listening to. I know this font is is super small. These are things like, JWT refresh, JWT refresh token revoke, really fine grained events, that you're listening to. You can turn on, for a particular tenant, which of these you care about. And the other lovely thing for webhooks is that you can, test them right in the UI. So, this is an example of the audit log create, event that's sent out. And even if you can't see the full text here, you can see we give you a lot of information. Right? We wanna make sure that you have what you need, to respond to this event, and can test this this right in the UI. Right. I think that's all I wanted to cover high level around webhooks. Just double check, see if there are any questions before you continue on. Alright. Looks good so far. Thank you so much. So this is great. Cool. Onwards. The next, stop on our our whirlwind tour, FusionAuth, is looking at the user management portion. So here, right, in addition to handling all the login using those login methods, pass keys, MFA, all of that portion, user, FusionAuth is also a great user management portal. So, let's just maybe take one example here and, look at what you would do if you're needing to manage something about this user. So maybe you need to lock their account, maybe you want to, revoke one of their MFA methods, Maybe you want to clear out all of their sessions. And then this is that, user data field that I spoke to a little bit earlier when I was talking about Lambdas. This is where you can add, whatever custom attribute information you need. So, this could be just one value, this could be, kind of a more complex data structure, and I've seen up to, like, a thousand of these. Like, they're really like, you can really, flex this for for how you need it. And the other lovely thing about user dot data is as long as you follow, the accepted structure and keep your data types consistent, this is all searchable via Elasticsearch or OpenSearch. So if we go back to our users tab, all of these users are searchable via Elasticsearch or OpenSearch. You can see this query here, and you can filter even down on that user dot data field. Some other kind of use cases for this user dot data field. I've seen folks store, their consents there. So maybe as part of, your login, you need to keep track of, age gating or or things there. I've also seen folks put an external ID in this field for if they're needing to sync up between FusionAuth and an external system. You can store in that external ID on the user in that user dot data field, keeping track of loyalty level or loyalty flags. Lots of options there, for whatever you need to store as part of your user. Alright. Any other questions there around the user management portion? With all this, there's a lot more we could talk about. Like, there's some cool stuff with, for users within the admin UI. You can give them rules to scope the access within this UI of, maybe you want someone to only be able to be a user manager. Like, you don't want them to have, the ability to edit Lambdas or IDP connections. You just want them to be able to edit users. You can totally do that. So able to implement the, like, principles of least privilege and and make sure that 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? Mhmm. Yep. Definitely. You this is also full control over a user. So edit user, change their information, change their password or prompt them to change their password on next login. Yeah. All of that that standard user management stuff as well. Yeah. Great question. Alright. And then, I I wasn't planning to speak too much on logging, but we have all tons of logs here available. So this is the recent logs. We also have full, like, audit logs if you need, first, like, audits or or things there of all of the actions that have been taken in the UI. All of that fully available, in our logs. Yeah. And this is exportable to the logging tool of your, choice. Yeah. Definitely. You can download as, like, a a CSV and, I think it's a zip CSV and yeah. Do do it that way you need. Right. Yeah. Alright. Cool. And then other kind of big topic, stream logs to a platform. I don't think we have the ability to just take the log file and stream it. When I see folks needing that sort of situation, mostly I see them making use of the webhooks, like listening to particular changes for users, that they they care about and getting those into their logging platform that way, like Datadog or, other kind of data visualization or logging platforms. But I yeah. Have to look more into that, exactly exactly what we what we, support for logging, because I'm not entirely sure. Great. And then the next thing I wanted to, make sure we talk about is migration. Right? This is a super common thing that comes up. Right? Thinking about, if I were to go with FusionAuth, for my sign provider, what would migrating to that system look like? And the first thing, we always like to talk to is, checking if you have access to your password hashes. So if you have access to your password hashes, you can import those into FusionAuth. So that means that you can avoid users having to reset their passwords. So first thing to check, are you able to get your password hashes from whatever system you're currently using? And then the next thing you wanna look to, is your if you're able to migrate your refresh tokens, because oftentimes you are able to to migrate that as well, to keep a consistent session for users. So they don't even need to log in again, and make that even more seamless. So once you kind of thought through, what you have access to, for the actual process of migrating users, you have three kind of options for approaches. The first we call, like, the big bang approach. Right? That's migrating all your users at once. So taking all your users, making sure to clean them up as much as possible, and then all at once moving their password hashes and information into fusion auth, and making that one cut over to your new auth system. So that's the first approach. The second approach is kind of a modified version of the big bang approach, that we call segment by segment. And this is great if you have maybe two different applications and you wanna move over those chunks of users in segments. So still moving them all over at once, but just doing that in in little bunches. And then the third option, is a slow rollout approach. So with this, you're making use of a connector, and what this connector does is, the first time that the user is logging in, they're gonna you're the connector is gonna make a call to your old system, make sure that the the passwords match and all is well, and then add that user into FusionAuth. And then subsequent times, when the user logs in, they're gonna just log in with FusionAuth. There's some definitely nuance that we we wanna talk through with these approaches. Things like if you're doing the slow rollout approach, what do you do with that last 10% of users that haven't logged in yet? Thinking through how you wanna approach that. But high level, like, those are your three options. We've seen all of them been work really smoothly and successfully for folks. And we have great, going back to documentation, we have really great migration guides for all three of these options, with some concrete implementations of what this might look like. We also have specific guides for migrating from, the most common other auth providers, that you might wanna look into. Alright. Other questions related to, migration, that that kind of side of things, definitely really key key to think through. Nothing, at this time, I think, but I do wanna just make sure we do have, about twelve minutes left and wanna leave some room for, for q and a if needed. But, so far so good. Yeah. That's kinda what I was thinking as well. I was gonna go back and touch on just briefly, kind of the other things that are here that we we haven't really talked to. So thinking back to our high level object model, we, of course, also have the ability to group users, add roles to those users, configure permissions. That's also available here. We just don't have time to go into that today. We also have a tool called entities, which allows you to do for do, more nuanced organizational modeling. So maybe you're trying to model something, sort of similar to GitHub organizations where the groupings of your users isn't tied to a particular application, but you still want that ability to group them and add permissions and and have that fine grain control, that's what entities, is for. So another another kind of key key core here. Yeah. One question that just popped up was, whether or not we have support for MagicLinks. Yep. Definitely. Magic links or that kind of, like, one time password flow where, even if if you want your users to not ever log in with a password, you want them to just be able to log in with a magic link. Yeah. All all supported. Yep. And would be happy to to go into more more demo individually, yeah, if you you find time with us later. Amazing. Khalil's coming in with all the links. I love it. Khalil's one of my teammates. He's great. Much appreciated. Great. Yeah. I definitely we have about ten minutes left, so I do wanna make sure that we have time for other questions. These are kind of my kind of top hitters I wanted to make sure that we covered, with the goal of of giving you just a taste of what's, possible and available in FusionAuth. My kind of high level way that I think about this is all of those kind of things like magic links, social logins, those sorts of things available really quickly out of the box, but then where you need your customization, it's there as well. Right? The Lambdas, they're being able to call APIs exactly as you need them, all of that available where you need it, when you need it. And that's a lot of the stuff that I end up talking through with folks. One on one is making sure that we have the best approach, for for their particular, off situation. Alright. Other other questions or things, that you would like us to talk to, with these last few minutes before we wrap? Well, we'll wait for some more, questions to be dropped in the chat, but, this is a superb walk through, Zoe. Thank you so much for taking the time to go through it. And I do wanna just underline for everybody that we're ready to talk through your specific use case. Right? We can make a plan with you on how to do this and talk through an infrastructure strategy, talk through, an optimal design strategy, and make sure we're set up for success. And 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 we're here to discuss. Alright. One last question instead of how scalable or performant is FusionAuth? From a hard numbers perspective, and I'll defer to Zoe to speak to this, but we have many, many customers there in many millions of users, and it really comes down to the behavior pattern of of your user set. We have a huge number of absolute user volume that's out there, but, the 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, if it's a full new new account creation or otherwise. We work with a Premier League football club, for example, that streams their games through a proprietary application, and they have scheduled international friendlies. And about five minutes before kickoff, they have a dramatic number of millions of users coming in to often create accounts for the first time to be able to stream their their favorite club. And that is an example of a use case that required a full copy of FusionAuth running in The UK to serve UK customers that needed their data stored within The UK, but also had extreme scale that was scheduled in advance, and had some level of high watermark. And we created a contract structure that worked for them, that worked for us, and was allowed allowed this very unique behavior pattern that had extreme high points in in login per second at these at these prescheduled events. Mhmm. Yeah. I thought that was a great answer, Mark. That that's kind of what I speak to, when I answer this. The other thing I point to is, that we kind of cut our teeth in the gaming industry. That's kind of where we came from, and that is an industry that needs, similar to the Premier League Football Club, like, game is launched and you need to support millions of users all at once. Like, it's really, like, a very sharp spike. And so built in such a way to support that, and happy to talk more about your particular use cases as well. Yeah. Yeah. Built it. Built in such a way that we can handle those sorts of situations. Let's see. Oh, interesting. A question around, just different integrations. So Flutter, Android keep zooming in on me as there's more questions. I love this. Cool. This actually let me let me take us to, the portion of our docs, where we talk about kind of SDKs and other, like, integration tools that we have. We are built, like, with using kind of those standards, OIDC, SAML, those best practices. So just generic whatever off library you're already using. Probably, if you're using those standards, you'll be able to kind of switch it in or out. We also have some dedicated SDKs and client libraries, for different use cases. So I don't know exactly for Flutter. I haven't done too much with Android, but I do know we have an Android SDK. The React SDK is super popular. And then we also have some great example apps as well. So I don't know if we have any for particularly for Flutter. I'd have to look more exactly into to that particular use case, but lots of examples. Our SDK is, Yeah. Other things there to help make the integration portion as smooth as smooth as it can be. Would you mind dropping this link in the chat so people can, click out and look at it? Yeah. Totally. That's a great call, Mark. Especially with the tiny font, easier to just send things. Yep. Also, we definitely support the SSO experience right when you wanna be able to use a single login for multiple applications. Many, many of our customers use that. And, as Zoe mentioned, we kind of grew up in the gaming industry and that's a very common use case as you go from title to title but wanna carry the same credentials from each one. That is a a common model, that, that we we've enabled. Yep. And one of the lovely things of using our hosted login pages, it's this, keep me signed in button here, is what turns on that, SSO style being able to log into one application. And then when you go to another application, you're automatically logged in because FusionAuth is keeping track of that single sign on session for you. It's like a cookie that we're handling and you don't have to worry worry about. Yeah. Yeah. A very good question. So, yeah, supporting that single sign on through our our hosted login pages. Yeah. I see another great question around, migrating from cloud hosting to self hosting. Yeah. Totally. Definitely definitely doable, and it like, much more straightforward because of the situation where you have your own database and we can dump that, and move it as needed. So yeah. And it's one of the really lovely things about FusionAuth is you can start cloud hosting if, like, that seems like it's the best approach now. If maybe you have a customer that signs and you need to keep all everything on premise for whatever security reason they have, yeah. Not not too bad to, like, take all your data, set up a new instance locally. Yeah. Definitely doable. Let's see. I see some follow ups. It's a little hard to follow the chat. One login for multiple apps, migrating. I'm loving these questions. This is this is great. Not account, but user data being shared across apps. I think that is probably something we're gonna have to talk about in more detail because it depends how and what, needs to be accessed and how much information you need to put. Obviously, there's the ability to have all kinds of data in the, custom data field in the JWT itself, but there's some if then, considerations. We'd wanna understand the scenario and clearly. Yeah. That that's my thought too. Yeah. This this feels like definitely and we need to talk more, and I want to to learn more about your particular use case. Now what what the setup is with your apps and what data you're looking to store and, like Mark said, like, there's a lot of flexibility. There's that user dot data field. There's the ability to add custom fields to your Jot, if you need that. There's there's a lot of tools there. It it's just it's figuring out what what what serves your need best. Yeah. Oh, man. So so much chatting about gaming platform. And and Kennedy did notice that we have signed in through Nintendo as well. That was actually, developed for one of our customers that had a need, and we worked them to make it possible. And I believe we're one of the few providers that has the ability to, log in with Nintendo. Yeah. Yeah. That definitely comes from our gaming history roots. But that's that's a feature we felt for for one of our customers. Yep. Cool. Yeah. These are great questions. Loving it. Keep them coming. I'm appreciative of Josh O'Bannon, who, is an iPhone gaming enthusiast, and now I'm just curious about his high score in Candy Crush. Well, 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 if you have further questions, our team is ready to to work with you, and, we look forward to making that happen. So reach out. We'll we'll follow-up with a link and instructions on how to interact with us. But, thank you for spending the morning with us, and hopefully you found this useful. Yeah. Thanks so much, everyone. Yeah. Alright. Have a wonderful day. Cool. Bye, everyone. Let's see.