Podcast / Scale / Episode 3

Managing reader and subscriber access with smart user authentication

Scale Podcast Cover Art. Scale is a podcast for modern digital media and publishing professionals

How has the process of managing user authorisation and management changed for publishers in recent years? And what should publishers be looking for when selecting the right tool for them? Joining us for episode three is our friend Dan Moore from FusionAuth. An expert on all things authorisation, he talks us through his tool, FusionAuth, and how the process of authorising users has developed, changed, and become significantly more intelligent over time.

About Dan Moore

Dan Moore is head of developer relations for FusionAuth, and currently helps educate developers about auth and OAuth. He’s written, contributed to, or edited 5 books. Dan loves helping folks solve business problems using identity standards and solutions. A former CTO, technical trainer, engineering manager and longtime developer, Dan has been writing software for (checks watch) over 20 years.

Show Notes

How has the process of managing user authorisation and management changed for publishers in recent years? And what should publishers be looking for when selecting the right tool for them? Joining us for episode three is our friend Dan Moore from FusionAuth. An expert on all things authorisation, he talks us through his tool, FusionAuth, and how the process of authorising users has developed, changed, and become significantly more intelligent over time.


[00:00:05] Stewart: Hi there and welcome to Scale a podcast for Modern Media. I am your host, Stewart Ritchie, the founder and lead developer at Powered by Coffee. Powered by Coffee is a web and software development team focusing on technology issues facing the media today. Scale is a podcast about how technology impacts the media and how the media impacts technology in return, everything from ad tech and privacy to hosting and content management.

We’re interested in what’s happening today, what’s happening tomorrow, and where we might end up in the future.

[00:00:36] Stewart: Welcome to episode three. Today’s guest is Dan Moore , head of developer relations at Fusion Auth. A platform we use at work fairly frequently. If you’ve not heard of Fusion Auth, it’s effectively an API.

For managing user accounts. We kind of take the view that you don’t build your own credit card payments, so why should you build your own identity management? It’s a really enjoyable episode, and Dan gives us some good insight into how to structure these things, why it’s useful, we think you’ll, you really enjoy.

[00:01:09] Stewart: With me today, I have a really cool guest. Dan from, Fusion Auth. Dan is the head of Developer relations.

Fusion Auth is a web skill, identity, management platform that we have used, on a couple of projects and we really like it and all. So thank you very much, Dan for for agreeing to be on with us today to talk about identity, with Fusion Health in particular and kinda other identity scale platforms and how, how that impacts with.

With media, so I just wanna like get ahead of something as well. So increasingly we’re noticing, media brands talking about identity, meaning two things. So the identity that me and you kind are dealing with today, like this user is logging in to this platform and here’s who they are, kind of what they have access to.

And more in a data sense, like how are we identifying this user and fingerprints. So just to get ahead of that, today we’re talking about the old school identity and how we, how that could be useful for, for publishers.

[00:02:11] Dan: So, so sorry Stewart can I peel that back a little bit? That’s a really interesting thing.

So you’re saying you have identity, old school sense where people kinda raise their hand and choose to like create an account and log in and have all the things that come with that. And then you’re talking about identification of, of anonymous folks and kind of knowing, kinda de- anonymizing them. Is that, is that what you mean by that identity or more like kind of just having it aggregate data so you have some idea who’s reading your, your website or your magazine.

[00:02:45] Stewart: It’s, it’s kind of all of those. So it’s looking at who is who effectively, and eventually, you know, that starts as an anonymous profile, but it might be for your fingerprinting people to be like, Okay, this user is this user, and even if they’ve cleared their browser history and got rid of their cookies, we can still have a good idea of who they are.

Not really from a functionality perspective and like a web app site, but more from an advertising and marketing perspective, which is why it comes up more and more because people are now, where you would’ve had a first or third party cookie you could’ve relied upon. Obviously in Europe there’s been a lot of changes with, you know, GDPR over the last few years.

Kinda the expansion of that changes in how Google is handling identity, and also particular rules in the United States. I know there’s a lot of rules in California about like user protection, your privacy. So we’re seeing the, the word identity kinda get polluted a little bit, so we might need to just be clear about it, but it’s, it’s such an interesting space because one eventually leads into the other where ideally you have that kinda data profile that you’ve built up from anonymous users to turn into, Oh, here’s some info on this person that we know who they are and we can action that data somehow.

