Transforming APIs from Endpoints to Business Products

Well, hello, and welcome to another KuppingerCole webinar. My name is Alexei Balaganski. I'm the lead analyst here at KuppingerCole, and our topic for today is Transforming APIs from Endpoints to Business Products.

Today, I am joined by two guests. The first one is Jacob Ideskog, who is the CTO of Curity, and the second one is Elisabeth Falck, who is the Head of Digital Business Enablers at If Insurance. Before we jump into the topic, however, I have to give you some housekeeping rules. So you do not have to worry about your microphones. You're all muted centrally.

We are, in fact, not planning any polls today, but we do have plans for a Q&A session at the end of the webinar. Please enter your questions at any time during our presentations in the control panel of this application you are using now. And of course, we are recording everything, and the recording will be published tomorrow, along with all the slide decks, and everybody will get a link to watch them and download. Our agenda for today is fairly straightforward.

I will start with a kind of a strategic overview and introduction into the whole notion of APIs becoming digital products instead of simple developer-oriented tools. Then I will hand over to Jacob, who will be talking about the identity and authorization basically becoming the critical and crucial foundation of any API economy. And finally, Elizabeth will give you some practical insights and views and recommendations on how do you actually turn APIs into products.

And again, as I mentioned, we will end up with a questions and answers session. So yeah, we are living in interesting times. And you know, some people call it the Chinese curse. I would call it a time for new exciting opportunities. You never know where you win, where you lose, but what we do know is that our society is now increasingly becoming digital thanks to all the recent developments such as multi-cloud and mobile devices and software as a service and collaboration suites.

Basically, all the business nowadays is done online, digitally, and there is absolutely no notion left of our once existing network perimeter. We are all exposed to a huge sprawling web of systems, devices, applications, workloads, you name them. And anything in that sprawling web can be a weak point. And the biggest problem is that that weak point can bring down your entire digital economy if not implemented, operated, and protected properly.

Of course, we cannot ignore the elephant in the room, and I promise it will be the last time I mention it, but generative AI is a huge changer. You know, it could be a call we've been tracking and observing API economy and API security markets for over a decade, and it's been a huge difficulty for us to explain that APIs are not, in fact, just a technical term, it's a business thing. AI changed overnight. Now everybody wants to become an AI service provider, and of course, for that, you have to expose your data, your systems, your services, and of course, you do it through APIs.

So everything now has an API. Unfortunately, too many things now have APIs, and if you are not designing and managing them and securing them properly, your API ecosystem, if you can still name it like that, becomes a fragile mess, and again, one exposed and improperly controlled endpoint can compromise everything.

And even if you have never thought about this from the technical or business perspective, at least you have to think in terms of privacy and compliance because that is something which influences us all, especially here in Europe, in the European Union, but well, this is something you have to deal with at any time. Again, your digital data, you probably heard a lot of terms used for this, like it's your crown jewels, it's the new oil. I would only say that there are hundreds of ways of losing your crown jewels, of exposing them improperly, but only one way to do it properly.

There is only one way to monetize your data, your, again, crown jewel securely, it's through APIs, because APIs are basically the delivery channels for digital products, and digital products is what your business is probably doing today, even if you don't know it yet. And again, you have to consider that the data isn't actually the product, it's the business logic, it's what you do, it's how you transform and derive value from data, it's what you actually be able to monetize in the end, and you are usually doing it with APIs.

I always like to think about it as what Netflix did to movie piracy some years ago. They did not stop people from downloading illegal movies, they built a better experience, with easy access, with fair pricing, and with built-in copyright protection, and that basically killed movie piracy overnight. So be the Netflix of your digital assets, because if you won't, there will be tons of foreign trackers and pirate base, and other malicious actors out there who will steal your data, scrape your web, and basically do anything with all that crown jewels, including trading AI models.

And again, I swear this is the last time we are talking about AI. So yes, APIs are basically business logic in motion.

Again, I personally like to compare data with air, not oil or jewels or anything like that, because you can put your crown jewels into a safe, but you cannot put air into a safe. If your scuba gear, if you will, do not work properly, if your business doesn't get enough air, you start to suffocate, your business processes start to crumble down, and well, you get out of business very quickly. It's basically everything in nowadays digital businesses is powered by IT, and everything in IT is mediated by APIs.

You can only say one thing, APIs are your critical infrastructure, APIs are, again, your scuba gears, if you will, and of course, as any kind of critical infrastructure, they are your top attack vectors, or attack vector for malicious actors. So APIs basically now define your business competitiveness, but also they define all the risks and challenges and complexity that can easily break down your entire business prospects. And the only way to continue, as I mentioned, is to ensure that you deal with APIs as with critically sensitive digital products.

