Understanding OAuth and Web-API security with Matthias Biehl

Kevin Montalbo

Our guest for today is an API expert, author, and advisor at API University. He has consulted companies on digital transformation, API strategy, API architecture, security, software development processes and software integration.
He now uses his background and expertise in technology and software engineering to help companies realize their digital transformation agendas and bring innovative software solutions to the market.

He enjoys sharing his knowledge and experience in the classroom, in-person workshops, online courses or books. Matthias published several books such as RESTful API Design: Best Practices in API Design with REST, and API Architecture: The Big Picture for Building APIs.He also regularly speaks at technology conferences, and runs the API-University YouTube channel with video tutorials, best practices, and reviews. Today, we’re glad to have him over for a round of Cocktails.
Matthias Biehl, welcome to the show! How are you doing?

Matthias Biehl

I am good. Thank you very much for having me, Kevin.

Kevin Montalbo

Yeah, how's the weather over there?

Matthias Biehl

It's turning spring. It's really nice now. Really nice to go outside later and have a barbecue.

Kevin Montalbo

Yeah, that's nice. That's nice. All right. So we'll dive right into the questions. We're going to talk about OAuth in this podcast. Let's first talk about your book OAuth 2: Getting Started in Web API Security. So, five years have passed since you released it. Do you think the content is still relevant today or has anything changed since you've released it back then?

Matthias Biehl

[OAuth] is actually quite good and a well thought-out, practically proven, protocol that we should all use more in our implementations on APIs.

Yeah, well we have to see that the rate of change that we see right now is really staggering, right? Our society changes more than ever before we worked from home - things that people have never imagined and you know, everything is turning more digital. So from that perspective, yes, things have changed, but some things are still staying the same. The fundamentals that hold everything together digitally, those are bound to stay longer than some of the other things. So for example, APIs are still there. They're still running under the hood and we need a way to protect those APIs and it's still OAuth. So these fundamentals of how we connect digitally and how we protect our most valued assets, those are still the same fundamentally.

Now, the specifics may have changed and we have learned a lot over the years, we have learned best practices and there's accumulated knowledge based off of best practices on OAuth that are going to be updated all the time.

Kevin Montalbo

So why do you think OAuth will emerge as the de facto standard protocol for securely protecting API versus other standards?

Matthias Biehl

Well, I think we have to go back in history to a time before OAuth to look at what our toolbox basically looked like back then. I mean, we had passwords, we had certificates, we had MTLS and that was basically the stuff we had in our toolbox. And that worked really fine as long as there were two parties involved - a client and a server. And what changed is, well, we have the emergence of the ecosystem world, where there was now the need for an end user to delegate access rights to a client to access the server in the name of the end user. And that's a new requirement that all of a sudden popped up. And well, there are several solutions to that. And when I think back at how that was solved in the early days I mean, not very good from a security perspective, people have included the end user password into the clients, right? You have to enter, basically, the key to the front door of your house and hand it out to people who were basically just visiting. But that's really a problem that was solved by OAuth, because basically, OAuth works like checking into a hotel. When you check into a hotel, you don't get handed out the master key to all the rooms, right? That is kept secret and only a few people can hold that. But when you check into a hotel, you get a key card that's programmable, and that gives you access to the front door, to your own room and not to any other room in the big house. And it also gives you access only for a specific time period, right? And afterwards, I mean, maybe you would leave it in your pocket. You come back a year later, it won't work because it is bound and that's basically what OAuth brought this new setup that we had in the ecosystem world.

Kevin Montalbo

Yeah. I read somewhere that they also compare it to - like you said, the hotel - they also compare it to like a valet key, right?

Matthias Biehl

Yeah, exactly.

Kevin Montalbo

All right. So the OAuth 2.0 framework supports several different flows to obtain the access token AKA the key card for your hotel room or the valet key, right? Depending on the use-case. So can we run through a few of the major flows used for obtaining tokens in OAuth and how can we distinguish them in relation to their specific use-cases?

Matthias Biehl

Yeah, that's a good question. So, I think I'm going to run you through the main flow. It's called the "Authorization Code Flow", and that's kind of the mother of all the other flows and the other flows are then shortcuts of this authorization code flow. And so, what you do in an authorization code flow is number one: the client requests an authorization code on the authorization endpoint. Then, there you have the end user in the loop. The end user usually authenticates by logging in with biometrics, with a password so forth. Then as an outcome of that, the client, the app receives a so-called authorization code on the redirect endpoint. And with this intermediate code, it can then request an OAuth access token using a back channel, using an API called directly on the OAuth server. Now, when this comes back, the access token has to be validated and then it can be used in order to access those resources.
But, well, this is the OAuth protocol, in short, for the authorization code flow. And there's a lot of things that need to happen. So, you can get into the position to even start that OAuth flow, right? And that's another part that needs to happen before that. But then we have other flows that cut out a part of that, for example, a client credential flow. A client credential flow would not require any end user authorization or end user authentication in the beginning because it's a client just accessing its own data. So, you just cut out basically the first part and you don't have three interaction points, but you just have two interaction points.

Kevin Montalbo