Just wanted to head it up. Yeah. You wanna give us an introduction to yourself, Dan, cuz you can tell us more about you than I ever could.

[00:04:06] Dan: Sure, sure. Yeah. So again, thanks so much for having me on. I am head of DevRel at a company called Fusion Auth that Stewart mentioned. We are an authentication, authorization and user management provider similar to O zero or Okta or AWS Cognito, if you’re in that space.

And I’ve been a developer for about two decades. Played a lot of different roles. Been a contractor, cto, engineering manager, technical instructor, and a couple years ago I moved into DevRel because I really enjoy educating developers and so developer relations, if your listeners aren’t familiar with it, kinda combines coding and software development with education and marketing.

So for me that was a sweet spot, but yeah.

[00:04:57] Stewart: Cool. And then, you know, fill us in on Fusion off. We’ve given, given a very brief overview on, on what it is, but for those who kind of haven’t maybe heard of this before or it’s never occurred to them that this is a thing that can be run as a service external to whatever they’re building already.

Can you, can you give us some background on, on it and where it came from?

[00:05:17] Dan: So Fusion Auth grew out of another product that and got peeled out when people, when the founders realized that this was actually a real problem. And the problem that it solves is in every application there’s this core bit of functionality that is login, registration, forgot password, other pieces of the journey that are basically the front order, your application.

But aren’t really differentiated. And yet they’re kind of critical because if someone can’t get into your application, then the, the, all the great features behind your application that your application offers aren’t really valuable to the user. And it’s also relatively high risk because it’s pii, because it’s credentials that often stolen.

I don’t know if your users have visited the website haveIbeenponed.com ? But it’s a great website out there that, ano. They collect compromised passwords and they don’t reach out and do it. It’s more like compromise. This happened and then they get collated there and there’s over 11 billion user and password combinations on that website that have been compromised and so, If, if username password is compromised, if my username password is compromised, then that means someone else can act as me, and that may mean reading an article or buying something in my name.

And obviously that’s problematic. So with Fusion Auth and with this kind of whole class of authorization authentication servers, you have something, it’s critical that’s scary to deal with because it’s high risk, but it’s also undifferentiated and it’s pretty common across different applications. Is a very good candidate for something that can be outsourced to, a company or organization or an open source project that focuses on it and Fusion Auth plays in that space.

I think pretty well. Obviously I’m talking my book a little bit when I say that, but of course, I think that the most important thing for users to take away, for your listeners to take away is they shouldn’t be building their own off, and fusion is one option. There are others, and we can talk about.

Some of the others, I’m happy to have that discussion because I wanna educate people to make the right decision. But the wrong decision, and we’ve seen this over and over again, is people choosing to build it themselves. And the way I phrase it, and the way I’d sum it up is very few organizations and companies would build their own database and I think building off servers in the same category of decision, right?

For one 10th to 1% of people it makes sense to do. Everyone else should be looking at an off the shelf.

[00:07:58] Stewart: Great. So I think then that’s you. The words you used was undifferentiated. So just to kind of like give that, I suppose a lot of thought that it’s in effectively every application, you know, every non-trivial application somebody’s going to need to.

Login. Otherwise it’s probably just a blog. And even then a blog has some level of off, because some, unless you’re entirely static and running it off GitHubs or something incredibly too technical like that, someone needs to log in and have privileged access to perform actions. And I suppose it’s one of those things you, it’s not immediate obvious to me that you would outsource this because it is a fundamental part of almost every.

Starting point you would look at to build an application. Mm-hmm. , we’re primarily a WordPress development agency. WordPress has a user system built in, maybe not a very good one, but it has one Laravel. If you go and start doing anything nontrivial, Laravel some of the very first things you’ll do is install there.

 Authentication packages, whether you’re doing with Nova and building out an admin panel, or I’ve forgotten the precise ones, Century and I can’t remember the name of the other package, but it’s very quickly the thing that you do. It’s where you start, To me, until we started working together and it wasn’t obvious, the benefits of kind of, of looking at it, this way, so.

Maybe think about that a little bit. I’ve increasingly moving towards the idea that we don’t build our own payment processors, despite the fact that almost everyone could, like, I don’t wanna build the Stripe API every time we have to do this, and it’s such a critical piece. Now why am I continuing to build this over and over and over again?

 Where. We’re not developers that specialize in building an authentication system. And you know, 5, 10, 15 years ago it was very simple. Like, here’s a username, or actually ideally an email cuz who remembers a username, and a password Sure. Log. But it’s so much more complicated than that I to get, You have to look at things like two-factor.