That's the only way that scales, the only way that actually generates return of investment on APIs, if you will, because again, if APIs fail, the enterprise fails. Unfortunately, what was promised to us as a simple alternative to all those pre-existing enterprise service buses and other standards, the RESTful APIs turned out to be a tiny part of the entire API complexity ecosystem we now have. First of all, we have tons of different protocols, again, REST, GraphQL, gRPC, streaming protocols like Kafka.

Anything is now basically an API because whenever you involve an endpoint, which is not entirely human, it can be your mobile phone, it can be an AI agent, if you will, or anything else, they have to speak a specific language. And unfortunately, we have a multitude of those languages tuned for different industries and use cases. Even worse, we have extremely fragmented deployment environments. We have multi-cloud APIs, we have hybrid deployments, we have edge deployments, we still have some legacy on-prem things working in your basement, some old forgotten mainframe, or just a printer.

All those shadow APIs and zombie APIs are no longer a potential thing to generate you any income, but they are huge, keeping hold on your security. They are basically a digital equivalent to a secret passage to your castle, or even a huge keeping hold in your castle wall. So we have to deal with all those things. And the only way to start thinking about those things in a way you can actually quote-unquote sell to your board is to present them as enablers, as business products.

It's something which you turn into profitable and useful thing that will generate a return of investment for everyone in your enterprise. Now, organizations that succeed should treat APIs as offerings complete with anything that a digital product traditionally comes with, documentation, onboarding processes, observability, and success metrics, monetizations, of course. So this is what differentiates a traditional view of APIs as technical interfaces from, again, the modern one of treating them as products.

As I mentioned, API security is something that we at Kubernetes Core have been tracking for over a decade. I have recently published a leadership compass where we compared about 2,000 of API security vendors, and Qwerty was one of those, by the way. I won't dive into any details. You are very welcome to visit kubernetescore.com and watch some of the recordings, read our papers, and we will link to them by the end of the webinar. My kind of biggest point to you today is that security done right is not just stops to be wasting of your money.

It actually becomes a growth acceleration point, if you will. You have to stop thinking in terms of security being a lock on your door, but instead a set of controls to ensure that your business processes work as intended, as smooth as possible, and of course, they will provide you the necessary level of compliance. And when you actually start thinking of APIs in terms of business revenue, again, it becomes much easier to sell this to your boards and to get more investment into designing proper API security and API operational and management and observability architectures.

So basically, API security solutions are the foundation that enable you to make your APIs delivered as products with agility and security necessary to basically start doing it without any compromise. And of course, one of the key points of this whole security foundation is identity and access management. Identity is what turns endpoints into trusted business interfaces.

And again, kind of the way how you deal with identity and access management for your APIs is where the tail is. How do you build this architecture to make sure that your APIs are treated as business critical interfaces and at the same time as convenient and easily consumable and monetizable business products? This is where you have to find this fine balance and this is where you have to look out for proper solutions for that.

Basically, I wanted to highlight that you need continuous authorization and fine-grained access management, obviously. There is no security without that. You have to support passwordless and verifiable credentials if you want to actually expand your API consumers to be not just machines, but humans as well. And of course, you have to offer unified identity coverage across all the ecosystems you are operating yourself or connecting to through your partners or contractors, suppliers, and customers.

So again, API security is impossible without identity. I mentioned the Leadership Compass.

Again, feel free to check out my earlier webinar where I spent 45 minutes talking just about that. But the key takeaways from that Leadership Compass were that we have identified eight foundational capability areas where we believe API management and security solutions have to be acting and providing all those capabilities to the customers. API security is clearly converging with identity and access management and data protection because those things are just impossible to orchestrate without tight integration and standard support and proper workflows.

Although we have seen a lot of vendors which only cover just one or two of these capabilities, we do see the tendency of those vendors collaborating or maybe sometimes even just acquiring each other to ensure that they can deliver a unified API fabric. The fabric being a lean combination of all those separate tools which can work in accord, which can work together to deliver more value as a standalone point solutions.

Of course, compliance and observability are top investment drivers. But again, if you can do better than that, if you can turn your APIs into actual monetizable products, of course you will win any competition. So API market is moving from tools to platforms. What is your danger? What's your risk if you are not keeping up with all these developments?

Well, APIs are your new supply chain. Do you want to be the weakest link in the chain because again, you have to collaborate. You have to work not just with your customers but with your partners, contractors, third-party suppliers. This is basically like connecting multiple fortresses with a huge chain.

And again, if only one link in the chain breaks, the entire ecosystem fails. We know from some studies that API breach can cost 10 times more than a typical data breach like the one caused by ransomware, for example, or stolen credentials. Think about it again. Your API can be a gate to someone else's fortress or someone else's.

Again, broken API can be a backdoor to yours. So my final takeaway for you, if you will, just reiterating, the strongest fortresses are not those which keep attackers out. They help allies come in.

