← Software Engineering Daily
Software Engineering Daily
Enhancing OAuth Security and Interoperability Using FAPI with Joseph Heenan
00:42:49
FAPI is a refinement of the OAuth standard developed by the OpenID Foundation. It was conceived to solve a core problem of providing a consistent approach to API security across the financial industry, with the goal of enhancing interoperability of fin...
Loading summary
Transcript55 lines
- [00:00]
Joseph Hinan
FAPI is a refinement of the OAUTH standard developed by the OpenID Foundation. It was conceived to solve a core problem of providing a consistent approach to API security across a financial industry with the goal of enhancing interoperability of financial data exchange. It has now been adopted across many different industries and applications where there is an API that requires a heightened authorization security implementation. Authleat is a service that provides a set of APIs to implement OAuth authorization servers and OpenID Connect identity providers, allowing either to be easily made FAPI compliant. Joseph Hinan is the CTO at Athlete and he also leads the certification program at the OpenID Foundation. He joins the podcast with Gerger Van to talk about the origins of fapi, the motivations for its creation, the status of FAPI development, and more. Gregor Vand is a security focused technologist and is the founder and CTO of MailPass. Previously, Gregor was a CTO across cybersecurity, cyber insurance, and general software engineering companies. He has been based in Asia Pacific for almost a decade and can be found via his profile at Vand HK.
- [01:23]
Gregor Vand
Hi Joseph, welcome to Software Engineering Daily.
- [01:26]
Joseph Hinan
Thanks Gregor. Great to be here.
- [01:28]
Gregor Vand
Yeah, Joseph, it's great to be speaking today. We did have authleet on the podcast, I think it was back in April, and we learned a really good amount of things really around the OAuth spec and the way that Authly implements that specifically. But today we're going to be focusing on kind of a different piece of the Authly stack, if we could call it that, which is fapi. And obviously we can get onto what on earth is FAPI and what does it even stand for, et cetera. You're the CTO of authlyte. Maybe if you could just give us a quick what's your background and how did you find yourself as the CTO of Authly?
- [02:04]
Joseph Hinan
Yeah, sure. So my actual kind of long term background is actually as a mobile app developer. So I always quipped that I started doing mobile apps before mobile apps actually existed, because I actually started back in 2000 when this was more like palm pilots and things like that, if some of your readers are of the older nature. But yeah, after I kind of ended that engagement I went into doing independent consulting for a bit and then some people that I'd worked with at the previous company doing mobile apps reached out to me and said, hey, we've started this new thing called Authly. Are you interested to come and see what we're doing and talk to us about Helping out. So yeah, kind of went from there. That was my first kind of venture really into this whole authorization space. I'd always, I'd obviously consumed OAUTH before, but never really got into the details of how it all worked and how you secure it and what's good and bad practices.
- [02:58]
Gregor Vand
Yeah, and you're also, you know, you're quite involved is it with the OpenID connect like spec. Is that the best way to sort of describe it?
- [03:06]
Joseph Hinan
Yeah. So particularly with the OpenID Foundation, I get quite involved with a bunch of specs they do so as well as my CTO role at Authly to actually lead the certification programs over at the OpenID Foundation. So yeah, I get involved with quite a lot of different specs, including the Most famous 1 OpenID Connect I think everybody's heard of as you kind of log in with Google and so on options, but also get involved with a lot of the other specs as well. So some of the shared signals specs that are used for these modern ecosystems where the identity providers share signals about fraud with each other. Some of FAPI is another OpenID foundation spec obviously and then there's some others like Authsen Federation and a few others probably shouldn't get into those today.
- [03:52]
Gregor Vand
Yeah, no, I mean it all sounds very complimentary and yeah, I think maybe different to some other kind of aspects of technology and the industry. Just that being involved with foundations and spec creation often go kind of hand in hand with platforms that are rolling it out. Having some huge separation there doesn't really benefit anyone. So it really helps to sort of be able to be on the spec creation side as much as the industry side.
- [04:20]
Joseph Hinan
Yeah, exactly, definitely. I mean, I think from the very early days of Authly it's been very important to the company that all the kind of specifications are open, interoperable standards that don't favor any particular player and that everybody can get involved with and implement without any fear of things being patent or locked into one vendor or anything like that.
- [04:42]
Gregor Vand
Yeah. So let's kind of dive straight in. Today we're here to talk about fapi. I'm aware FAPI has gone through a few naming changes conventions because I think, I guess if I was to Google FAPI or whatever, there could be a few different potential things pop up for sort of what that still in this context. But yeah, I'll let you maybe just talk us through the history of the naming.
- [05:08]
Joseph Hinan
Yeah, it is quite an interesting and long history. As you say. There's been a few different names over the years. I mean originally the working group at the OpenID foundation actually started out with the aim of making essentially an open banking API that would be global and international. They kind of relatively quickly realized that was actually a really complicated task. But what they had produced was a security profile for how you do OAUTH in these kind of open banking spaces. So at this point it was FAPI stood for Financial API and it had this goal to be this wide ranging thing that covered everything to do with open banking. And as I say, they specialize then into just the security part. But at that point the kind of FAPI acronym was already locked in. So we've been trying to figure out different ways to use that acronym, but still have some underlying sense. So firstly it evolved into Financial API Security Profile. But then we started getting approached by people that were actually outside of these traditional open banking spaces. Because the FAPI standard is very much. It's how you do OAUTH in a high security and interoperable modern way. So it's completely applicable to pretty much any open data ecosystem that's transmitting any kind of personal information. So certainly we've got a lot of information from health ecosystems where obviously the privacy is very important to people. Also things like open energy ecosystems or open insurance, there's quite a few. And with that financial label on it, we were getting pushback from those ecosystems. We don't think this is suitable for us because you're aiming for banks. So we then changed the name to instead of Financial API to Financial Grade API Security Profile. But actually it continued to be a thing that the financial in there was confusing people somehow and they just didn't feel that this was a general purpose thing that they should adopt. So essentially the latest change is that it's now just fappy and it doesn't stand for anything in the Same way OAuth 2.0 it did originally stand for something, but now it's just OAUTH and nobody talks about what it stood for. So we're doing the same thing with fapi.
- [07:11]
Gregor Vand
Yeah. And then I think we see this throughout history in this sort of tech world. I believe Ms. DOS started as qdos, which I think actually technically stood for a quick and dirty operating system. So they dropped the Q and added Ms. On the front. And obviously they don't want to of remember the fact that it started as quick and dirty os. So when technologies start out they always have a name that sort of helps everyone just get behind a concept. And I think I find this one particularly interesting because even I thought There was maybe more specifically around the financial side today, whereas actually it's a standard and it can be used for many things. I think it might also be just helpful. I'm very familiar with when we talk about open banking, for example, I'm very familiar with that. Although I live in Asia, I'm quite familiar with the UK banking system and there was a big thing around open banking. But I think there'll be quite a few listeners out there who actually don't maybe have a concept of what that means. So maybe could we just cover that one off?
- [08:12]
Joseph Hinan
Yeah, no, it's a good point. As you say, the UK was very much the leaders in this space. So back in, it was 2018 that open banking started to become a thing in the UK and the idea was very much using more acronyms. Now it came out of part of GDPR coming out of the European General Data Privacy Regulations, which is very much this concept that a user's data is their own and if they want to be able to share it with other people in a way that benefits their lives, they should be able to. And in particular the whole open banking aspect is that the regulators didn't want the banks to be choosing who the consumers could and couldn't share their data with and wanted it to be easy for the consumers to do this data sharing. So that's where open banking comes from. So a few actual use cases I can name, like when I'm doing my accounts, the transactions from all my UK bank accounts just automatically appear in my accounting package. That's just using open banking. At some point in history I authorized my accounting software to access my bank account. Said I was quite happy for that to be ongoing access and they just automatically come in several times a day and it saves a lot of manual entry and reduces the number of errors. Prior to open banking, this was actually done via FTP if the listeners actually are old enough to remember FTP and it wasn't reliable, it was a paper based form to set it up and quite often you'd miss a day's transactions or a day's transactions would get uploaded twice or something. And open banking has very much solved that. The setup's much easier, it's much more reliable.
- [09:49]
Gregor Vand
Yeah, I didn't maybe appreciate if I'm understanding right that it was actually FTP behind the scenes, but when I first started a company in 20, I think it was 12 at this point and Barclays, the bank in the UK had a sort of relationship with an accounting provider and they talked about bank feeds and As a consumer, this was pretty great. I didn't need to do much, but I do remember signing forms and there was data problems at times like, oh, the same day has appeared twice, or that kind of thing. And then there was a clear point when we were told, right, we are moving to this new standard called open banking and you need to click a button and that's fine. And equally, another use case, I guess for me is I'm sure people in the us, for example Robinhood or these trading platforms, if you want to top up that account, similar concepts in the uk and you can just say, hey, top up. And then your bank app pops up and says, are you okay about transferring this money? Yes, I am. And you don't have to do any kind of other real logins other than your, in this case, sort of touch ID or that kind of thing.
- [10:52]
Joseph Hinan
Yeah, exactly. So, I mean, one of the biggest use cases in the UK now actually is for paying your taxes with open banking. And it's actually saved the government a fortune because the thing about paying your taxes is you always have to get the exact right account number and there's also some kind of ID that actually means that the payment can be tracked to what you were trying to pay. And people were just getting these IDs wrong all the time. And HMRC have to then manually trace the payment, try and figure out what you are trying to pay and so on. And that took up a lot of time for them, so they enabled open banking. So you just go on your phone and say, hey, you owe this much, I want to pay it, launches your bank app and you say, yep, go ahead and pay it. So, yeah, that's. I can't remember the latest figures, but I think they reckoned it saved them millions of pounds, basically just implementing this open banking ecosystem. So, yeah, one of the best payoffs I think, in a recent government tech project.
- [11:43]
Gregor Vand
Yeah. So actually just to back up for a second, hmrc, I think, because we're both quite UK aware, we know what that is. Yeah. Maybe if you could just give a quick explanation of what is hmrc.
- [11:54]
Joseph Hinan
Yeah, sure. So Her Majesty's Revenue and Customs, which is a very British term, obviously. So, yeah, in the usa, the equivalent would be the Inland Revenue Service, the dreaded irs. So, yeah, the people that are responsible for collecting taxes from individuals and businesses.
- [12:10]
Gregor Vand
And I sit in Singapore and I don't maybe think they're using open banking as such, but within Singapore there's a very sort of closed ecosystem where effectively the same thing is going on and I feel quite spoiled at this point between the two systems. I'm quite just used to being able to do things very fast and easily. And I think obviously the elephant in the room is North America where you have all these differing banking systems and is it ach, is it Wire Fedwire, blah blah blah. So I think we've probably got a fairly good feeling of where this can be useful and maybe towards the end we can also come back on. You mentioned things like Open Insurance. I'm really curious to hear about that, having personally worked in cyber insurance. So we'd love to go there. But let's talk actually just about the technology side and so obviously offleet very much helps implement fapi. We can talk about the exact authly sort of piece to this shortly, but let's actually just talk about FAPI in relation to OAuth and OpenID connect generally. Like, you know, those are the two standards that or OAuth 2.0, you know, if we're talking about OAuth probably how would you sort of in semi layman terms describe how FAPI differs from these other two standards and works potentially with them, which I think it does.
- [13:30]
Joseph Hinan
Yeah. So I mean, I think the first and most important thing is that all these things are built on top of OAuth 2.0. So there is a common underlying base there with common terminology and so on. So we're not trying to completely reinvent wheels. So OAuth 2, it's very much a framework, it's got lots of optionality even in the base spec and then there's all kinds of bolt on specs you can have as well. There's different documents that cover security best practices for OAuth itself or for the underlying jots, things like that. So it's a very comprehensive spec. And if you just say I'm using OAuth2, then you can't really expect any level of interoperability and it's very unknown what kind of security target you're hitting. And OpenID Connect is just again that builds on top of OAuth 2. OpenID Connect very much adds on the identity layer so that as well as getting access to an external resource like your Google Drive contents or whatever, you also get information about who you are sent to the third party so they know your verified email address, for example. That's the part that OpenID Connect solves. So FAPI very much builds on top of those underlying OAuth 2 standards, but FAPI is based on an attacker model that these are the kinds of things that we want to prevent happening by improving the security of OAuth 2. And it uses standard OAuth 2 specs. Again, there's all this optionality around. So FAPI really narrows it down to, you know, when you're doing client authentication. I think a lot of people that have done OAuth2 in the past will be familiar with client secrets and secrets. A bit of a misnomer here because it's. That secret is known to many people. It's known to the authorization server that issued it. It's obviously hard coded into your client software that you then use as it to actually authenticate at the authorization server server. It's known by your client developers, maybe some of whom aren't even with your company anymore, and that kind of thing. So it's not really a secret because of that. It doesn't really give you proof that if this secret's presented that you actually know who the entity presenting it is. So what FAPI does in this case is it says you must use one of two particular standards, one of which is called mtls, one of which is called private key jot client authentication. And the common thing between both of those standards is that they're based on cryptography, so public and private keys. So they're based on the assumption that the third party has a private key and can keep it secure, and then it just passes objects signed with that private key to the authorization server. The authorization server knows the public key it's expecting for the client and can then verify the message. So that's one example of the kind of way fapi2 it builds upon OAuth 2.0, but it makes it more interoperable, it makes it more secure.
- [16:13]
Gregor Vand
Yeah, I think that's a very good way to introduce it and explain it is the fact that under the hood, it is still OAuth 2.0. However, what is was one of the problems with OAuth 2.0 that there are still many ways to implement OAuth 2. And unless you can get everybody on the same page about how we're all agreeing to that, then. Exactly. Call it different APIs. That's a very basic way of explaining it. But even though it's the same spec, you're working off two different systems. So FAPI has added this effectively an agreement layer, if we want to call it that. Okay, so here's a question. When it came to, I guess, open banking with fapi, I'm sure it was a long process, so maybe just a certain condensement. What Was the process for actually getting the major banks to agree to a spec. I mean how does that work?
- [17:04]
Joseph Hinan
Yeah, that was a long journey, I think we could say. And it's a journey that repeats every time open banking expands to new ecosystems. So actually exactly this conversation is currently ongoing in the USA and in Canada. The USA has what their Consumer Finance Protection Bureau has started saying actually open banking is going to be a thing. They're probably some rules and now banks are talking, how do we actually do this? And yeah, as you're hinting at there, getting a country wide set of banks to actually agree to doing something in similar ways is not the easiest task. And I think at the end of the day a lot of the actual routes of agreements is from regulators actually saying look, you have to do something that's secure and interoperable, which means it has to be pretty similar across everything you're doing. So you do need to agree to do something. That's the same for all of you.
- [17:55]
Gregor Vand
Yeah. And if those sort of listening today the reason why they might need to implement fapi, either they work for someone where they are in a regulatory environment that says just that you need to implement fapi, or is it also fair to say that it could be there are a small number of parties in a certain industry or area that all much faster agree to needing to or wanting to pass data between themselves because they would all benefit and FAPI happens to now be probably the most realistic agreement structure to do that under.
- [18:33]
Joseph Hinan
Yeah, definitely. So I guess one interesting example is in Australia. So Australia actually has a regulated ecosystem called the Consumer Data Rights which deals with a lot of the open banking side of things. But what's happened recently is that the bank's industry body, Australia Payments plus has decided that they want to start the banks sharing identity information with each other and with people that want to pay to access it. So yeah, they got the banks together and they decided, yep, we should do this using fapi. This is the obvious choice.
- [19:06]
Gregor Vand
Out of curiosity, are there any other standards like at the moment that could be sort of competitors to fapi, so to speak?
- [19:14]
Joseph Hinan
Yeah, the kind of, I mean the big one you'll hear about within Europe is the Berlin Group standards which they define open banking APIs but they've also defined some security profiles. But I think it's fair to say that open banking in Europe is not as advanced and not as usable for consumers as it is in the uk. And a lot of people, including myself, attribute that difference to those Berlin Group standards. They're firstly not mandatory for all banks. And they're not as prescriptive about interoperability as SVAPI is. They don't, for example, have certification suites like the ones the OpenID foundation has that actually check, yeah, okay, this bank has actually implemented the standard correctly, which is a really important thing, because everything we've discovered from doing certification is that unless you have that kind of test and that assurance, then the banks just don't implement things correctly and they do something that works. And then if somebody complains it doesn't work, they just say, sorry, but you can work around it like this. And when you have to do that for like 400 banks, it becomes a significant impediment to actually integrating with banks when you do that. And the other standard that people often talk about, which we've not mentioned yet, is OAuth 2.1, which is an upcoming standard from the same working group in the Internet Engineering Task Force that produced OAuth 2.0 originally. People do say, well, can't I just use OAuth 2.1 instead of FAPI? And I mean, OAuth 2.1, it does fix some of the worst security problems in OAuth 2. And it has the recommendations kind of built into the spec instead of external best current practice documents. And it's a much easier spec to read and actually implement. But it's still just a framework exactly like OAuth2 is. It's not prescriptive about exactly how you do things. It says, yeah, we recommend you use sender constrained access tokens, for example, which prevents stolen access tokens being used by an attacker to access the data. So it recommends that, but it doesn't say you must do this in a particular way, so you don't have the interoperability. And it's only a recommendation. So a bank can quite happily say, hey, I'm compliant with OAuth 2.1, but not implement this very important security feature.
- [21:26]
Gregor Vand
Yeah, I think this is a really good point just to touch on where often the problem, at least from where I sit with a lot of implementations of anything when it comes to security generally, is the lack of whether you want to just call them defaults or lack of, quite frankly, opinionated forcing, actually of whether it's a user or in these cases it's more companies and how they talk to each other, but actually saying you don't have a choice. This is, yes, okay, the underlying spec had all these areas you could have gone with, but the only way we're going to do this in probably the Best possible way. And what we're talking about is the safest and most secure possible way is you cannot use all the bits of the spec. You have to actually use certain bits of the spec in this specific way. And actually the challenge of course is getting people to come and agree on that. So I think this is really just a really interesting move forwards where actually something like FAPI has come along and put in place clearly a whole series of more than just suggestions. But let's do this, let's use the same thing. Maybe we could even dive into just some of those in a little bit more detail. Now, some things that I guess come to mind, the concepts of things like message signing, client initiated back channel authentication, grant consent, pushed authorization requests, and then you did touch on it just briefly there, sender constrained access tokens. Could you maybe just talk through kind of these concepts and how they actually make FAPI work?
- [22:57]
Joseph Hinan
Yeah, definitely. Let's talk about client initiated back channel authentication, I guess to start with. That's usually abbreviated to siber, which is much less of a mouthful. So it's not actually got huge adoption at the moment, but it has got some niche use cases where it's working very well. What that specification really does is when you want to authorize someone to do something, if you're say, doing it over a phone call, then it's very difficult to do that whole identity proofing. I'm gonna, you know, you can't read out an access token over the phone or something. So what SEBA does, you know, you can call into a call center. The call center probably knows who you are because they've got your phone number. Then you tell the operator what you want to do. They need access to your account. So you get a push notification on your mobile phone that says, hey, do you want to allow this call center operative you're talking to access to your account? Obviously you can put some kind of codes in there so you know it's the person you're actually talking to. And then the user authenticates that and does the usual face id, says yes, I want to consent to this. And then the call center operator gets access to the user's account and is able to complete whatever the user wants done. So that's the kind of use cases SIBA solves. As you mentioned, there's a separate message signing spec as well. So the way FAPI was developed, there was an attacker model developed. Then we tried to develop a security profile that then protected against that attacker model. And we actually did a formal mathematical analysis that was done by the University of Stuttgart. That actually proves that, yes, what we put in the specification does actually protect against the attacker model that was defined there. And what message signing does is it's not necessary to actually protect against that attacker model, but it's sometimes necessary to retain messages and prove later in time that, yes, I did actually receive a request to make a payment from this account to this account from this third party. The message signatures gives you the way to actually have that signed message that says, yes, someone that has access to that private key that only this third party fintech should have access to did actually sign this message and ask for that payment to be made. So it's not technically security, but people call it non repudiation, which isn't a phrase that people often understand, but it's just that ability to say that, yes, to the best of our knowledge of current cryptography, this person did actually produce that message and send it to the bank.
- [25:23]
Gregor Vand
Matching of identities, basically, and not necessarily within a very specific timeframe. If I'm understanding it. There could be a lag.
- [25:32]
Joseph Hinan
Yeah, exactly.
- [25:33]
Gregor Vand
Yeah.
- [25:34]
Joseph Hinan
It could end up being produced in court or something.
- [25:36]
Gregor Vand
Yeah. And then maybe just touch on pushed authorization request, something I think I'm fairly aware of receiving. So I think that could be an interesting one. Yeah, like sort of. How does that operate?
- [25:49]
Joseph Hinan
Yeah, so pushed authorization request, actually it's a great simplification to the specs because in the first version of fapi we actually always require people to send signed messages because these messages were actually getting passed via the browser in what you'd call the front channel, which means they're kind of exposed and the user potentially, or plugins the user has installed in their browser could modify those messages. So yeah, potentially you end up with a situation where that plugin could be changing the destination account number or something like that, which is obviously undesirable. So FAPI1 said you have to sign the message to avoid that because that then makes it untamperable. But then this concept called pushed authorization requests came up and what that allows is that it allows the fintech or the third party to actually ahead of time send to the bank's authorization server. I want to make this payment from this account to this account and it's passed over tls, as you'd expect, and it's an authenticated message. So it uses MTLS or assigned jot just to say, yeah, this is coming from this third party, you can check that and know that. And then basically the bank gives back a handle to the third party and Then it's only that handle that's actually passed into the user's browser and then you can't tamper with it because it's not got any of that payment information and it's either a valid handle or it's not. So the only thing you can do by tampering with it is break the whole thing. And that just means that the developers at the fintechs can just avoid having to do this whole thing with sign messages. And it just makes the spec much simpler and it helps with security and with privacy because obviously even if the message is signed, the contents is still there. So you'd have to add encryption on top to prevent the contents being leaked to browser plugins and potentially recorded in browser history and who knows what else. But again, it neatly solves that problem because that information never flows through the browser anymore.
- [27:41]
Gregor Vand
I think that's a really good example where it's not as if developers from two different banks couldn't have ultimately come up with this system. That's not the problem here. Yes, it's still very complex and still requires people that really understand, especially things like cryptography, to know what they're doing. But this overarching problem here was getting everyone to agree to use spec that we all know what these different bits are and how to handle them. Just before we maybe talk about some, maybe potentially non financial, we talked a lot about open banking and we can move on to maybe just a couple of other examples. But I'm aware the FAPI does have, I think it's two different profiles, baseline and advanced. And how does that differ effectively?
- [28:28]
Joseph Hinan
Yeah, so it's actually slightly more complex than that because there is a version one of FAPI and a version two. So in FAPI version one there's a baseline profile and an advanced profile. And again they've been through several name changes. So you'll sometimes see the baseline profile actually referred to as a read only profile and the advanced one referred to as a read write profile. The thought was at the time that security of payment transactions would need to be higher than the security of just getting access to account transactions. But once these open banking ecosystems started spinning up and the lawyers started getting involved and the banks as well, they actually quickly said, well hang on, we don't actually care that much about losing little bits of money. Happens all the time. You know, we just give the customer the money back, it's not a big issue. But if the user's data leaks, that's actually a big problem because you can't close the Barn door after the horse has bolted. So it actually came out. Yeah, we need this higher security all the time. So actually the baseline profile really isn't used. Everybody uses that advanced profile in FAPI1. And then what happened? As a result of a lot of the feedback we got from ecosystems implementing FAPI1 advanced, it became clear that it could be simplified a bit and made easier. And we started on a second version of FAPI called FAPI 2 which has, that just has a security profile. It doesn't have baseline and advanced. And that security profile is sufficient to meet everything in the attacker model. And then as we talked about earlier, there's extra bolt ons like message signing and so on that you can add on top of that.
- [30:01]
Gregor Vand
Got it. So we have talked a bit about open banking. At the start of the episode you touched on some other areas, things like open insurance. Could you just speak to a couple maybe you'll assume almost seen every area or implementation of FAPI so far or been aware of it probably. So what else has been happening with fapi?
- [30:22]
Joseph Hinan
Yeah, I mean it's interesting you say we're aware of them all, but even with that kind of role I'm doing at the OpenID foundation, we occasionally get, people pop up and say oh yeah, this, we get contact from a new country and they say yeah, we implemented a law two years ago that says people have to use fapi. And you know, the first we're hearing of it is two years later. So often we don't find out about these things as they're actually happening. Particularly with OpenID Connect, we have absolutely no idea how many implementations there are out there. We reckon it's thousands, tens of thousands. But people just, you know, it's open standards, it gets used and you never find out about it a lot of the time. So in terms of other ecosystems that we actually know about that are using it, I mean Brazil went, they bought into FAPI and open data in a big way. So they put open banking live, they extended that to open finance pretty quickly. So open banking obviously is usually just your transactions and stuff. And then once you expand into open finance, you're talking about your investments, potentially credit cards, that kind of thing that might not be part of the traditional bank. And then they very quickly after that expanded into open insurance as well. So again, it's perhaps still slightly early days for open insurance. So I don't think we've got the data yet on where the kind of biggest benefits for users are coming in. Obviously it's letting brokers retrieve information about the policies user a user has from the insurance companies. They can then use that to get quotes from other insurance companies that have the same equivalent cover. And they, you know, it avoids this problem with the user needing to react re enter all the information into each insurance site to try and get competitive quotes. And there are alternative solutions around to that. I think in the UK and I think the US Compare the market is a big one, but that's obviously all based off kind of proprietary APIs. Open insurance is very much that same, very open. The user owns the data type ethos where everything's based on open standards. If a new player wants to enter the market, they can very easily do so they don't have to sign agreements with each insurance company to get access to the data before they can actually usefully serve users. So it's just very much about flattening that barrier to entry and allowing innovation in things where there's otherwise market incumbents that just have essentially not creating a proper competitive market.
- [32:45]
Gregor Vand
Yeah, that's a really good example. Yeah. Compare the market. I'm very, I guess, familiar with that, finding my insurance for a house or a car. But yeah, maybe just if you could give a quick explanation and we can talk about why it's even so famous in the uk. But what is compare the market?
- [33:01]
Joseph Hinan
Yeah, so it's one of these portals that you can try and find the best dealers, consumers. So covers insurance, credit cards, things like that. But yeah, they do a lot of data scraping essentially to get the data and potentially they ask questions about what insurance policy you would like and then provide it out to a bunch of different companies that then I'm sure some of them are using APIs, but I would suspect some are probably using screen scraping and those kind of headless browsers. So perhaps I don't know if Money Supermarket is more better known in some of the other geographies, but it's this kind of comparison site paradigm.
- [33:37]
Gregor Vand
Yeah, and I think it was probably one of the sort of first that came on the scene for consumers, but yeah, very much popularized by their advertising of compare the meerkat and having a puppet meerkat at one stage. And I think it's all animated now. But yes, good advertising. But unfortunately it means that everybody in the UK I think knows exactly what compare the market is.
- [33:58]
Joseph Hinan
Yeah, I think at one point if you took a policy out through them, they did actually send you a soft toy, cuddly mercat in the post.
- [34:05]
Gregor Vand
Yes, yes, that sounds about right. Is this in any way in the right direction? Where Something like FAPI is then going to actually make it sort of safer, better than I feel like something like compare the market. I don't know what they do today, but someone like them or in another industry basically sort of scraping data and using RPL I think is the acronym, basically using kind of headless browser, et cetera, et cetera, terrible ways to kind of do official things. That feels like where FAPI can come in and as you see, sort of level the playing field a bit and just say, look, we're all in agreement that it should be helpful to both sides that we can swap this information, but please don't come and use bots on our website.
- [34:46]
Joseph Hinan
Yeah, exactly. And I mean the big problem with that kind of screen scraping approach and the bots is that it's not really visible to the bank or necessarily to the user what's going on. So you know, if you give your online banking username and password to one of these screen scraping sites so that they can pull their account transactions down, you're actually also giving them the ability to make payments on your behalf, which is not really what you wanted to do. And FAPI just avoids that because it's oauth based and the user is actually involved in authorizing the bank and that the fintech gets specific permissions that might even be limited by the regulator or something. So that, yeah, the user knows that that person, they're going to be able to see their account transaction data but they're not going to be able to do anything else with their bank account.
- [35:35]
Gregor Vand
Yeah, overall just a huge step in the right direction given how sort of many accounts things that we basically manage online today, whether it's insurance for a car or a house, it feels like all my banking is online at this point in time. But insurance is also getting there. I think they finally just implemented the ability to update my credit card on their account, which feels kind of ridiculous, but I'm aware insurance moves much slower than other industries. But if something like FAPI can come along and as you say, level that a bit and speed that up, that sounds pretty exciting. Let's maybe just talk about Authly and how Authly helps implement fapi. So you know, if I'm a, if I'm a developer and I'm wanting to implement fapi, what does authleet kind of do to help with that?
- [36:23]
Joseph Hinan
Yeah, so good question. So I mean autholite speciality is providing these backend APIs that let you build your authorization server how you want. So, so you probably Start by building a basic OAuth 2 authorization server. But then once you've built that with Authly, if you decide you want to enable fapi, which obviously I think most people should, then it's just a case of switching on a few configuration options, creating a few keys and that kind of thing. Autholite hides any complexity of all that extra security that's going on from you. You just have to interact with it in the same way, and you basically get that fappy side without any development effort on your side.
- [37:02]
Gregor Vand
And we may have covered it in our last episode back in April, but in terms of does it matter at all what stack I'm already using, or am I already using OAuth 2.0 or OpenID Connect? How does that look in terms of I'm coming fresh at this? Well, I say fresh at this, but let's talk about both Greenfield and maybe Brownfield projects as well.
- [37:23]
Joseph Hinan
Yeah, sure. So, I mean, Greenfield is obviously a great place to just buy straight into authleet. You know that there are obviously other solutions out there, but we would say they don't give you that same level of flexibility. So, for example, when you're using authlyte, you get a completely free choice of which programming language, which web frameworks you use to actually develop your authorization server. Because we're not providing the actual authorization server, we're just providing those APIs that enable you to create an authorization server easily. So, yeah, you want to do it in go Scala, you know, Node js, whatever you want to do it in, you can do it in. It's just you have to call the API. So it means that it's really loved by developers because they get the freedom to do exactly what they want in the languages they're comfortable with. Which is quite different to perhaps some of our competitors that might insist you use Java and a particular web framework and you kind of get a bit locked into the decisions they made for you. And having to get developers familiar with that that aren't necessarily the same developers you would have for other parts of your product?
- [38:29]
Gregor Vand
Yeah. Awesome. And yeah, like, what's the sort of day zero for a developer with Authlite? I mean, does it tend to be a developer that makes that first sort of signs up and gets the account running? Or is it somebody else in the. Org or how does that work?
- [38:42]
Joseph Hinan
Yeah, I mean, I think in general we see our customers being developer driven. A developer just they need to solve a problem, they sign up for an authleet trial account, they get immediate access and they can then put the authorization server together. Very simply. We've had people spin one up in a few hours and then once they've done that, they've got their proof of concept and they can then go and build out the full proper project and get the other people involved and say, hey, I found this solution, this looks good to me, go and buy this, please.
- [39:13]
Gregor Vand
Yeah, nice. Well, I mean, yeah, there you have it, listeners. Pretty easy in the end of things to actually get going with fapi, whether it's something that's being asked of you, depending on your role and the company you're in, or if it's actually now just something that sort of sounds like it makes a lot of sense. I'm curious, Jose. You're so involved with the spec and whilst, as you say, you haven't seen, you don't know every single implementation so far, but what are you kind of excited about potentially seeing FAPI unlock that maybe hasn't actually happened yet.
- [39:48]
Joseph Hinan
Certainly one big problem that we see in the UK and a lot of other countries is that people's medical records are locked into a particular system and can't be exposed. So we have seen some of the European countries actually adopting FAPI for healthcare use cases. So I think that's really exciting to let users consent to sharing their data from the provider that's holding it with other people that need it in a nice and easy way. I mean, I can't tell you how many times I've heard from people that, you know that their GP is meant to have sent the data to a specialist and quite often involves letters sent in the post or via email with scans of PDFs and who knows, but it often seems to fail. And just by having that direct, okay, the user's in control of their data, they can actually just share it directly with the specialist. Just means you avoid a whole area of the system that can go wrong and slow down people actually getting access to the healthcare they need.
- [40:44]
Gregor Vand
Yeah, that's really interesting. I lived in Hong Kong for a long time and something that stuck out there was if you got an X ray, then they just give you your X rays, like in a little packet, and then you take them physically to whoever they need to go to. And you became this kind of thing that you noticed as you realized that you're like, oh, there's someone with their X rays today. And in other countries that just doesn't happen. But equally, the way data like that gets transmitted, who knows, maybe is it actually just literally posted or Is it slightly sort of not okay ways of, who knows, emailing X rays or something along these lines. So, yeah, something like FAPI could definitely, I feel, clean that up. Yeah. So, yeah. Thank you so much for coming on today, Joseph. I mean, I think I've loved just learning, I guess, a bit more behind the scenes of the system that I've obviously benefited from hugely having access to the UK banking system and kind of having watched it, I guess in some ways almost take the lead a little bit on the open banking sort of stage. To recap, like, where's the best place for a developer to go from a sort of website perspective to get running with FAPI on Offleet?
- [41:54]
Joseph Hinan
Yeah. So we actually have a special offer for software engineering daily podcast subscribers. So we usually have a kind of limited free trial, but that's been extended to 90 days for subscribers. So if you just go to authleet.com sed then you'll get that.
- [42:11]
Gregor Vand
Awesome. So that's authleet.com sed yep. Perfect. Wow. I feel like that's almost a first. We're now, we must be hitting the big leagues if we're getting the special offers just for our listeners. So this is exciting. So, again, thank you so much, Joseph, for coming on and yeah, I look forward to catching up in the future on all things fappy.
- [42:32]
Joseph Hinan
Yeah, that's been awesome. Thank you very much for having me, Gregor.