You have to look at things like hiring places. Is this account logged? Netflix at the moment is going through a lot to do with password sharing of like, okay, great. How are we identifying that these users are logging in from five, six different places? Like off An identification is so much more complicated than people will ever realize.

That’s where I think there’s a lot of value in fusion.

[00:10:29] Dan: Sure, sure. And I mean, I think it, I, I wanna, I wanna be, you know, precise. Like, I think that starting out when you have a single application, WordPress or a letter, a app or something like that, going to that initial builtin user management system is a great start, right?

Again, you’re not building your own, you’re using a, a battle tested library. You say WordPress, authentication may not be the best. I, I think it is great for what it does, and it’s a starting. Where we run into issues or where our customers and users run into issues pretty quickly, which you allude to is, you know, if you create a user table for every different application, you’re running into two issues really quickly. The first is, now you have this PII spread throughout each your applications, and you need to make sure that they’re very secure so that those passwords don’t get stolen. You also need to make sure that that, any new functionality that you want to introduce around authentication is deployed to each individual application. And the other thing that you run into is that. The user account is isolated. And so if you have three applications, well now when you have a new employee or a new user, you have to deploy them to each of those applications. And so at that point, I think if you have one application and it’s kind of the primary one, you’re fine using a built, built-in system.

And again, that’s way better than building your own. But I’ve given talks where I ask how many people have just one application, and very few companies and organizations have just one. Yeah. It’s very common to have, you know, a support system and, and or other custom applications at that point. Having one place where all your use today is.

Really makes a lot more sense. And this is especially true because the standards are actually there, right? This is not a wild west where you have to do custom integrations. O I D C is a standard that’s been around since 2014 and is a great way to basically let every application interface with an off server in a very standardized way.

[00:12:52] Stewart: So you’ve mentioned, , IDC there, what, what is OIDC?

Sure. So OID stands for Open ID Connect, and what it is, is it’s a protocol that basically defines how an application like. You know, WordPress could interact with an off server and I don’t know if we need to dig too deep into the, the nuts and bolts of it.

I think it’s just something you wanna look for in the label, right? Sure. Because that will tell you that there’s a world of documentation, libraries and developers who understand this, you know, I know you all understand this very well, that it’s, it’s basically kinda like USB right? Like it’s a standard and.

Anybody can make a USB cord and I can plug into any other USB outlet. O I D C is maybe not as perfect as usb, but it’s, but it’s far better than rolling your own and trying to do custom integrations across a bunch of different applications.

I think then that’s, I mean, that’s such an important point to head on with this because that moves us beyond, like this is the off, server for this application to, this is an off server that can be talked to by many, many applications.

Regardless of how they were built, because there is a standard in between like a common language that all these tools and endpoints and things talk to make sure that that user, AWS is essentially portable. So if you re-platform your application, say, so you go from word breath to triple or you know, symphony Laravel or whatever you’ve backed up.

You’re not reworking the user authentication system, you’re just reworking how you talk to, to the, the author. Just one more thing while I back as well. You mentioned like, who has one app? I would say no one has one app. You might have one or websites, you know, using those kind of words interchangeably.

You might have one public facing version of that, but there’s almost always a staging version and a test version. They’re all working on separate databases cause they’ve all got slightly separate data. If you’re provisioning users, admin users, editorial users and folk who have, you know, publishing control into those applications, most organizations forget to de deprovision users in those backup ones, and that gives them a point which they can get back in.

You know, it’s not just one app, it’s how many environments does that app live in? How many different places for ing? Are possible. So I would go say no one has one app. You know, there’s lots and lots of instances of every app out.

[00:15:26] Dan: That’s a great point. You know, I mean, I kinda jump immediately to, you have an app and then you have like a customer support system and a forum and other things.

But those environments, and especially controlling access to them with, from controlling privileged users, access to them is, is really important.

[00:15:43] Stewart: Yeah. And that’s, that’s a thing that can vary organization wise. We’ve seen orgs that, you know, all their publishing happens in their production environment, which is fine if that’s how they wanna work.