So again, kind of stop thinking in terms of perimeters, walls, think in terms of stronger, smarter gates. Let the innovation flow. And with that, let me just give the stage to Jacob, who will be explaining in more detail how they can help you doing just that. So I'm gonna start a little bit with a look back in history because we're talking a lot about APIs now, and there's a good reason for that, but there's also a good reason why we started to talk about APIs back then.

Obviously, it started way before 2008, but this is kind of the kickoff point, I would say, for APIs. Because in 2008, something happened. Apple released the App Store, and as people were starting to build mobile apps and realizing this is an excellent place to interact with your customers, you also realize, hey, we need this thing on a device we don't control to actually get data and work with the services that we provide. So we need to build APIs. And that kicked off a really big shift in becoming platforms as companies.

This also introduced a bunch of new problems because you have the API belonging to one organization, you have the user who had services at that organization, and then you have the app who ran and perhaps was written even by third parties. And you needed these to connect. You needed the user to be able to access the APIs via the app, and that led to discussions like how should this be solved? We don't want the app to see the credentials of the user and so on. So a lot of discussions went on back and forth and some protocols emerged.

And 2012 was a big year for that because that's when OAuth 2.0 was released. It is the primary protocol that can be used to do this type of mechanism where you secure APIs, you provide an identity layer atop, and you can also separate the user's credentials and access and login from the app that it actually needs to access the APIs. OAuth 2.0 was important because it was so much easier and simpler than any predecessor that had been out there before. It solved the problem a lot faster and with fewer lines of code for the developer who needed to use it on the client side.

And this led to a new shift again. So companies at this point, at 2012, were starting to realize, hey, we really need to become platforms. Like Alexei was saying, we have all this air, we have all this oil, we need to monetize that, we need to use that for new types of services, we need to have an omni-channel presence, we need to have partners work with this thing, and we need to cross the chasm of being just an internal focused company to actually thinking how do we expose ourselves? And that means not only turning on APIs, it means turning the entire organization into a platform.

And some organizations did this really quickly, others are still struggling and are at this point today. But it started off around this. This is also around the time when the term microservices started to show up because it really showed, like people are thinking about this, we're trying to address these problems on architecting organizations as platforms. Jumping ahead a little bit more, 2015, just to mention in this, this is where Qwerty started, we built the identity server to provide this identity plane.

And the reason that this whole identity plane started to show up for APIs, as I mentioned, was because we had all these APIs, but we also had all these users that needed to access these APIs. And those were different from what we were used to before. If you look at identity and access management, you can split it in two big boxes. You can think of internal or workforce IAM, which is to the right. And you can think of external IAM, which sometimes is called SIAM, if it's only focusing on consumers and a small part of it.

You also have the B2B side or the partner IAM in there, but it's a pretty big area. And in many organizations, it's actually a bigger area in the terms of work and people doing work in it compared to the workforce IAM. Interestingly, on the external side, that's where we have all the APIs that we build, the homegrown applications that we use. We have all the external users connecting in. We have custom user management for those because we have our own flows for how a user is onboarded in our organization versus your organization.

That's where we deal with partner integrations and how to onboard partners and their users. And we don't necessarily think so much about groups and things like that. We have other types of entitlements in the external identity space, things like which products can you access and other things like that. So in contrast, the internal one, there we connect off-the-shelf applications. We federate more. We use groups because we came from Active Directory and it's quite different. So there's some overlap, but not a whole lot.

And this is good to keep in mind as we progress also into the space of AI where a lot of the things we'll do will end up close to the APIs, close to the homegrown stuff, close to the partner and external user things. So it's good to be thinking about this separation already. If we jump to this year or at end of last year, I think we see another chasm. The MCP API spec or was published last year and made open source I think even in November last year.

That really made a shift in the whole enablement of agentic and AI tools because an AI or an agent is not super useful if all it has is the data it was trained on, the memory it has, so to speak, or the knowledge. Once it starts to access external tools, it starts to become really useful. We can ask it to do things for us, buy things for us or sort things in a marketing database or whatever we connect it to, we can teach it, hey, here's a tool for the thing that I'm asking you to do and many tools usually.

And the MCP type API is the enabler of that because that allows organizations to publish themselves yet again as a platform, but for AIs. So quite different this time, but still the same. And as we start thinking about building all of these or probably are already in the middle of building all of these, we need to fortify ourselves. If you haven't done this already, it's urgent because if your API infrastructure isn't Fortress, you're in the risk of a lot of damage. So what do I mean by a Fortress?

Well, I'll talk about it a bit more over the coming slides, but essentially you need to be controlling the entire environment you have, making sure you know what's in there, making sure you can handle the stuff that you publish because all the mistakes that will happen there, they're yours. So you have to take control over that process. But also a Fortress means you can control the progress inside it and the development of things in there.