Yeah. So like the flows are making it a little bit easier for everyone else, including the user and even the vendor, right? Yeah.

Matthias Biehl

Yeah. And some of those flows that were originally specified some years ago are now not really best practice to use anymore. So, I would say the authorization code flow should be the starting point. And then if there was any need to shortcut, then you really need to dig into the security implications of it

Kevin Montalbo

All right. So, let's talk about microservices now. So, is OAuth relevant only for public-facing North-South APIs? Or can it also be used in an East-West configuration between microservices?

Matthias Biehl

You need to tweak it a little bit differently depending on how you want to use it.

Yeah, definitely. It can be used for both cases. But I think you need to tweak it a little bit differently depending on how you want to use it. So for example the North-South interaction is typically something that's used when you have exposure of a service externally and there, you use a specific type of token, a so-called reference token. A reference token is a token that doesn't contain any data in itself. It's just a reference, like a primary key into a database. And you can, via that way, retrieve additional information from it. But in itself, if someone would try to decode this access token, you wouldn't find anything in it. And that's very fine when you have central control, when you have a central enforcement point that can then validate that token in a North-South way of interacting.

Now, if you have this East-West type of interaction, then you typically want to have a distributed architecture. You don't want to have any central points, any bottlenecks in your architecture, and you should not really have a reference token because a reference token can only be decoded basically in one point in the whole architecture. So, then you would have what I call a value token and a value token contains information inside the token. So, you can decode this token and see what are the access rights, who is the user and in a very decentralized way, each microservice can decode it and work with that token. And then of course, you can bring both of these patterns basically together, where you have a North-Southbound interaction to the outside world, you translate to, say, the reference token that you give out to a value token, that you can then use inside in your microservice architecture.

Kevin Montalbo

That's great. All right. So now we all know that, OAuth 2.0, it was ratified at the end of 2012, and it was a way for us to solve the pains associated with OAuth 1.0. Now, what is on the agenda for OAuth 2.1?

Matthias Biehl

Yeah. Well, OAuth 2.1 is very interesting because it's basically a simplification and a consolidation of all the things that we have learned since OAuth 2.0 came out. So we basically have new information on how to integrate native apps. We have new best practices for browser-based apps, for proof key of code exchange. So PKCE is the new standard, and we’re basically making that a requirement. It basically improves the security level of OAuth with everything we have learned. And I think it's great.

Kevin Montalbo

Yeah. you talk about OAuth a lot in your YouTube channel and a lot in your technology conferences and so on. Is there a specific or a significant question that you always, like, encounter that you always want to address? Is there like a misconception that you want to address or when OAuth comes up, something that you want to address to the audience?

Matthias Biehl

So, why do you think people are intimidated by OAuth?

Matthias Biehl

People always think that OAuth is super complicated. It's not.

Well, there's a protocol that requires a lot of different players and a very dedicated way of interacting between those players. There are different channels that are used, there was a front channel, like a UI-based interaction, and there was a back channel and API-based interaction. And somehow you need to make the link between this front channel and the back channel. And all these players somehow need to be authenticated. And you need to be sure that you're talking to the people that they're claiming to be. So bringing all of this together is done very elegantly, I would say, in the OAuth protocol. And you have to look at it as a whole. So I think in the beginning it looks like a big pile of spaghetti, but once you go through it, step by step, I think it becomes very digestible.

Kevin Montalbo

And I guess the fact that they're dealing with security is like intimidating, right?

Matthias Biehl

That's right. That's right. But nowadays, I think there are excellent libraries that you can use as a programmer that gets you around a lot of these difficult parts and it already incorporates all the best practices. So I would say instead trying to code the protocol yourself from the start, use something that's already out there.

Kevin Montalbo

Yeah. Including your book, right?

Matthias Biehl

Yeah. And also on an implementation level, I mean, use some modules that are out there for doing OAuth.

Kevin Montalbo

Yeah. So speaking of your book, before we, you know get our listeners excited about all of that, if you were to have a wishlist for OAuth 3, what would it contain?

Matthias Biehl

Yeah, I mean OAuth 3 does not exist yet, but of course, I mean, after 2.1 comes 3. And we see a lot of the development already with 2.1, so we accumulate best practices and then we consolidate and some of the things that are coming up right now are also developed in the OpenID Connect community, which I think could at some point also float back into OAuth, maybe into OAuth 3.0. So, we have the rich authorization request and the push authorization request, for example. And we have the Chiba protocol that could all come back and be consolidated and simplified in OAuth 3.0. And then of course I hope that OAuth 3.0 will be as successful as its predecessor OAuth 2.0.

Kevin Montalbo

All right. How about your wishlist for, you know, after all this pandemic is over?

Matthias Biehl

Well, having a really nice vacation somewhere, going on a plane again.

Kevin Montalbo

All right. Yeah, you can go to APIuniversity.com. I'm also on Twitter, on APIuniversity and MattBiehl and also on my YouTube channel. You can find me and you can find more practical tips on how to use OAuth.

Kevin Montalbo

Alright, that's a wrap. Thank you very much, Matthias.

Matthias Biehl

Thank you, Kevin.