We’ve seen other ones. Spin up a new environment for each edition that goes out, and then they swap those over so they’re continually provisioning new users into this new environment. But are they getting deprovisioned when those users leave or on the way out? That’s the, that’s the big question.

[00:16:09] Dan: Do those environments continue to live on like as long as that edition is live and other people are looking at it, or do they get cycled?

[00:16:17] Stewart: They can get cycled off. They can get reworked. So what you might do is have an off one that is being worked on and then you point all your live traffic at it. Whenever the addition swaps over and then the one that you know was previously live, you pull all the new content over and then that’s where the editors work to bring it up to until the next publish goes over.

Cause it’s easier to swap those, Sorry, very technical. Easier to swap those seniors over. And kind of like have a potential reverse proxy or some other system where it’s like, okay, we don’t wanna mess with database. We just want to have it and then point all the traffic at the new place. And then you’ve got kinda two banks that you’re going backwards and forwards between.

[00:16:59] Dan: I mean, I think that does point out something that is interesting to me is you want to automate it as much. This is possible and the user you. I, I focus on user stuff, right? But the user stuff is just part of the piece. And so you wanna make sure that whatever environment you’re building, you don’t have to have some checklist that a fallible human being like myself has to run through to, to devision when an editor leaves or gets promoted or whatnot.

Like you want a single user store, and frankly, you probably want. Source the record for every piece, right? Like not just for users, but for articles and other pieces of data.

[00:17:40] Stewart: Yep, absolutely. think then that’s one of the more interesting things I think about as well, is that it doesn’t just have to kind of work with its own user database.

It can be backed by user sources from other places. So, I mean, we’re kind of talking about like what happens in a corporate world here. So it’s not unfeasible for that to term be connected to like an active directory where a user is being provisioned in using Fusion off or another identity system to say, Okay, this user has access to all these things and they have these permissions, and then that system is in turn controlling fusion off to get all those users in.

And I, that’s, that’s, that’s powerful opinion of itself.

[00:18:19] Dan: Right. So that’s the magic of, your users may not be familiar with this term, but it’s called Identity Federation. So the idea is that you don’t have to own like Fusion Auth itself doesn’t have to be the system of record. It can be, like an interface that defers to other people.

And for enterprises it can be systems like l d or Active Directory or Azure ad or Okta for. Consumers, you may wanna offer something like Facebook or Google or LinkedIn, you know, depending on who your, your, audience is. and putting an interface in front of that means that you have this layer of indirection, which introduces some complexity, but also gives you some power, right?

Because Fusion Auth for instance, takes care of keeping track of how you log in with Google or Facebook. And if Google or Facebook changes fusion off will take care of that for you. You know, our developers are watching this. It’s not gonna decay. And your users, and you’ll be looking at a chart sometime and say, well, why is nobody logging with a Facebook anymore?

Because of our community, because it’s our business. We’re gonna focus on that. So, I think that that ability to like delegate authentication to some other system is, is a powerful attribute of, of, servers. That’s a great point. Yeah.

[00:19:36] Stewart: So bringing it back to, to publishers a little bit and kind, I’m aware that, you know, obviously while you’re, you’re with Fusion, they don’t necessarily wanna make this just, look at all the great things Fusion Auth does.

But I think it’s such conceptually, such a powerful, powerful idea. From a user experience perspective. You know, a user can register on one brand or one kind of aspect within that publisher and have their information propagate to, you know, 5, 6, 7 other other brands or even user portals or kind of unified membership systems.

[00:20:07] Dan: Mm-hmm.

[00:20:08] Stewart: It’s so, so useful for that kind of thing to give that central management. So, how. I suppose then the question is like, how does that kind of work? What are the best ways that you have find of structuring sort of applications, not necessarily applications, but structuring instances of identity management to be like, great, here are I need to manage identity, a single identity pool, a sense pool of users across like six, seven different places that they might, might end up being kind of, what does, what does that look like conceptually?

What are the moving pieces that people need to think about if they’re coming to look at this on their own?

[00:20:47] Dan: Sure. So I think that you’re gonna wanna think about, you know, kind of the pools of users, first of all. Mm-hmm. . And if you are, in a, in the media business, you probably wanna have the biggest pool of users you can.

You’re not gonna wanna kinda segment them out, although there may be situations where you have, certain pools that only have access to, to certain. Applications or websites. So you wanna think about kind of permissioning, right? Yeah. Like who has access to which brand and when do they get provisioned into that access?

