The API Economy and the role of identity in API security with Marjukka Niinioja – Podcast Episode 20

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Spotify | Pandora | Email | TuneIn | Deezer | RSS | More

Let’s talk about digital identity with Marjukka Niinioja, co-author of API Economy 101 and Founding Partner at Osaango.

Why are APIs not just a technical issue, but a business issue as well? In episode 20, Oscar chats to API guru Marjukka Niinioja about the opportunities APIs can create, how COVID-19 has highlighted the need for digitalisation, the role of identity in API security and the importance of standards like OpenID Connect.

[Scroll down for transcript]

“You don’t need to have an army of coders, you just need to buy the capabilities as APIs”

Marjukka Niinioja is co-author of API Economy 101 book and founding partner and leading consultant at Osaango, a company specialising in API and Platform economy. Osaango has worked with several companies in Finland and abroad as well as public organisations to help them not only learn about the possibilities of API and Platform business models but also define their API and platform strategies and guide them in the implementations.

For links and more information visit www.osaango.com

Marjukka is also the “mother” of the lean, business-oriented and open APIOps Cycles method, creator of the open course about API Economy with Tampere University and the local organiser of APIdays Finland conferences.

Visit APIOps Cycles at www.apiopscycles.com and check out the API Economy open course at Tampere University at www.osaango.academy/courses/intro-to-api-economy.

For a roundup of APIdays Finland 2019, read Oscar’s blog – www.ubisecure.com/api/apidays-finland-2019/

Find Marjukka on Twitter @MNiinioja and on LinkedIn.

We’ll be continuing this conversation on LinkedIn and Twitter using #LTADI – join us @ubisecure!

Go to our YouTube to watch the video transcript for this episode.

 

[Podcast transcript]

Oscar Santolalla: Let’s Talk About Digital Identity, the podcast connecting identity and business. I am your host, Oscar Santolalla.

Hello and thanks for joining today. We will have now for the first time talking about APIs and the API economy and what is the relationship with identity. For that, our guest is Marjukka Niinioja.

She is co-author of the API Economy 101 book and founding partner and leading consultant at Osaango, a company specialising in API and Platform economy. Osaango has worked with several companies in Finland and abroad as well as public organisations to help them not only learn about the possibilities of API and Platform business models but also define their API and platform strategies and guide them in the implementations.

Marjukka is also the “mother” of the lean business-oriented and open APIOps Cycles method, creator of the open course about API Economy with Tampere University and the local organiser of APIDays Finland conferences.

Hi Marjukka.

Marjukka Niinioja: Hi. Nice to be here.

Oscar: Welcome. It’s very nice talking with you. So Marjukka, let’s talk about digital identity. And the very first thing I want to hear from you is what was your journey to this world of APIs and digital identity?

Marjukka: It’s an interesting question because it started actually about 20 years ago. I will never be older than 25 but still 20 years ago. Finland joined the European Union, and we were basically pulled as students from the university to build the European Union Agricultural Benefit Systems in Finland.

And one of the key things there was, of course, identity and we started – very ambitiously because we were young and stupid, we didn’t know that it was very difficult to do. So we started building a web services-based architecture and one of the key things for that was how to handle identities and it was a really tough school because we had to handle the public sector people, like the people in municipalities who made the decisions about the benefits and also the farmers and everybody else who were somehow delivering or handling the agriculture goods and supplies and everything else, and the animals.

So we even had to find out ways to handle digital identity for animals. That was kind of the more interesting part. So yeah, after that, I had been doing identity management and handling identity management as part of a SaaS platform and a big retail company in Finland, Kesko, which also had at the time operations in Russia and in Sweden and in some other countries and we had to even figure out how to handle the identities for multiple countries, multiple types of customers and also the staff and partners. That has continued.

Oscar: Sure. So, where were you working for in this very first project you mentioned?

Marjukka: There was an information centre under the Ministry of Agriculture and Forestry in Finland, and we were responsible for the IT services for all of the other government organisations and kind of area organisations within the forestry and agriculture and labour areas in the public sector.