So building those is necessary and hard because if we look at 2012, when I said OAuth came out, there was two, three, four specs that year in OAuth explaining how this should be done. Now we're at at least 101 specification in this area, targeting different areas of API security, user security, federation, how to connect identities between systems and moving into the new decentralized identity space with wallets, proving identities and all of that. It's huge. So it's pretty obvious we should not be brewing security on our own. We need to look to the experts on these things.

So let's talk about the Fortresses because if we build a really good Fortress, we have a good chance of actually providing value and not risk. Because like Alexis said, there's a pretty big risk associated with API breaches.

In fact, studies show that it's 10 times more costly to have an API breach than traditional data breaches. So this needs to be really thought through. And there are no studies yet on what the risks or costs are associated with AI related breaches. So that one can only imagine, but it's likely gonna be even higher. So what I really wanna talk about is not Fortresses, but Tents. Because if we build a Fortress, but then we hand off security to something else, something outside our organization and trust that they do the right things.

What really we did was just hand off security to someone who perhaps only has a Tent. And we say, here's the keys to our Fortress, just protect it. Not a great idea. What do I mean by that? I'll give you a few examples. So say that someone in your organization builds a pretty successful API, and you connect it to a bunch of applications. The finance department uses it, the marketing department uses it, other departments use it, because it's useful. And that's the dream of every API developer, trust me. So as time goes, you start to look at the news and you start seeing these things.

Risk, token compromised. Because credentials ended up where they shouldn't be or tokens ended up being snatched from places that weren't in your organization, it was elsewhere. And these are new type of supply chain attacks. Because if your partner is compromised, and that leads to a data breach in your organization, who do you think is gonna get the blame?

Is it you, or is it the organization that was breached? Well, it was your data, it was your services that actually leaked. So it doesn't really matter where the breach happened. So this is serious. Because your API is part of the new supply chain. Your fortress needs to be opened up for your partners or customers and applications that are outside. And we can do this by protocol, we can use OAuth and tokens in there.

But if those aren't used correctly, an attacker might not bother to attack your fortress, they could just attack that vendor instead, because that was easier, the mistake was done over there. In the history of protocols, essentially, this has happened many times, and it's not unusual.

I mean, one of the most prominent attacks like this happened really early, I think it was Facebook that logged certain tokens in certain apps, and those could be fetched and stolen by other applications because the security wasn't that high by then, and someone could access the data on someone else's behalf maliciously. So again, who gets the blame when this happens? Think about it. The API holder, the data holder is ultimately the most responsible for the security of that data. It's your customers you made the promise to to keep that data safe.

So a couple of these tents I'd like to talk about today are two, there's web apps, in particular, single page applications. When building single page applications, you don't have a back end. So you use the browser to run a bunch of code in the browser, and the browser just calls APIs directly. It's called using cores. It accesses APIs on different domains. And in order to get OAuth tokens then to access these, which most do, those tokens have to end up in the browser. And where do you put those?

Well, there is no safe place to put them because JavaScript needs to access them. So you put them wherever it makes sense. On the web, the most common attack is called cross-site scripting. And cross-site scripting is when you have your JavaScript running, and it's a lot of it because it's an application doing something fancy. And an attacker somehow gets its own JavaScript injected in there, that's cross-site scripting.

And what they can do with that, I'm not gonna threaten you with code here, but just to prove a point, these two lines of code essentially takes all the things that are stored in the browser as local storage for that site and sends it off to a malicious website, which could include the tokens that could access your API. So essentially opening your fortress. And any site today that you build with common frameworks like React and Next.js have a lot of dependencies.

React, Next.js, 360 dependencies without even building anything yet. This means someone else's mistake could end up on your website causing these things to happen. So we need to recognize that the browser is a hostile environment. And we need to force integration patterns. So it's not possible to make these mistakes as partners. There are good patterns to prevent this. In this particular case, you could use the token handler pattern or backend for frontend pattern, it's also called. That will prevent this. You cannot, as a partner, get this wrong if you force that pattern.

So as an API vendor, you can actually apply that pattern and say, this must be done. You won't get access otherwise. The other tent I wanted to mention is the AI agents. Obviously they're new, they're autonomous, they're non-deterministic. They give us a lot of stuff to think about because we're used to applications that we can hand off some trust to and it will do what it did last year, this year as well. But an agent, we don't know. It may not do the same thing based on the same input the second time you ask it. It could do different things.

So when it needs access to an API, in this case, it needs access to the tool. We need to think like, how does this work over time? It's a new angle that we need to consider because normally you would provide access and say, you can do all these transactions for me at any time. But as an agent evolves and as you ask it to do other things, the context changes and it might not come to the same conclusion, so it could cause damage. So you probably want to gain more control. So you need to consider like, what assets can this agent access? When is it always, or should it be per need?