You know, do they have to pay something? Do they have to have an approval by a salesperson, or is it kinda self-serve? , The other thing you wanna think about is, is roles and what kind of, access they can have within the brand, right? Like everyone may get a default role of a viewer. Somebody else who pays a little bit more might get access to premium content.

Somebody else who pays a little bit more might get access to like webcasts or some other library of content. And so that can all be modeled inside a robust off server. Notice I explicitly didn’t say Fusion Auth right? Like, again, there are many solutions out there. But you’re looking for things like RBAC , which is stands for role-based access control, which is that mapping of users to roles.

 You wanna look at things like groups, so how you can group users. And again, It’s hard to give generic best practices, of course, because you know, every, every application is different, every company is different. But these are some of the kind of technical concepts you’re gonna wanna be looking for.

 We wanna, look at that a little bit because I think understanding how you might structure. Like an application, identity server to be like, okay, these are, this is granular enough control to give people how they want to be accessed, versus, you know, a bit of a free for all.

And then what is ultimately manageable, because realistically, the needs of that business aren’t static. They’re gonna change over time. So I think that was one of the things that we knew we did incorrectly or not optimally. The first few times we looked at it was like, okay, we’ll structure it this way.

Like we really want more. We don’t want one big pool of users, We want a big user tee. And then that’s kind separated up to anarchist specific apps where an app would’ve been. Website A, website B, brand C, you know? And so that’s ability to control like a, this user should have access to app A and app B, but not app C.

[00:23:23] Stewart: Is that kinda the reason you, you did that? Okay. Makes sense.

And then within that particular groups, I think is what we went with. And then rules within the groups, I can’t remember the exact, because there’s so many different kinda little, little things. But even then, you. There’s be around how far you go, like how much of the application layer is integrated with it.

Like, cool, do we, we have all these different permissions in the app, do we wanna like map those one to one to, you know, rules in fusion? Or do we kind have a bit of an abstraction to give control back to app? It’s an interesting thing that can be difficult to get, get right in such a way that you. Move on from it and in the future if you need.

[00:24:07] Dan: Yeah, I mean we, we kind of see like two different patterns and I’ve seen a third one get introduced and the first is you’re just using Fusion Auth for authentication and you’re gonna build your own kind of custom permission structure inside your application. That obviously gives you the most. Power and control.

 It also puts most responsibility on you. The second is you can leverage FusionAuth and its model, right? So that’s, you know, we have a high level, We have tenants, which are basically user pools. We have lower level of applications, which are things you could log into. And then we have group, which lets you group users kind of on top of those applications.

Now, of course, that means you have to constrain your thinking to kinda what FusionAuth can model, and that may or. Be problematic. The third thing we’ve seen kinda come in, there’s actually the rise of these, Authorization is a service vendors. Okay, so Sebos, Permit.io are two that I’ve, I’ve interacted with.

And they basically, you, you have an authentication event and then you sprinkle calls this authentication as a service, or sorry, authorization as service vendor into your application. And that gives you a lot more fine grain control. That’s really where you need. You want a centralized draw authorization, but you don’t want to build that yourself.

[00:25:30] Stewart: Okay. I haven’t heard of these particular like that providers. I’ll have to have to go and have a look into those. Okay. That’s interesting. So then when it comes to, you know, guess back to like an infusion and some of it’s comparisons, and I know you mentioned a couple of like other players in the space, Auth Zero?

Okta log me in? Is that the other one?

[00:25:49] Dan: I think it’s called One Login is

[00:25:50] Stewart: Azure and Amazon-based competitors. Are all players in this space fairly similar? How differentiated are they beyond I’m already in the Microsoft ecosystems. I’m gonna stick with, I’m already in AWS ecosystem. I’m gonna stick with that.

[00:26:07] Dan: Sure.

[00:26:08] Stewart: How do the players stack up each other.

[00:26:12] Dan: Yeah, I mean, I think that, so first of all, there’s like a base level functionality.

We mentioned O I D C. Previously. All these players should support O I D C. And so if all you’re looking for is kind of plain old login, then you could be served by any of them. At that point, you start to look at what are differentiating features. One key one is where you can host a lot of these players are SaaS only, or.