Oscar: Yeah, very interesting story. A lot of what we’re going to talk about today is about APIs. APIs, at least the first time I heard about that, for me meant something completely technical and I know you talk about very different things related to business. But just to go to a starting point, how would you define an API? What is an API?

Marjukka: Yeah. So there are so many definitions but API for me is, of course, coming from application programming interface and that makes it sound very technical, and of course the implementation of it is technical. But we use this books and publishers allegory in the API Economy 101 book that I was writing and there the idea is that –which kind of makes it a business thing too– if you have a book, you would think that book to be an API, an interface to that knowledge and stories and things in the book.

So, for example, all the people and locations and things in the book. The API would expose those things in the book to be used anywhere and everywhere in other books, in marketing of the book and for example the publishers of books are right now a lot of times using APIs. For example, they are using APIs for calculating the ISBN code. They are using APIs for handling the logistics or buying the logistics for delivering the books. They have APIs for proofreading, translating, a lot of other things.

So, to be able to be a book publisher for example, you don’t need to know all of that. You don’t need to have an army of coders. You just buy all these features, these capabilities as APIs and that’s how a lot of things that we are looking at –these kinds of very successful platforms and cloud platforms–work. So, they are actually selling their capabilities as APIs.

An API can access a lot of different resources, a lot of different capabilities that the company can offer. So it’s not just a database or an algorithm or system, but also for example we have customers in the US where they are doing transcriptions of videos and audio files for example via API.

So, they take the audio in as an API call (API request) and they have their own system there that allocates those work requests to all those people, transcribers all over the world, and then they return their stuff on their platform and then the end result, the transcribed files are published, uploaded for example directly to YouTube via YouTube’s API, or delivered as a file to the person who ordered it.

So then for example if I am a provider, like they are providing services for Lynda.com or the American Heart Association or various other places, the company I’m talking about is Rev.com, which is quite known for these transcribing services. They are able to combine the transcribing service within their own processes and within their own tools, without having an army of transcribers.

So this is the kind of business side that we talk about when we talk about the API economy. So you can buy things, capabilities, data, algorithms via API.

Oscar: Yes. So that’s already the API economy. When did this concept of API economy start or begin to spread? The concept itself of API economy, how did it start? – because API came first.

Marjukka: It started around…let’s say 2005-ish. Basically, there were companies that said: “hey, we are going to make our platforms. We are going to make our products available via API”. So there were companies like Salesforce, Amazon, eBay, Flickr and a lot of others who basically said “this is the way that we do it”.

For example, Salesforce said: “we focus on the CRM and a few other things here and we want to provide more services and a kind of more holistic approach to our end customers. But we don’t want to do it all ourselves”.

So we offer these APIs to partners so that they can add on other capabilities to a platform. Stripe, which is a payment provider, was also starting this quite late in a way in the API game, but not so long ago. And they were basically saying that yes, let’s do payments, like credit card payments, and PayPal was around there already at that time and PayPal was the de facto payment method in a lot of countries.

But Stripe said that we will do this only with APIs and actually they got everybody else to do all their promotion around it. So it was something that you could buy just as an API with no user interface (UI) involved.

So this is where we started seeing that and personally, I saw the first signs and I got involved with API economy really, in the kind of modern API way, in 2009. We were getting basically a lot of customisation requests and a lot of things that came from our customers and wishes, “Hey, can you do this and this?”

We had a lot of integrations that were file-based integrations. They were always needing a lot of work to be done and then one day, my developers said, “Hey, we heard about this API stuff. We could do this,” and then we started making APIs and productising them and basically we got rid of a lot of tedious work and we got rid of a lot of the customisation, and the customers could start building their own stuff.

But as some people listening to this might say who have been around for a little bit longer, it does go back. You can already start talking about API economy or like web services and service-oriented architecture as the kind of pre-stage of API economy. It wasn’t completely sellable at that time in a way that APIs are now sellable and viable.