Do you need to be in the loop of that and manage that? Other questions we need to answer are, who is the agent acting on behalf of? Is it itself, like a system user back in the day? Is it acting on behalf of a customer or an employee? Important questions because that can help you govern how you should give it access and when. But more importantly, we need to maintain control of the access outside of the agent. Because as with APIs, if we just hand off the control to the tent, we don't know if they're going to do the right thing and access is going to be breached for us.

So we need to do the same thing, keep the same paradigms when we build MCP APIs for agent access or if we expose agents as APIs to others, we need to make sure that we control the access and not the other side. So the MCP API is the natural place to enforce this, the gateways in front of it together with the API code in it and make sure the AI is not the one who decides if it should have access or not at this particular time.

Luckily, this all works. If you do use OAuth properly and use the advanced features of it, you can achieve a lot of this access control already today and make sure it's safe. You can even go further and make sure the access is dynamic. So when you issue certain access to the agent, it actually gets high elevated access in the beginning when the human was there, it diminishes over time.

And if the human, if it needs to do something advanced, it needs to request more access from the human and you can involve the human in the loop again to approve that access or consent to that access depending on what structure you have. So it's possible to build these things very dynamically with the tools we have. So make sure your integrations with your platforms are done right because they are as critical to security as the platform itself.

Use the protocols and patterns that force you to, force your integrators to protect your data in the right way and keep control over access at the API side, not the agent or AI side or the caller side. So I'll hand over to Elisabeth.

Thank you, Jakob. I'm here from IFPNC Insurance. We are a happy security customers. That's why we are presenting here today together. And I will explain a little bit more how to succeed with your API in iName strategy. And there are two main takeaways from this session is that you need to treat your APIs as products and you need to keep your API and iName domains close. So that's two takeaways in place. So who am I to talk about this? I'm Elisabeth Falk, I'm head of digital business enablers in IF. It means I'm overall responsible for APIs and also external iName.

I brought my gardening tools here today. And that's because we have an agile way of working in IF. And as a tribe lead, I'm a servant leader. I try to keep our garden in place of the great tribe that we have. It's called I'm Happy, notice the word play. And we are responsible for APIs and iName in IF. And it's around 50 people that is working on this area and that is behind the success story I'm here to tell today. Pinkies. So this is IF for those of you who do not know us. We are owned by a sample group. We are around 10,000 employees.

We are the largest property and casualty insurer in the Nordics. We're number one in terms of market position. We work across private, commercial, industrial and Baltic areas. And we have around 4.5 million customers. Headquartered in Stockholm, the CEO is Martin Kroshe. And we work with different type of insurances. But we have this digital vision and that is to be the most caring digital insurance company. And how to achieve that being caring in digital. It's actually got a lot to do with APIs and also iName. Pinkies.

So iName, Identity and Access Management. I assume you know what it is. But that enables us to know who the customer is across all channels, both our internal channels but also external channels. And then we can ensure access to what she's entitled to. And then we have the APIs, Application Programming Interface as Alexei has presented for us earlier. So I'm not going to dive into details but they enable us to be very customer side in digital with data and functionality. And then in the middle here is the human because people will always be most important asset we have got. Data is the second.

Pinkies. Then iName in a little bit of a nutshell because this is important to understand the difference in the different type of iName areas. So imagine you're checking into a hotel here and then we have identification. Who are you in real life? And that's something you will typically present to the receptionist here. You will come and say, hello, my name is Elizabeth. I would like to check into this hotel. And then the receptionist will say, well, can you prove that you are who you say you are? And then it's authentication, right?

So then you will typically present your passport or driver's license and prove that you are who you say you are and then identity management. That is more about what do you mean to us? So the receptionist will then check the records, check that, for example, maybe you're a member of a loyalty program, which room you have booked, what you mean to this hotel and all the attributes stored on you as an individual is very important. And I'll come back to that a little bit later. And then e-signing and consent is around, can we agree to this?

Can we agree to that you're checking in, you're staying for five days and maybe you'll sign that we can treat your or process your personal information. And then last but not least, authorization, which is the hardest part of I&AM. And it's something about what you're allowed to do. And in this hotel experience, it will be like, you get the key card and you can access your room and the training facilities, for example, for exercising, but you cannot access the kitchen area nor the staff area, right? And maybe you have a rule that after 10 o'clock at night, you cannot access the spa area either.

So authorization is using the attributes in the identity management system and also other attributes and signals from different systems to determine what you're allowed to do and not. So important to understand the difference in this and also important to understand how APIs can enable this.

So ping, please. Because the I&AM area and the API area are very much interlinked. As I explained, the different I&AM solutions we have for employees, customers, and partners, they need APIs actually to enable self-service and governance. For example, an application that is to implement a certain authentication method, let's say it's a bank ID in the Nordics, they can then use an API for that, right? And also the other way around. So the API platforms, the developer portals, all the APIs and also the applications, they need I&AM solutions.

