Hello. Welcome to our talk about how to best deal with standards like OIDC, like OAuth2, and FAPI, which probably few people know. And how make this really work well in practice. I'm Martin Kuppinger, Principal Analyst at KuppingerCole Analyst, and I'm here with Joseph Heenan of Authlete. Welcome, Joseph.
Hi Martin, good to be here.
So maybe Joseph, you could introduce yourself a bit and talk a bit about your role at Authlete and your background.
Sure, yeah. So I mean, my actual long background is as a mobile app developer. I was doing that for, well, on and off for 25 years or something. But yeah, I got into the identity space a while back and started at Authlete around about the time open banking and that kind of thing was kicking off. So I'm the CTO at Authlete now. So a lot of what I do for them is engaging with the standards bodies, taking part in standards development, doing presentations at conferences, generally trying to figure out where the market is going essentially.
Okay, so I assume that most people who will be listening to this talk will be familiar with OAuth and OpenID Connect and stuff like that. But FAPI is a bit of a different beast. What does FAPI stand for? And could you give us a bit of a brief introduction here?
Yeah, sure. So there is quite a bit of history around that. The very short answer is that FAPI doesn't actually stand for anything, but it used to. So back over, where are we, six, eight years ago or now, the OpenID Foundation started an effort looking at kind of open finance and that kind of thing. So at that point, they created a working group, which was at that time called Financial API, which was actually aiming to develop the functional APIs that you'd use to, you know, retrieve your bank account transactions or make payments or that kind of thing. They kind of fairly quickly realized that that was actually a pretty tough goal for what is a relatively small team of in a working group at the open ID foundation to actually achieve it's... you know, banking differs a lot around the world. So coming up with one banking standard that works everywhere around the world is really quite challenging and actually even today no one has really cracked that nut yet. But what did come out of that work was that it was clear that the underlying OAuth and so on, there needed to be an interoperability and security layer there that kind of lifts OAuth from suitable for sharing cat photos to suitable for sharing your financial information and initiating payments and those kinds of higher risk use cases.
So FAPI in that sense is a layer on top of OAuth, in OpenID Connect, which adds an extra sort of level of security and the required strengths and reliability and assurance we need in the financial services.
Exactly. Yeah. And the interoperability part is also very important because that's, you know, if you think about some of these open banking ecosystems, like in the US I think there's, 4,000 banks. Can you imagine if you had to as a FinTech configure your OAuth stack individually for each of 4,000 different banks. It's, it doesn't allow an ecosystem to scale. So FAPI by kind of reducing optionality really makes things interoperable and scalable.
Yeah. So, FAPI in that sense is really also about having some layer that maps the standards from the outer space to the frequently very legacy types of backend services you find in different types of banks and other financial services organizations. Do I get this right?
Yeah, so that's definitely part of it. As I said, I mean, the working group kind of moved away from really getting into those backend banking systems into just concentrating on that OAuth layer that really lets the user authorize access to their transactions. And then the third parties really get access securely to the, and reliably, as you said, to the user's data.
So what is the adoption then of FAPI in that world?
So it's pretty high. So everything really kicked off in the UK. The UK was really the first ecosystem to go live with open banking and they were very early adopters of FAPI and actually got involved in the FAPI working group and the OpenID Foundation actually provided feedback on the specs. And, as the spec was rolled out in the UK, I was actually working in UK open banking at that point. and we got an awful lot of feedback from implementers and saw what really went well and what really didn't go well and use that to evolve the standard. And I think Australia were probably the next people to adopt it then in what they call their consumer data rights. But we've also seen adoption across New Zealand. FDX in the USA has been recommending FAPI for a long time, same in Canada. There's a health-based ecosystem in Norway that's using FAPI. This isn't just for financial use cases. You can use FAPI in any case where you need that higher security level of OAuth. And that's one of the reasons...
So in that sense, it goes back to what you said earlier that it was called FAPI at the beginning, but right now it's bigger than financial services. So it became, in that sense, a bit smaller. So the very ambitious goal at the beginning probably was a bit too audacious. Then it became a bit smaller, but right now it's growing beyond the financial services ecosystem.
Yeah, exactly. So we are seeing a lot of adoption in any cases where, you need that higher security and interoperability. And that's very much why it doesn't stand for anything anymore. And we've kind of tried to remove it for a little bit. It was even called financial grade API, just trying to say it's, it's financial grade, but you can use it for non-financial use cases. But even so people in the market still seem to think, that must be for banks then it's not applicable for health. So that's why we ended up with it's not standing for anything at all.
Yeah, I think we maybe need to differentiate between financial and financial grades. Financial meaning, it's really for the financial services, while financial grade means it's a really good and strong one. So where does then, we started a bit with OAuth and OIDC and then moved to FAPI, but maybe you can give a bit more background on how OAuth and OIDC then relate to FAPI. So what is the interplay here?
Yeah, so FAPI very much builds on top of OAuth, so it's completely compatible with OAuth. If you're using FAPI, you can very much say I'm doing OAuth. And what FAPI really does is it takes that OAuth standard, which is 10 years old now, and is very prescriptive about this is how you do client authentication. This is how you do sender constrained access tokens, just pulling all those things together so that you've got an out of the box recipe basically for how to do secure OAuth and interoperable OAuth. So it's just, it's almost like a checklist that's very easy to follow and covers all those latest recommendations. So for example, it's fully compliant with the security best practices document that comes out of the OAuth working group at the IETF, which is otherwise a 50 page document that you need to digest and somehow take action on. And then for OpenID Connect, that's an optional layer that in FAPI 1.0, it was actually required, but in FAPI 2.0, we were able to simplify things and keep the same level of security without requiring OpenID Connect. OpenID Connect is there. It's a part of FAPI 2.0. You can use it. You don't have to use it. You would use it if you want to do that authentication side of things that OpenID Connect is very good at. So for example, if you need the user's identity information, essentially you would use OpenID Connect.
Okay, got it. So what are - I think we touched a bit there, the business value in having a standards-based interface with financial grade. But let's say more concretely, what are the concrete business cases, use cases and business values for banks and other financial institutions in using FAPI?
Yeah, so I mean, in a lot of cases, it's actually the regulators that are looking at the open banking ecosystem overall, seeing that they want these ecosystems to scale and for the fintechs to have an easy life. And they're just telling the banks, you have to do FAPI. Obviously in the US, things are a little bit different. There's a bit more of a market led initiative. So you do have different incentives there. And the way we're really trying to think about FAPI is that it does just make life easier for everyone. So for the banks, there's a whole bunch of vendors that have already been certified at the OpenID Foundation as being FAPI compliant. So you can buy their software and you can pretty sure it's going to work and be FAPI compliant and interface correctly with everyone else that's doing FAPI. So that really ends up kind of lowering the burden on your support desk because you're not having to answer basic questions about how your OAuth stack is configured. You take FAPI on both sides and things should just work.
Okay, so it's at the end of the day, the advantage is that you can build all these new types of application services, etc. with caring relatively little about the complexity that is behind OIDC, OAuth and so on by relying on FAPI. And also having, I think this is very important point, also having a certification scheme in place so that you know, okay, these ones are certified. You can probably rely on that certification and have a lower project risk at the end of the day. I think that the logic is very clear. This also makes sense for other types of organizations, not just banks. Even while banks in some regions, as you pointed out, benefit from the fact that regulators are driving the usage while in other industries, it's probably more sort of led by the business case and that someone takes the initiatives and just driving it like you mentioned the healthcare use case previously. So you're working at Authlete, you're the CTO. Where does Authlete come into play when we talk about FAPI, but also when we talk about OAuth, OIDC, so OpenID Connect? So what's the role of Authlete in there?
Yeah. So Authlete is essentially providing a set of APIs that lets you build an authorization server. That might sound a little bit unusual because I think we're the only people in the market really doing that. Other people want to sell you an authorization server and then you kind of get some limited customization of that authorization server, probably using one particular SDK and programming language. So Authlete really flips the model on its head. It puts the developers at your company in control. They develop the authorization server. Authlete does all the heavy lifting in a backend on all the standards space piece. And your developers focus on the user experience, the things that are specific to your company. And they can do that in whatever programming language they want, basically. you know, it's a set of REST APIs you have to call for Authlete. So you can use your developers' preferred programming language that they're very much at home in.
So basically, FAPI already simplifies a lot and Authlete then delivers services that, so to speak, first simplifies that part, which is, as we all know, very specific. So that developers really can focus on the business processes, on the user experience, on the business use cases, on that part of functionality of their solutions.
Yeah, exactly. And I mean, the real advantage of Authlete is that once you've kind of done that basic integration of OAuth and OpenID Connect, if and when you want to add FAPI in, it's just a case of tweaking a few configuration options in Authlete and providing a key or two. It becomes a very simple uplift. So what we also see happening beyond this is we see a lot of stuff happening around decentralized identity and verifiable credentials. Is this also something you have on the radar?
Yeah, definitely. So I mean, actually, one of the standards I work with is I'm actually one of the co-chairs at the Digital Credentials Protocol Working Group at the OpenID Foundation. So I work with Torsten and Christina there defining the OpenID for issuance and OpenID for verifiable presentation standards. So we've been very deeply involved in that for a while now. We actually just released Authlete 3.0, which has support for OpenID for verifiable credential issuance and lets you issue SD-JWTs or mdoc format credentials very easily. So yeah, we absolutely see that as an upcoming area that we're focusing on.
So you're opening up, in fact, that system to this new evolution at the end of the day, your customers don't need to care much about technical details. And also at the end of the day, this evolution, because Authlete helps them, so to speak, this complexity.
Yes, very much so.
Okay, anything else you'd like to add around this topic of FAPI, OAuth, OIDC, verifiable credentials and Authlete?
Yeah, I mean, think the current times are very exciting for all of these technologies. So obviously, with FAPI, we just keep on seeing more and more regulators adopting FAPI, and more and more ecosystems adopting FAPI. So for example, I mean, Brazil did a very big rollout of FAPI in their open banking two years ago. They very quickly then expanded that to open insurance and are now looking at other industries as well. you know, they've very much moved from being one of the slightly late starters in open banking to really leading the pack on open finance completely. And then with verifiable credentials, it's obviously a very exciting time around Europe with an awful lot of activity going on around the EUDI wallet and just European credentials becoming available as these verifiable digital credentials within two years. That stuff should all be in users hands, which certainly is not going to be an easy journey to that point, but it's a very exciting one and yeah, one that we're very much taking part in.
Joseph, thank you for all the information provided. This was very insightful, very helpful. I'm absolutely confident that it helps everyone to better understand this set of standards and technologies that are so essential for building digital service in the digital
Yeah, it's been great to be here, Martin. Thank you.