But the same idea was there. So when, for example, in 2005, 2006, we started doing those web service-based architectures in the Ministry of Agriculture and Forestry, we already had partners using those web services and it was just that the monetisation ways were not completely there yet. Even the service-oriented architecture and web services were quite new at that time.

But the earliest signs of API economy you can see already from there, even globally.

Oscar: Those examples you mentioned are of course quite outstanding. Some organisations that made it big about using APIs in that way. Some of these companies – basically their business model started like that. So they didn’t have anything before.

Marjukka: And I have to say, since this is a Ubisecure podcast, I have to say that one of the things that we did need and it started to happen in like after 2009-ish was the kind of coming up of these identity services and authentication services, which had APIs. But back in the first wave, there were no proper standards, or there were XML-based standards, and then there was like a really rapid development of also the kind of security-related and identity-related standards after that. And we are just seeing the real maturity of those standards at this point I would say.

Oscar: OK, OK. Yeah, very interesting. And a term that is very connected to what we are talking about is digitalisation, which the term itself, I don’t know how old it is. Maybe you know better. It has been already popular for the last decade, for the recent years. How are things today in 2020? Would you say that companies, organisations are done, are still in process in getting digitalisation?

Marjukka: Yeah. I would say that, as the COVID-19 has proven, there are companies that are very far in the digitalisation and then there are companies that absolutely have taken no steps or very few steps towards that. That is what we are seeing right now.

So, in this sense, the answer is finally very clear but also, I think that even the last one of those companies have started to see the benefits of digitalisation. And digitalisation –I think this is kind of the thing that everybody ends up saying at some point– it’s not just about digital. It’s not just about the tools and the technology because, for example, we have been working with some companies now for like one or two years even and to start with a proper digital strategy and, actually get it done, it needs a lot of time, a lot of organisational changes. It needs culture. It needs a way to handle partnerships and it needs like a whole new way of thinking and understanding that for example things can be a little bit decentralised –like all the capabilities, all the resources don’t need to necessarily be bought and owned by the company itself– and it needs a lot of kind of networking skills and not the technical networking skills, but the business networking skills.

Oscar: Yes.

Marjukka: And these are maybe even more difficult to get done and sorted out so that you then know what tech to introduce to support those new models.

Oscar: OK. So some organisations still need to change their processes internally in order to be ready for digitalisation.

Marjukka: Yeah. I mean like humans are both the problem and the solution in digitalisation I would say.

Oscar: OK. Wow.

Marjukka: But hey, I’m a master of education. So I get to say this.

Oscar: OK. You have authority to say that.

Marjukka: Yeah. My biggest job is actually to kind of enforce unlearning of old concepts and even the old-fashioned ideas about what API economy is because for a lot of people, that is still totally a technical thing.

Oscar: Yeah. It is correct, unlearning. So that is one of the reasons I wanted to talk with you about because you evangelise this API economy business-oriented API. We’ve been there last year in APIDays Finland and always learning more about what you and other companies that are doing things right. There is still a lot of work to be done to keep evangelising other companies and organisations about this.

Marjukka: Yeah, and I think that it has been funny. We have this joint course introduction to API economy. That’s a free course with Tampere University and it has been really fun to see the comments from the students. There are all kinds of ages and backgrounds and countries represented in the course and the first enlightenment comes in the first chapters where they are like “hey, now I get why this is a business thing”. With a lot of people, you can see that if they have a technical background and, even business background, they just think that it’s completely kind of a technical thing. But that is something that just needs to change.

Oscar: Yes. So what’s your view of identity and digitalisation in the API economy?

Marjukka: Well, you have to handle it. I mean, if you don’t handle the identity and if you don’t handle the identities of partners and customers and staff and the whole network, if you only concentrate on the kind of traditional identities to handle, then you are in problems with the digitalisation. I just have an example about that quickly. We were just consulting on behalf of Business Finland, which is a government agency, but we basically had the opportunity to consult a digital platform programme where one of the bigger cities of Finland was starting to build or plan additional platform for education. That could be joined by all the municipalities of Finland eventually.