So these areas are very tightly connected and if we treat them closely together, both in terms of how we work with them, but also in terms of the platforms and how they're integrated. Ping, please. Because IF has got very modern API and I&AM platforms to enable the open data era. And of course, it started out with feeding our own channels with APIs and also I&AM in order to be fast and have sustainable development. And it also enables our partners' channels.

So if Pins Insurance has got thousands of partners throughout the Nordics, and we are integrated to multiple of their channels in order to everything from ensuring insurance distribution, which it's very much a direct revenue source, to more indirect, for example, being in a workshop when a dealer is about to, for example, handle a car crash and a related claim to that, then we can ensure that the customer gets the right information at the car dealer site and do not have to reach out to IF directly. So we're making a lot more smoother customer experiences.

We were also the first insurer to have embedded insurance into car ecosystem with Polestar and the in-car app we have there. And then also third-party channels. As you know, European Commission is about to publish financial data access regulation, FIDO. It's like PC2, but for the whole financial industry. So not just for banking, but also for insurers and pension companies and crypto companies. And we need to prepare for that. And we are, of course, using APIs in our name to do so.

And as I said, our name then is HERE to ensure that we know who the user are across all these different channels, both our own channels, third-party channels, and then our partners' channels. And as I said, initially, one important takeaway here is treat APIs as products, really.

I mean, products like, you know, Marty Kagan type of products and how it's defined there. Not just as an afterthought, but really ensure that you have ownership, that you ensure that the APIs delivers value to a certain group of users. To a certain group or individual. Ensure that it's reusable. Ensure that it can be handled, you know, end-to-end in terms of lifecycle management, all the way from when you start your business modeling canvas to figure out who are we providing this to, to the very end where you will typically sunset the product. So that's the recipe for success.

Ping, please. And I think it's good to sort of reflect that a product is actually anything that solves a specific problem or fulfills a need for an individual or a group. And here I brought the boat because I think it's a very good way to explain, you know, a boat is a product that can take you from A to B. It's made for, you know, people that love boats, in this case, a sailing boat, and also need to cater for delivering needs to both the person driving the boat, the captain, but also the crew, and they have slightly different needs, right?

You can have add-on products like navigation systems or whatnot. And I think we need to think the same around APIs. So what will this API do? What is the primary value it provides and for whom, right? And then also how this is owned and how the lifecycle is managed. Very much like a physical product, even if it's obviously a digital product.

Pink, please. So in order to apply then these product management principles, you need to use proven product management practices, right? You need to plan your product.

As I said, typically business modeling canvases, you know, the Auster-Wendler framework. You need to then implement the actual product, often that goes a bit in cycles, and then operate and then decommission. So it's got a lifecycle, right? And if you look to the middle here, we have all the different API contracts because an API product can consist of one or multiple endpoints, right?

So it can be, for example, a combination of different APIs, like saying, for example, get a quote and buy, or it can be just see engagement, for example, if you want to view your insurance engagement, which is a common use case in IF. And it's important also to remember that the products need customer service. So customer success managers need sales, right? Go to our partners, go to our enterprise customers and explain the value that this API can provide. And there are of course legal agreements related to that, sometimes pricing, but often it's indirect revenues.

APIs is typically glue to make partnerships work. And then when it comes to also customer support and incident handling, so you need to have proper processes for what happens if there's something wrong with APIs not working, for example. You need problem and incident management, just, you know, IT processes. It's used for any other products. You also need to have very clear processes also for your APIs. And then documentation should never be underestimated. Document everything in both for business developers and for developers. So remember both dimensions.

And reporting, it goes from everything from API traffic to actual, for example, how many sales did this API provide? So you need to look at reporting from different dimensions. And then data protection. So like Jakob said, we don't want to create a fortress with the security of a tent. So you need to really protect your APIs and also ensure that the ones consuming it is handling, for example, the credentials, the OAuth credentials in a proper manner, and that they're, for example, using a key vault and not just having the credentials in a repo somewhere. Yeah.

Ping, please. So at IFTTTM, API products can be ordered from us just like insurance products. So we have used the same principles as we have for our core products, which is insurance. So that means that you can read about our APIs. You can see the unique selling points. And that means that it's for business developers and partners. It's for attracting the customers of this API. And we do it both internally and externally in the exact same way. And then it's important to think about this as our digital assets. And as you said, Alexia, initially also, that it's the gold, right?

That we have, or the oil, or the air, or what you want to call it, that we productize for those that are to use it. Ping, please. And our API products are available in our developer portal. And here you can see the developer portal has sort of got some different dimensions to it. It's all about the sales and marketing. And then it's more about the developer experience also, that the APIs are properly documented, both the requests and the responses, and also what type of OAuth flows are used that we can explain.