In the case of Auth Zero, I think if you pay enough money where it’s many, many zeros, they will run inside your AWS cloud, Fusion Auth is self hostable or you can pay us to run it for you. And then you get to other kinda unique differentiators, right? Cognito is really great if you’re building on the ABOs ecosystem, because it has some really fine, integration with.

Was permission with aws. Im right. Azure AD is really, you know, again, you alluded this, you’re in the Microsoft ecosystem, you know how to run it anyway. You’re using it for your employees, you know, use it for your customers too. I’m trying to think of some other differentiators. You know, some of it is, we mention.

Automation, Right, Which is typically done through API calls, and some of these are more, or. Some of them are less available for automation and then others are more API first. I happen is pretty API first, but that can be important when you’re starting to think about scaling, right? It’s one thing, we have two properties.

If you have a 200, you really need to be able to do everything again, not just user stuff, but everything else via scripts and, and software.

[00:27:59] Stewart: Yeah. Remind me is, is Fusion Auth open source or available source?

[00:28:07] Dan: Fusion Auth is not open source. And there is, if you’re looking at open source solution, Key Cloak is the one that we are most often compared to in terms of functionality.

There are others out there. Fusion Auth has a free version and I don’t know whether this might be dating myself, but I remember there was free as in speech and free as in beer. Fusion Auth is free as in beer, so you can’t look at the source, but you can run it yourself. And we’ve actually had people running with millions of users on it and they’re managing themselves and good on.

So that’s kind of our model is.

[00:28:41] Stewart: Nice. Cool. And then I guess you mentioned kinda automation and stuff there. One of the things that I think is most interested is looking at user data, kind of from an analytics perspective and trying to like parse, like trends, parse, like, you know, whatever insight you can get from the assets that you hold.

How doable is that across the competitor’s? You know, whether that’s getting it into, you know, in a business intelligence platform, I mean, obviously if you’re using some of like the Microsoft tooling or AWS tooling, they’re gonna integrate pretty easily. But the other players, you know, is it’s forward to get, get that into a table and start, and start querying.

Or something like that. Does that make sense? The question is a bit ramly of a state.

[00:29:31] Dan: No, I think it’s, I think it’s a great question. I think that, it’s actually a critical thing that you want, right? We talked about like the user experience of having one user be able to kind of go across multiple brands, multiple platforms.

Which is a great user experience, but you also think about the business value and there is a ton of business value in not having to run a query across seven different user tables to see what Dan has been up to. And so I think that’s, you know, to tie back to early part of the conversation, that’s a great reason for this standalone off server, right?

 Stand alone user data store is to give you that reporting. Even if what you’re doing is just going there and pulling stuff out of it, you know, so I would say that what I’ve seen, I haven’t delved deeply into this with, with the competitors most of them have some pretty decent APIs. When you’re in the SaaS world, you wanna be careful about throttling making sure that you open a support ticket if you’re gonna be pulling out a bunch of data with Fusion, What we push a lot is, is what are called webhooks, which is when an event happens and we push out a bunch of data and you can store that however you want, and that turns into more of an event driven system.

I haven’t seen that functionality in too many other competitors. So I, I think that there’s, so to sum up, I think there’s kind of two ways to get the data. The first is kind of a poll where you are the one going to the data store and saying, “Hey, give me everybody who’s registered since yesterday.” And the other is push where every time someone registers, you’re getting an event and then you can kind of act on that as you see fit.

And the latter. More modern. I feel like, you know, the former works, but the latter is gonna give you better real time results.

[00:31:16] Stewart: Great. Yeah, I suppose even from like a, a developer perspective, if you have a push, you could run a small serverless function to process that, you know, just as you need, rather than having to maintain and run a service the handles all the time.

[00:31:31] Dan: Or you throw it into S3 or something else and then you have that later and it, you know, Forever, essentially.

So you can run your analogs don’t have forever. Yeah,

[00:31:41] Stewart: Just keeping an eye on the time, Thank you again for being as generous since you have been. I guess it’d be great to, to kind sum up like identity for, for publishers. Identity and authentication and kind of why it’s, you know, much more valuable to kind of outsource this to a service fusion author otherwise as opposed to to doing it your own.

And I think you kind of, some of those key are, it’s a big, dangerous, scary thing to write yourself on. Almost everyone tries it very error prone. And acts as quite specialist skill. So why do it yourselves whenever we can, you know, go out to services, both, you know, proprietary and open source. People are looking at this full-time, it’s their job to know and do it well.