But one of the key things there was that traditionally the Department of Education had been handling only the identities of the students and the teachers, and now they had to involve also the parents and a lot of other people that were involved in the education and a lot of partners because they wanted to make it as open as possible for education technology vendors.

Oscar: Right.

Marjukka: And you suddenly have in your hands a totally different set of identity issues, even how to handle, allocate, manage those identities and what is typically a problem is how to verify the identity, the digital identity, –who is really the person behind that identity? – In which cases is that important to know and which cases it isn’t important? And to handle all those different levels of identities and verified identities in the same system. That’s a typical issue.

Oscar: OK. So that’s for instance an example of a project that is ongoing now. So there are challenges like that today.

Marjukka: Yeah, there are some other cases. Like I just mentioned, also this is a Finnish case but still very relevant in the European Union context and also outside – the traffic sector. So, mobility as a service is a thing for most and this kind of transformation of the transport industry. In Finland, the government came up with an idea: let’s copy open banking to traffic. It ended up as local Finnish legislation, national legislation, and that required all the traffic operators to handle a case where they all needed to open APIs to each other or anybody who is somehow relevant to the industry.

They needed to allow these parties to actually sell their tickets. So there’s this kind of a travel chain. If I want to go from Helsinki in the south of Finland to northern parts of Finland for example, and I want to book one ticket so that I could book that ticket and no matter what means I need to use to travel, like taxis, buses, trains, flights, anything. Because all of those traffic operators have their own systems for loyalty and customer management, I might have already accounts in all of those systems. So then how to handle that identity exchange, that data exchange between those operators? I was involved in a project by the traffic regulators where we needed to make sense of this law in a technology and business way so that the traffic operators would actually handle this situation.

It was quite an interesting thing. We ended up using OpenID Connect based trust there and it needed to be extended. And luckily, the open banking efforts had already forced bank and all the finance sectors to come up with solutions for example, to handle business and person identities. For example, Social Security numbers and business registry numbers and all that stuff within the OpenID Connect specification or OpenID specification and we could actually rely on that. And that was actually why I asked you guys in Ubisecure last year to give a presentation in APIDays in Helsinki about that because that was at the time a huge issue. We needed that also for the traffic sector.

Oscar: Yeah. I mean another very interesting example you are giving, when you start describing some of it like a nightmare at the beginning.

Marjukka: Yeah. It pretty much was a nightmare at first to even grasp what the law required, why it was there and how the heck should we handle this technically, so yeah. It wasn’t easy but we came through.

Oscar: Excellent. Well done. Then I saw that you started talking about OpenID Connect and that’s an open standard and that’s one of the drivers of Good Identity. I mean, you need open standards like OpenID Connect to make these things happen.

Marjukka: Yeah. I mean like there was earlier, some years ago already, the OpenID standard and of course OpenID is what all the Googles and a lot of other single sign-on solutions also rely on. But it wasn’t really until OpenID Connect came about that it was usable in, for example, API-based solutions and I could go on to the technical stuff on it, but I won’t, because the thing that you need to just understand is that OpenID Connect solves the problem of – for example you have a mobile device. You have a mobile app in that device. The mobile app is using APIs over the internet.

And the question now is: “Who is actually handling the mobile device? Who is the person using that app in there?” and because the traffic between the app and the APIs and the backend of APIs can actually be quite easily seen, because the device owner can actually access that traffic even if it’s secured, encrypted and everything.

So OpenID Connect brings a lot of solutions to that kind of situation too. So it was the thing that was completely missing before and some people might know SAML. That was the stuff that we used with web services, XML-based web services, and of course it’s still there. It hasn’t gone anywhere. But with these modern technologies where we have REST APIs with case and formats and other stuff, the OpenID Connect is just so much more convenient and also it’s more secure than just SAML.

Oscar: Yes, yes, exactly. Now that you start talking also about the importance of security, what is the role of identity in API security?