This is how you manage, for example, OAuth with the client credential grant, or this is how you manage with the cold flow. And also that when a partner or API consumer is logged in, it's possible to manage all the different applications. Maybe it's multiple, right? That will consume multiple APIs. So it's important to have inventory control and control of which applications do you have in both test and production, and which APIs will the different applications have access to, and then make it easy for the API consumer to be a customer, right? Like it would with any other service.

Ping, please. So API platform is the heart and the brain behind, obviously, the developer portal and the whole API product thinking. And it offers a capability to manage APIs and also events, which is asynchronous APIs as products, and also lifecycle management from the very initial deployment in test to the very decommissioning stage. And it's important to have the self-service to enable that. And it can be consumed by different consumers. It's important for us, at least, that we have the same level of quality, both internally and externally. So that was why we try to use the same principles.

I-Name and security is, of course, very key, and Qwerty is integrated to our API platform. We can also manage Qwerty clients, for example, there. And then also self-service for developers. It's extremely important to be able to self-serve, go through everything in a self-served manner. And then there are, of course, some manual checks, particularly when it comes to security and I-Name.

So yeah, that's needed. We need self-service to scale, but we also need to have some checks to ensure that we don't create the fortress with security of attempt. Talking a little bit about the partner dimension. So partners do no longer ask us first, what's the provision to sell insurance? That has historically been important for many partners, but they rather ask, where are your APIs? Because they want to create good digital experiences for our joint customers. So it's a ticket to play. You will not have a lot of partners if you do not have APIs. So it's a product that our partners expect.

And here are a few selected examples of some partners we have integrated to. And now more than 75 partners are onboarded to our API platform, and it's growing quite quickly.

Ping, please. So this is one example from Norway, which is the Norwegian Postal Service and their moving portal, where we have integrated content insurance. So when people are moving, it's very smooth to just add content insurance because that's something you need for your new apartment, for example. So we're caring then our customer side in doing so.

Ping, please. And then Viking, which is a subsidiary of IF, is managing travel claims on our behalf. They use a series of APIs to ensure that when a customer of ours is traveling and need help, then Viking can manage the call. They can ensure that the customer gets the support that she deserves. And also Viking can check the coverage, can check what claims exists, follow the status on the claim. So it's really smoothing the customer experience in our joint operation towards the customer share.

Ping, please. So how do we do this? It's of course the people, most important asset, doing the stuff. And then we use processes, very strict processes actually, to be able to scale our business. So that's about how the stuff is done. And then of course we have technology, what we do the stuff with. And with tech, we can automate processes. And with tech and people, we can also innovate. So I think it's a beautiful sort of trio which is needed to succeed with managing APIs as products.

Ping, please. So some trends, and I'll be rounding off soon. Passwordless authentication, such as Passkeys, is coming. And we need to support that in our identity fabric as well. Continuous authorization, which is really dynamic and attribute-based, like in the hotel experience I explained, is highly important, particularly now with AI agents coming. Verifiable credentials, with, for example, a UI digital identity wallet will be important as well.

And the wallet will likely offer some new opportunities for, for example, insurance information or coverages to be visible and easy accessible by customers, for example. And then API and INAM security is very critical, obviously. I don't think I need to explain that to this audience now. And we need to prepare for FIDA, financial data access regulation, particularly to our industry and the financial industry. And then APIs are also key to connecting large language model into our own applications and for enabling AI agents, as Jakob explained.

Wrapping APIs behind MCP servers to be able to serve the AI agents, both our own, but also our customers and partners, is going to be extremely important going ahead. I think that was it. Thank you very much, Elizabeth and Jakob, of course. Now we still have some time left for the questions. And I guess before we jump into a couple of questions we had from the audience, I want to make one kind of important statement anticipating some of the questions.

Surely some of the people will think, but isn't it exactly the same thing we are getting from a quote unquote traditional API management solution where there is a developer portal, you can go check an API endpoint, apply for a key, and this is it. Now you are part of the API economy.

Well, no, obviously. I mean, if there is like one takeaway you should get from this webinar, that's not enough. The whole point of what Elizabeth just presented is that you have to go beyond treating an API as an endpoint, as a developer tool, and turn it into something which, well, you can sell, you can market, you can support, and more importantly, you can get variable feedback from your customers and improve it further. You have to think that API lifecycle is just a small part of the actual product lifecycle in general, right?

And this is exactly where identity comes in as a huge key factor, because, well, when you're the only quote unquote identity you have is an API key, you don't get much context and business value from that. But if you know who are you dealing with, who are you actually doing a service for, it's a major boost for any healthy business relationships, if you will. And I guess we have to address the questions we have from the audience.