And kind of leverage the experts there and better user experience. Kind of unable to, you know, share data across multiple brands. Kind have it, be as Unified an experience for your end user as possible. There’s operations benefits from the business, from a security perspective of like, okay, we only have to integrate in one place.

We’re deprovisioning, you know, users from our team to make sure that everyone’s and then there’s a, the aspect of being able to, to get your usually get art and be able to process it and query it and whatever insight you wanna, wanna kinda garner from that. Did I, did I miss anything?

[00:32:58] Dan: I think it

was a great summation.

The only thing I would add is that just like with any other outsourced solution, if someone’s focusing on things, they can keep an out of the future. There are new things coming down the pike. New forms of multifactor authentication, which can help people secure their accounts. You know, new identity providers we call ’em, or New Federated Identity Solutions, right?

Like logging with TikTok might be a thing now that wasn’t there, you know, three years ago. And then there’s new technologies like Web Off End, which you users may not be familiar with, which is basically let’s me log in with Touch ID or things like that. And by outsourcing to an off provider who focuses on that, you get the benefit of them bringing these new features in addition to all the other operational and security benefits you.

[00:33:43] Stewart: Yeah. Yeah, I think that’s WebAuthen a great point. That’s not a thing I know particularly very much about. I’ve heard mentioned, but not being a mobile or kind of hardware developer, I’ve kind of passed up a little bit. Can you give us a little bit more on that at all? You have it?

[00:33:57] Dan: Sure. I can give you there saying spiel, but basically it’s a way for for people who are writing web applications that are running in browsers to access biometric.

Authentication methods like touch ID and face id with nothing more than some JavaScript, and it’s a new standard that I think was codified in 2019, but is now supported by all the major browsers and all the major operating systems. And it lets you, as a website publisher have a, a very secure means of authenticating a user and it frankly, a very easy.

Method as well, because it’s a lot easier to just hold your finger up to the fingerprint reader on your Mac. Then is type of username and password.

[00:34:43] Stewart: Great. And is that, I suppose a lot of that is happening on device cuz they’re not gonna be sending you or us or anyone the biometric data off, off the device.

That seems very difficult to do well.

[00:34:55] Dan: Yeah, I mean the nice thing is that like the operating systems have built these pieces of software that talk this protocol and the browser talks the protocol and use WebDev, basically call a job script API. You say like, Hey, you know, You passing a couple options and there’s some security stuff in there too, but it’s one call and you either get back to like a thumbs up or a thumbs down and so it’s a, I think it’s, it has its flaws like every technology or its strengths and weaknesses, but I think it’s gonna be really big for the consumer space to let people authenticate.

[00:35:34] Stewart: Cool. That sounds great. I look forward to seeing more about it. Yeah. Dan, thank you very much for your time today. I really appreciate it. Where can people find out more about you and fusion off, et cetera, or anywhere else you wanna point them?

[00:35:48] Dan: Sure. Yeah. So you can learn more about Fusion off@fusionoff.io and you can learn more about me.

And here’s some of my, my ramblings on Twitter. I’m more Ds, so m o o r e d s.

[00:36:03] Stewart: Lovely. Thank you very much. Really appreciate it as always and have a lovely rest of your day.

[00:36:08] Dan: Thanks so much for having me, Stewart. Really appreciate it and learned a lot.

[00:36:12] Stewart: Great. Thanks man.

[00:36:14] Stewart: Thank you for listening. If you enjoyed this episode, please subscribe. The skill is available in all the usual podcast places. Even better, if you could leave us a review that really helps us.

If you’re interested in finding out more about me or Power by coffee, you can find us on social media and again, in all the usual places, links are in the show notes. Scale is currently gonna kind of come out every two weeks and we will see you then.


You can find Dan and his team at Fusion Auth, or Dan himself on Twitter (@mooreds).

A modern media podcast

hosted by Stewart Ritchie

How has the process of managing user authorisation and management changed for publishers in recent years? And what should publishers be looking for when selecting the right tool for them? Joining us for episode three is our friend Dan Moore from FusionAuth. An expert on all things authorisation, he talks us through his tool, FusionAuth, and how the process of authorising users has developed, changed, and become significantly more intelligent over time.

Grab a coffee and let’s discuss your project.

Drop us a message and we’ll set-up a call to discuss how our team of experts can help.


  • This field is for validation purposes and should be left unchanged.