Marjukka: Well, it is hugely important because the first wave of APIs, these RESTful APIs, was actually using a lot of these API keys only. So you wouldn’t actually know who was using the API, which user. You would only know which application would be using the API and that brings about a lot of problems because sometimes you need to know if the user of the API, the same API, is the customer. Is it the partner? Is it somebody who has only access to their own data or all data or, for example, a member of a business unit but not the member who can actually see all data in that company?

Because APIs shouldn’t rely necessarily on roles. I mean, that’s one way to handle access of course. But you still can’t rely on a very simple identity management, a simple authentication because the identity and the authentication method wouldn’t go necessarily hand in hand or it would be too easy to just, for example, give somebody else the API key or pass it on and you wouldn’t know who was really using it.

So the identity in API security is very critical in many APIs – not in all. For example, we have open data related APIs that are very public. There it’s completely fine to use typically an API key, which doesn’t really tell who you are. It just maybe is connected to an email address or something. But you can still, for example, block that user of that API key from using the API instead of blocking everybody.

So we had a case for example – the public radio station. There was some developer there that used one open data API from another organisation and there was this programming error or something that it started spamming that API a lot.

The provider of the API, the other organisation, was in trouble because nobody could use it. They didn’t have proper API management at the time and they just didn’t know who to block because there was no API key, there was no identity that associated with the API used. So they didn’t even know who to tell to stop meddling with it.

They just had an IP address so they ended up blocking all the traffic from the public radio, which is not very convenient probably. So, I mean, there is that kind of security level, like who is accessing and what should they be able to do? But then there’s also that kind of management, lifecycle management, information, and all of that stuff. That is related to also the identity.

Oscar: So API keys can be still OK for some APIs that don’t require too much security.

Marjukka: If the choice would be just to not have any authentication, if you don’t really have any use of securing the API, if it’s only for example for retrieval of data, not updating, creating, deleting anything. Just for retrieval of data and the data might as well be on a website, on a public website. So that’s kind of the criteria.

The thing about an API versus a website – it’s not even so clear sometimes which is which – but with an API, if you don’t have any traffic management there, if you can just use the API as much as you want, you have no rate limits in place for example, then of course you can crash things for the other users.

So the recommendation would be, even in the public service, to put an API management layer there. To put some rate limits there, give at least the API key associated to any email address, which of course, there’s kind of an identity behind that email address but we don’t need to know who that person is, who that organisation is.

We just need to know that this is the way to reach it and this API key has been used for example to spam this API. So we will block that out. Those are the criteria that you can use it, that there’s no update for it or anything. It would be as public as the public internet. Otherwise, you should always have OpenID Connect.

Oscar: Yeah, yes. I think most of the cases essentially we are talking about organisations, companies that have real services. So it’s the opposite. You have to use OpenID Connect to secure the API.

Marjukka: Yeah. But there’s just so many real companies out there that are still using only API keys and that’s kind of the issue there and a lot of times, those APIs have been born first into the internal use. But then when you actually want to use them in mobile apps, you want to use them in IoT devices, anything that a user can get grasp of, and also if you want to share them with partners, then you are in trouble if you don’t have proper API management and proper security and identity management there.

Oscar: All this experience, learning about this, would you say that companies are taking API security seriously at this point?

Marjukka: Well, there are a lot of companies that are taking it seriously. Then there are a lot of companies who think they are taking it seriously but are relying on it only for internal use for example, or these APIs are so old that they are using technologies and ways of managing the APIs and authenticating and having identities, that they are not relevant anymore.

So they need an update. And then, there are just companies that absolutely don’t take it too seriously or rely on the developers who might be very junior or who might not have been given any time or resources to really handle the security or specifications, how seriously they should take the API security.

A few years ago I was working in Digia, in a team where we had API management as a service to customers and the problem that I found out when being on the customer side for some years was that there was no good way to handle API development and API management.

So the developers who were developing the APIs didn’t quite know what API management was and oftentimes we’re not very security-oriented for APIs specifically. There was a process lacking there and checklist lacking, what should you check, and that’s where I ended up creating with the team the APIOps Cycles Method that is an open method and it relies on lean methods and kind of has a background in DevOps but also is very business-oriented.