Okay, the first one is AI agents and automation are becoming part of many business processes. How should a company think of identity and access management and API access when users aren't human?

Jacob, I think you could probably tackle that. Yeah, sure, it's a good question. And interestingly, I think it depends on from which angle you come, if you remember the workforce versus external. Because if you come from the workforce angle, it tends to be easier to think of like, how do I get this thing that is almost human, but definitely not into my traditional workforce flow. If you come from the external space and think of this as an application like other applications and it accesses APIs, it actually gets much, much easier.

Because we know how to deal with applications, we know how to deal with delegated access, we know how to deal with system access and system user type of access. So starting at that point and building it up as this is an external entity, even if we build it on our own, we treat it in that part of our system. Then you have a lot of tools actually to manage this. Protocols are already there, the OAuth protocol with good extensions on it work for this. And you can be quite elaborate on how it access toolings and what permissions it should have when and so forth.

So I think that it's a modeling question really, like, where do you start? Start from the external identity side to model this and it will be much easier. And by the way, I want to attract your attention to the white paper we just recently published, which actually to a large extent answers exactly this question.

Like, are those non-human identities something special or is it just something we know already how to deal with, we just have to expand the coverage and apply some additional controls and principles on top. Yeah, if you need more information, please welcome to get to our related research.

Okay, next question is, is the developer portal self-built or is there a product that can manage both REST and event APIs? Interesting.

Yeah, so the developer portal that I showed is based on our CMS that we're using. As for my pages, it's a regular CMS. But we're using Microsoft Azure Apping for our API platform. That being said, we have extended the classic Apping with some of our own features.

But still, Apping is the main sort of gateway behind our developer portal. And again, I believe the question was, is not how the portal itself was built, but how you can actually scale and manage and to extend it to basically serve as many customers as you are already serving. So I guess that's where the next question is actually referring to. So you said you have 75 partners already onboarded. Do you feel ready to onboard 150 or maybe 75,000? Because sooner or later, with all those AI agents multiplied, you should suddenly have a completely different sense of scale and scalability needed.

Yeah, you need to ensure that it scales, right? And we are, for example, using Qwerty. And as I said initially, we have four and a half million customers, right? So we can handle that type of scale through Qwerty in terms of authentication. Then it's about making sure that we can also handle the scale of partners. I don't think that's currently any sort of limitations on that. We haven't come into any challenges, but what I can say is that when the traffic increases, it can be that you need to upgrade your API platform to being more resilient.

Maybe you need to have multiple instances, things like that, right? To ensure you can take the traffic. But currently, I don't see any sort of limitations in terms of numbers of partners. That hasn't been a challenge for us.

Again, I would say that from the technology perspective, all of that is already solved. You have the cloud, multi-clouds, if you will. You have automation that allows elastic scalability of your resources with Kubernetes and other stuff. The biggest question is how do you orchestrate and automate it to be identity-centric and identity-related? And this is exactly where solutions like Kubernetes come into play. That's the point.

Yeah, exactly. And that's key in these things that you also need to remember that external facing identities, including AI identities, they don't work the same way as your traditional workforce identity. The information you have of them is not necessarily in just one place. You need to be able to collect attributes and data from various sources to build up the identity that you can ship around. So scalability actually can become simpler because you can add redundancy and scale in the places where it needs to happen, which isn't all over the place.

And then obviously, you just need a fast engine in the middle that can collect them and sign this off, which is obviously something we do. But it's not all in that. It's a correlation of things. And that builds a better architecture, in my opinion. Right. And I think we now have time left only for one final question, and that's, yeah, so we have talked basically for an hour about convergence of identity access management and APIs. So why so many organizations still treat them as separate domains?

Yeah, I could go first on that, but maybe you should say something, Elisabeth. But I think it's tradition, honestly. We don't see a whole lot of organizations where there is even good communications between the two. But I think that will change. I think AI will actually force us to change that a little bit because the new types of employees, if you will, that get in here, that are agents doing things for us, they won't end up in Active Directory necessarily. They won't end up in the traditional authentication flows they use internally. So there'll be a natural mix and a convergence.

The gradient will change, so to speak. Yeah, I very much agree with you, Jacob. And I think it's historical reasons to normally I-Name was sort of concentrating on internal I-Name, which is normally organized in operations, for example, while API platforms and API are as more closer to sort of engineering in the digital channels and that part of the business. So I think it's historical reasons why the domains are often a bit further away from each other than close.

Right, well, that's exactly one of those traditions you actually don't want to keep longer because it only hurts your future business development. So yeah, and I guess this is exactly the right takeaway for our viewers to wrap up this webinar. Thank you very much, Elizabeth and Jacob for being with me today. Thanks to all the viewers current in the future ones and see you sometime later in another webinar or maybe even at one of our conferences. Thank you very much and goodbye. Thank you. Thank you.