There we have some checklists and some guidelines of what you should be checking for API security, also identity management, and it’s completely free. It’s in www.apiopscycles.com address and you can go there and we have actually some training and some certifications for that too and meet-up. So you are welcome to come to those too.

Oscar: So that APIOps Cycles method, who is the main target audience? The leader of a development team?

Marjukka: Yeah. Sometimes it’s the leader of the development team. Sometimes it’s the enterprise architect even who is in charge of like all the framework and methods used for all the software development in a company. But then it can be also Product Manager and a business owner or a business designer and even a single developer.

So the idea here is that you can use and benefit from this method, whatever your role is. Sometimes you even have had service designers using the method and UX designers because they actually are sometimes involved in for example, making sure that the developer experience is really good and they might not know exactly what developers are doing and what APIs require.

So the idea with collaborative methods is that everyone involved could join in with a single language, a single set of tools, and it actually starts with business model canvas type of stuff and value proposition canvas type of stuff which are typically known to business people and product managers and service designers, that are made to work in the API world. And then it goes down to kind of, like one architect described, the next canvases as colouring book pages because a lot of times architects, IT architects, software architects, all the people in the IT architecture side, they are using tools and using methods to describe architecture which don’t make sense to all of the other people involved in the development. Not even the developers sometimes but definitely not the business people and the product managers and within the planning stage, you kind of need everybody to give input and you need some tools that everybody can work with and understand the business impact.

Because for example for security or identity management, the question is, “What is the business impact if these things fail for example?” Sometimes it’s a really big one. Sometimes somebody actually can die if the API for example is not properly secured. But a lot of times or has the wrong data or some impact. But sometimes it’s not that kind of dramatic.

Oscar: Yes. Well, excellent. I like also that you remind this, you have developed these tools and you remind us about that because when you are building new products, new services or new features on the products, it’s very important to take all this into consideration.

Marjukka: Yeah, and also even if your thing is security, but also to take the customer view on it. So what is the impact for example for the developer or the end customer who is using the service? So a lot of times we tend to think about the service provider view and we think that we need to have these features and sometimes you just list for example the security features or security staff requirements there. But we don’t really stop to consider what the end users or the developers using the API need and require or are afraid of.

Then if we focus on that first, then we actually can take the lean approach and only give them what they actually need and can use, but also give them more if it feels like they need more than what we originally thought was needed. So this is kind of a very important thing also from a kind of cost benefit and focus point of view.

Oscar: Yes, definitely very good reflections. So we are heading towards the end of this conversation. Could you now give us a tip for anybody to protect their digital identity?

Marjukka: Well, of course. The first rule is that don’t take your passwords from your immediate family or something, but that’s kind of an old thing. So digital identity can be protected in a lot of ways but a lot of times the digital identity is connected somehow to our email addresses. And email addresses are a unique thing.

If somebody gets access to your email address, then they probably can get access to a lot of your identities online and so the idea is that if you protect your email address, you protect a lot of your identities. That’s the simplest rule. Of course there are a lot of other things to consider too.

Oscar: Yeah, very true because that’s a gateway to the identities we have in several services. Correct. Thanks a lot Marjukka for these very interesting insights about API, API economies and also the security side of digital identity. Please tell us how we can find you on the net? What are the best ways?

Marjukka: So of course you can find me on LinkedIn – so Marjukka Niinioja. And also on our website www.osaango.com. So Osaango with two “As” in the middle because it comes from a Finnish word. We want everybody to learn Finnish secretly. But yeah, there’s a way to book a meeting with me or look up anything that I just mentioned – the APIOps Cycles or the courses on our Osaango Academy.

Oscar: Fantastic. Thanks a lot Marjukka and all the best.

Marjukka: Thank you.

Thanks for listening to this episode of Let’s Talk About Digital Identity produced by Ubisecure. Stay up to date with episode at ubisecure.com/podcast or join us on Twitter @ubisecure and use #LTADI. Until next time.

[End of transcript]