EPISODE 1674

[INTRODUCTION]

[0:00:00] ANNOUNCER: OAuth is an open standard for access delegation. It lets users grant websites, or applications access to their information on other websites, but without giving away passwords. OpenID Connect is an identity layer on top of OAuth. Even if you haven't programmed using OAuth and OpenID Connect, you've certainly used them for authentication on Google, Facebook, Spotify, and countless other services.

Authlete is a service that provides a set of APIs to implement OAuth authorization servers and OpenID Connect identity providers. Justin Richer is the principal architect at Authlete and is part of the working group that developed OAuth 2.0. He joins the podcast to talk about the history of OAuth. OAuth is a delegation protocol, the Authlete API, and much more.

Gregor Vand is a security-focused technologist and is the Founder and CTO of MailPass. Previously, Gregor was a CTO across cybersecurity, cyber insurance, and general software engineering companies. He has been based in Asia Pacific for almost a decade and can be found via his profile @vand.hk.

[INTERVIEW]

[0:01:21] GV: Hi, Justin. Welcome to Software Engineering Daily.

[0:01:24] JR: Hello. Thank you so much for having me on.

[0:01:26] GV: Justin, it's great to have you here. You are the Principal Architect at Authlete. I believe, you joined them quite soon after the company was founded back in 2015?

[0:01:37] JR: Yeah, that's correct.

[0:01:39] GV: Japan? Yeah, fantastic. What is your background and how did you become involved with Authlete?

[0:01:45] JR: I've been involved with the open standard space for quite a while, focusing on internet security and identity and protocols like that. I had been working on OAuth 2 and OpenID Connect. Back then, I was approached by the founder of this company, Authlete, who I had never heard of, when I was out at a conference in Japan. This was Taka came and we sat down and he started to describe to me what Authlete was and what they were doing and why it was different and stuff like that.

He invited me onboard to say like, “Hey, do you want to come join us? Do you want to come help us build this and really make this the best thing that it can be?” Because Authlete is a provider of services for OAuth and OpenID Connect, but in a way that's pretty different from a lot of other stuff, which we'll get into a little bit later on. To me, it was really a very unique take on the set of problems that I've been working on for years at that point. It was a really fascinating space to be able to dive into.

[0:02:43] GV: Yeah. I'm curious, just what were those problems you had been working on that then led into Authlete?

[0:02:51] JR: That's actually a really great question. My background in school, my degrees are in computer science, but I didn't focus on security. My focus was actually collaboration systems and what became known as social computing. It's gone through many names over the years. As I was working on these systems, at the time I was working at a research company, we realized that we were building out all of these systems that would connect things together. Then the security team would show up and say, “You can't connect everything together. That's not secure. You have to segregate everything.” Then, they would basically turn off all of the great functionality that us researchers had been building and working on.

After going through several rounds of that, I realized that, you know what? The security thing is important, but we need to have a mindset of how do we approach security in a way that actually preserves the kinds of connectivity and functionality and the human-facing aspect of this, that a lot of people coming from the security perspective really don't start with. They start with, how do we lock down the systems? How do we do that? That's great. You need to have that perspective at some point.

But I really believe that you also need the perspective of how do you enable as much functionality as possible while keeping it secure? that's how I get involved in the security space. This was right around the time that social computing and mobile devices and all of this other stuff started to really pop up. API-driven websites and all of that. This was the world that OAuth 1 was invented in, and OpenID, the original OpenID.

After a few years of working with those as an implementer, building those out, I started to join the communities where people were talking about how you actually define these standards. Because it turns out, for two computers to talk to each other, somebody has to sit down and really, a bunch of people have to sit down and figure out how those computers are going to talk to each other in the first place. That's when I discovered this world of Internet standards.  OAuth and OpenID were going through this path in different ways. I got involved in those communities.

It was from that space and from that perspective that I found myself falling backwards into this security area and really taking this perspective of how much can we do? How much can we really enable, without just leaving all the doors open? Which somebody coming from the collaboration side, like that was the easiest way to connect everything is just leave everything open. That obviously doesn't work. That was really my journey of trying to find that balance between these two sides, because there's always a push and a pull.

[0:05:36] GV: Yeah, that's super interesting. I like the almost juxtaposition of collaboration and security, because, yeah, the two don't sound like they can coexist, but they have to. I think, also, one thing you just you mentioned there is the word human. There's always the most important part of security, which that's actually what got me interested in security as well, which was how do humans interface with security things that people have provided and usually, it's not in the way it was designed. I always find that part very interesting.

[0:06:11] JR: I've always been fascinated by the topics of shadow IT systems and these homegrown solutions to things that come up, because I'm the engineer that has the stuff that I built. That's the stuff that I was building. At the company that I was at at the time, I knew most of the people on the security team, because they have to keep coming and talking to me about all the weird, little stuff that I was building that was getting around the assumptions that were built into the security systems. Really, it's that push and pull that I found the most exciting part of the security side of the house. Yeah, so that's where I ended up where I am today.

[0:06:51] GV: We're going to talk about some of the general concepts, that you've already mentioned OIDC in a minute. Equally, I think just to help set the scene a bit, how would you describe the Authlete product at a high level?

[0:07:08] JR: Authlete is a really unique product compared to a lot of other stuff that's out there right now. It is OAuth and OpenID Connect hosted as a service. But instead of hosting the entire platform that handles user authentication and accounts and attributes and all of that stuff, it really just does the OAuth and OpenID Connect protocol pieces. The way that it works is that you're building an identity provider, or authorization server. When some request comes in that you actually need to go off and say, “Oh, this is a token endpoint request, or this is an authorization endpoint request,” or one of those bits and pieces, that's when you call the Authlete service to say, “Hey, I got all of these parameters. Authlete, you figure out what's going on. Is this formed correctly? Is everything on the up and up? Which extensions are valid and all of that? Then just tell me what to do next.”

Which means that you as the developer, you really are building your own IDP, your own authorization server. But your code gets to focus on everything, except for the OAuth and OpenID parts. You get to focus on your risk management engines. You get to focus on your account management. You get to focus on your security layers that matter to your applications. You don't have to worry about things like, was the incoming jot on this request properly signed? Was this formatted? Have I seen this nonce before? Was this token actually issued by me at some point? Your software doesn't have to manage any of that.

You also don't really have to worry about adding in support for more extensions and more best practices and things like that as they come along. Because with a lot of software as a service type of things, as we add new features to the system, it becomes available to your software. You can get all of that without having to give all of your control over to Authlete. We don't want to see your users. We don't want to see your passwords and your authentications and all of that other stuff. That is for our customers to own that. What we want to help with is the clients and the token signing. All of that type of protocol compliance and that type of management.

Really, when I've talked to developers about this, what I like to call it is really, it's like an SDK as a service almost. Because you can use our SDK, you can use our libraries, but our libraries really all that they do is they turn around and they call the right endpoint with a properly formatted rest request. You don't need our libraries to integrate with us at all. It's a really straightforward API. Instead of taking an off-the-shelf, like open-source API and building up your own system on top of that, you're really using a world-class system to build out your own customized service. Which means that at the end of the day, all of the requests that are coming through, they pass through your own code before they get to us and after they get to us.

Which means that if you have, for example, a request that comes in and Authlete says like, “Yes, this request is good and everything's good. Go give them the token here.” Your risk engine comes back and says, “Well, actually, that session is suspicious, or this user account has been doing weird activity and we need to override that.” That is your software's call to be able to do that at that last step before it actually reaches going back out to the requesting application. That's a really, really powerful integration point that a lot of other software as a service can't offer, because the pattern that Authlete offers really is pretty unique.

[0:10:53] GV: Yeah. I think you just said there, unique is probably the one thing that came to mind for me. I think, there are a lot of services out there where they all brand themselves as you don't want to take care of user sign up, slogans, authorization, authentication. Let us do it all for you. A problem with that often is, well, that's great, except that you're taking it all away from us. We lose so much control of the platform and what can end up happening at these crucial points, which is signing up. If you lose someone there, then that's not great.

Also, the login side as well. If you're losing people somehow, or that flow is not fully in your control, can lead to some interesting things and not in a positive way, which I'm sure we can maybe get some examples later in the episode of how Authlete actually handles these. That's really good high level. I think we've got to maybe take a step back for a second and let's talk about just actually, the standards that this is addressing and working with. I think the first one, which I'm sure a lot of listeners have heard of before OAuth, but I think you're probably perfectly positioned to help us understand what is OAuth and what does it actually encompass and what does it not encompass?

[0:12:09] JR: I've done a lot of work with OAuth over the years, and I was part of the working group, or I’m still part of the working group that developed the OAuth 2.0 protocol, which is the OAuth that everybody is familiar with and uses. Even if you haven't programmed with OAuth, I guarantee that you've used it. If you've used a social login, or if you've used an app that signs up using a service anytime you do a login with Google, or anything like that, if you Spotify, if you use a Steam account, it is absolutely everywhere. Just about every smartphone also is just tons of OAuth going back and forth.

The reason for this is that OAuth is fundamentally a really interesting type of security protocol. It gets touted as an authorization protocol and people sometimes will say that it's authentication. It's not, but we'll get to that in just a couple minutes. Fundamentally though, OAuth is a delegation protocol. It's not about authorization. It doesn't really have a strong opinion about authorization by design. OAuth is a delegation protocol, which is to say that I as the user have some set of rights and I am delegating a certain subset of that to a piece of software to do things for me, or act on my behalf as it generally gets said.

That's a really, really powerful pattern. Because prior to OAuth and really things that work like this, and there were some attempts prior to OAuth 2, OAuth 1 obviously, but also some other proprietary protocols from Google and Yahoo and other places at the time. Really, the power here is that I don't have to give over all of my account rights to a piece of software in order for it to do something for me. Think back now, gosh, 20 years ago, right? I feel very old saying that the mid-2000s was 20 years ago now, but I think back to that time and APIs that were running over the web, by and large, in order to authenticate to them, you were sending a username and password. If you had a user that was logging in with a username and password, well, why wouldn't you just use that same username and password? It's on behalf of that user.

The problem here is that the API that you're logging into cannot tell the difference between the user showing up with their credentials and a piece of software showing up that happens to have a copy of the user's credentials. This is a really big deal for a number of reasons. One, you can't limit what is accessible on that API. Let's say, I was giving access to my bank account records. I might want something to help me balance my budgets and things like that. A bunch of great tools out there for that these days. But if I have to give my username and password, they can do everything that I can do on that account. They can close the account. They can make transactions. They can send all of my money off somewhere else. All of these things that I really don't want them to do.

I really don't have a good way to say, “Look, I only want you to be able to do these limited things. Importantly, I want the system that they're logging into to be able to tell the difference between me and the software that I'm giving some access to.” OAuth solves this by basically, creating this artifact called an access token that encompasses not only my identity as an end user, but also, the identity of the software, so the intersection of that, plus whatever that the system has approved for that intersection to access that API.

It's really, it's this tuple of who said it's okay, who's asking for it, and what was approved, right? With that type of mathematical logic behind it, it's understandable why a lot of people say that this is an authorization protocol. It feels a lot like an authorization type of language. Ultimately, that's what you're feeding into. Often, the backend is this user, this account, this action, yes or no. That's not what OAuth is actually doing. OAuth is providing the means to delegate that authority to that piece of software.

[0:16:31] GV: OAuth has been around a long time, I believe 20 years, possibly.

[0:16:37] JR: Almost, yeah. If we count OAuth 1, that was around 2006.

[0:16:42] GV: Right, exactly. Again, maybe a high-ish level, what were the core changes, I guess, that came in between one and two? Because OAuth 2 has vastly outlasted one, and as you call out, it's still in use today, pretty much all over the internet, anywhere you look. What was that step change? Clearly, it's been pretty important.

[0:17:03] JR: There were a lot of things that changed between OAuth 1 and 2. The first of which is that OAuth 1 was written by a bunch of very smart people in a back room at OSCon, the open-source convention. They put their ideas together about how to make this delegation protocol, named it OAuth, wrote it up as a paper, put it on the web, and people started to build and implement it, and it was great.

A few years after that, as people were building it, they started to feel out what the edges were. OAuth 1 had a lot of things that it got right, but also things that were just a little bit off. It had its own proprietary signature mechanism that was pretty easy to get wrong, and pretty easy to get wrong in ways that was hard to tell how you got it wrong. It assumed that it was always two websites talking to each other. The cryptography that it used was really about both sides can share the same secret, and that secret is always available for all of the crypto functions.

As we went on in time, 2008, 2010, mobile apps started to become really important. JavaScript-based, what we would call an SPA today, all of this became much, much more important than it ever was in the OAuth world, the OAuth 1 world. OAuth 1 was really about taking one website and letting it talk to you on other websites. With that, it does a decent job, but it was really when people started to stretch it beyond that original use case. Also, when Google started to use it and really stretch it beyond the scale that it was intended to really address, that's when the problem started to come.

With OAuth 2, a whole bunch of us got together and met in the IETF, the Internet Engineering Task Force, because you should never let nerds name themselves, right? This is an organization that defines the standards that make the internet layer run. TCP/IP, TLS, HTTP, all of this stuff is defined in the IETF. OAuth came to the IETF, like we've got this community document. First thing that we did was we dusted it up, cleaned up a session fixation attack that had crept into the original design and published that out as like, this is a thing that exists. At that point, though, a lot of people came together and said, “You know what? We can probably do a better job. We can probably take these concepts, take these patterns, and really address them in a different way.” A few different groups came together of like, “What if we did OAuth, but like this? What if we took this aspect and changed it around?”

Throughout that entire process, the key thing that really permeated the standardization effort was anytime that we had a decision about where to put complexity, we would put it away from the client application wherever possible. Because the idea here is that like probably a lot of your listeners, most of the people that are dealing with OAuth on a regular basis, they're dealing with it as a client developer. You've got an API that you need to call and their documentation said, you need to go do OAuth in order to call us.

At that point, it's important to realize that security is not the goal of this developer. Security is what's getting in the way of the developer doing their goal, which is calling that API that they want to call. Going back to, like I said, my background with collaboration systems, that's exactly what I was finding. The security patterns were getting in the way of me doing what I wanted to do, which was connecting data and connecting people.

We really took that mindset to heart with the design of OAuth 2 as much as we could; tried to make it simple for client developers primarily, but also, make it possible to do things securely and repeatably and really the best that we could with the technology stack that we had. We expanded on a couple of important concepts from OAuth 1. I was talking before about this whole idea of limited access. With OAuth 1, it really still boiled down to this notion of either you get access, or you don't. Now, you can tell that it's a particular client application and not me. I could, for example, say, oh, this copy of TweetDeck can send messages, but it can't post publicly, or whatever set that I wanted to do. That was fine, but that was all really limited towards what the API was willing to offer.

With OAuth 2, we explicitly carved out this space that became known as the OAuth scope parameter. The whole idea behind scope is that the client can now say, “Hey, these are the things that I would like to do.” The server can say to the user, “Well, okay. These are the things that this software wants to do. Which of these are okay?” Getting the user involved in that security conversation and having this explicit record of how the API is divided up in an interoperable structure was a huge step forward. Because now I could have an application that asks for read access and I get a token that's only good for read access. If that gets compromised, that's all that it ever gets.

We go back to the bank application and I can say, you can read my history up to the last six months. That's it. I can have a scope that amounts to exactly that set of access rights. That is the only thing that you will ever get. Being able to describe that inside the protocol for these APIs was a really powerful move.

[0:22:44] GV: That is fascinating. I mean, I love hearing technology history and it's also why I love being a host on SED. I get to speak to literally, the people that were involved in producing these, whether it's frameworks, or specs, which is awesome. I think, also, just the fact that we look at OAuth 2, the number of things that developers take for granted now as just part of how we look at authorization, or not exactly authorization, sorry, delegation is –

[0:23:13] JR: Both, really. Yes.

[0:23:15] GV: - is OAuth 2. I mean, it's just fascinating.

[0:23:17] JR: I mean, really, one of the things with OAuth 2 was that it was encoding a lot of the patterns. It wasn't really inventing a lot of stuff. It was encoding the patterns that people were doing, or wanted to do, or especially things that people were trying to do with OAuth 1, but messing up in practice. For example, one of the things that people messed up a lot with OAuth 1 was the signing mechanisms. OAuth 2, we made the decision that, okay, the default everything is going to be a bearer access. The client secret, it's effectively a password that you present by value to say, “This is my piece of software. Here you go.” The token you get back is a bearer token, which means you presented by value with no other proof of anything beyond possession of that value to the other system. That drastically simplified how people were able to engage in this.

However, here we are 10, 15 years later, and we're realizing that a lot of the drawbacks that we knew were there with those systems are really starting to catch up to people. OAuth community is now really working towards building out proof of possession capabilities all across the OAuth stack, building tokens and client authentication and attestations and all of this other work. It's really, it's taking those same concepts and building on top of them in a way that really makes it, so that you can add these pieces when you need them and when it makes the most sense.

[0:24:57] GV: That makes a lot of sense. We've really covered OAuth. We've also got OpenID Connect, OIDC. Might be a lesser-known term to some of the listeners out there, but I think it is equally important in the context of everything we're talking about today. How does that relate, or indeed, extend OAuth? What situations would we find a developer, or a platform reaching beyond pure OAuth for OpenID Connect?

[0:25:26] JR: Well, in my experience, a lot of developers that say that, “Oh, we're doing OAuth, are actually doing OpenID Connect. They're saying like, “Oh, I'm doing OAuth and I get an ID token.” It's like, well, what you're doing is OpenID Connect. The reason for that is that OpenID Connect provides a very clever application of the OAuth delegation. Really, fundamentally, what happens is that you have OAuth, you're delegating some right of access to a piece of software. What if the thing that I delegate is the knowledge of who I am? Is the knowledge of what user is here right now? I am going to delegate the ability for that application to know that.

Therefore, you take this delegation protocol that's built around providing authorization, and it now provides authentication, because it tells you who's there. That information can be carried back over the same channels and can be requested over the same channels. That's really the brilliance of OpenID Connect. The thinking around that came from a few different sources. There was SAML artifact finding. Google had this weird hybrid mashup of an older version of OpenID, which was very, very web redirect focused. OAuth 1, which was, it was a very strange and incompatible mix, but somebody at Google hashed it together and it worked.

It was really taking those thoughts and those practices and deliberately building them on top of OAuth 2 as an application. In addition to that access token that I get to go and call all of these APIs, I also get a message sent back to me, the client, to say, “Hey, this is the user that's logging in right now.” We can delegate that same authority of the knowledge of who is there using all of these same scoping mechanisms, using all of these same token mechanisms that we do elsewhere.

For example, when I go in OpenID Connect and I build out the user's profile, I need to get all of their extended profile information address and email and all of that other stuff. Well, I can go make an API call to do that. That API call is protected by an OAuth access token. It's the same OAuth access token that I got when I made the call that said, who is the user. That same access token could also be used to get their calendar information, or go look at their bank account history, or get their health record, or any other type of vertical API that I would want to talk to. Therein, really lies the power of the combination of these two protocols together and why, I believe, they really took off in the way that they did. They really complement each other in very, very important ways.

[0:28:18] GV: Would it be correct to say that OpenID Connect is synonymous with Single Sign-On, or how do those two acronyms work?

[0:28:31] JR: Single Sign-On is really a wider concept that OpenID Connect is one protocol that can provide a Single Sign-On experience. Single Sign-On is really, ultimately, about the user experience. It's about the user not having to enter credentials into multiple spaces, or manage separate accounts, or something like that. Because even wider than Single Sign-On, you have federated identity. I may not have a fully Single Sign-On experience. There might be stops to say, “Hey, this site is trying to log you in over here. Is that okay? We need to audit this. We need to approve this and set this up and all that.”

That's not really quite a Single Sign-On experience as we're used to it. But it has a lot of the same trappings. When a user is showing up and they have an existing account and they want to be able to express that account to a new site, well, with this technology stack, they can say, “Hey, I'm going to delegate the right to know who I am to you. In other words, that's how I'm going to log in.” Because think about, what are you doing when you're actually logging into a system. You're telling the site who you are and you're giving something that proves it.

Federated identity really is doing exactly the same thing. You're saying, I'm going to tell you who I am. But actually, I'm going to tell you about somebody else who can tell you who I am. They're going to say who I am and you're going to believe that, because you have an agreement with them to believe what they tell you about some population of users. Single Sign-On is really a subset of that wider experience, where the user doesn't even know that it's happening.

You go to different Google applications, you're being bounced through OpenID Connect left and right, right? It's all over the place. You don't notice it, because you sign into your Google account and then you're just there, and you're in all of these applications. That's really one of the most powerful things that this federated identity system can actually give you. I would be remiss to leave out other federation protocols that are out there, like SAML and people have invented all sorts of strange proprietary ones in addition to OpenID Connect.

There's a very long way to answer the question. That's that OpenID Connect can be used to implement Single Sign-On. In my opinion, it's probably the best standard way that's out there today to do that.

[0:31:00] GV: Yeah, that makes a lot of sense. Again, I think for most people listening, that touch point of SSO is helpful to then understand how OpenID Connect fits into their life, whether they realize it or not. Now, I think it's pretty clear here, we've had a lot on OAuth and OpenID Connect. There's just a lot that has gone into both, and then the ability to, or the effort involved with implementing them into a platform is hopefully, is fairly understood at this point. It's not an inconsiderable amount of effort.

That leads us nicely into Authlete, or back to Authlete. Let's talk about Authlete now in the context of, okay, we know what is underpinning the platform, or rather, underpinning what the platform is aiming to work with. Let's go back. What does Authlete do for you as a developer?

[0:31:54] JR: Well, I would actually like to lead into that with one observation that I've had over the years. When talking with a lot of developers, especially people that have come at OAuth from the client side, they say like, “Well, now I need to implement the resource server at the API, or I need to implement the authorization server. The client was pretty easy, so how hard can the rest of this be?”

The truth is, it's really quite hard to get it right. Because like I said before, when we were sitting down and writing these standards, anytime that we could systematically push the complexity away from the client, we did, which means that now the authorization server is on the hook for dealing with all of that complexity. I will say, it's relatively easy to go through and figure out a happy path solution of getting somebody logged in in a way that actually makes sense. Then the hard part comes with all of the combinations of features and the edge cases and the error conditions and all of that type of stuff.

Years ago, I was privileged to be able to co-author a book on OAuth called OAuth 2 in Action. Authlete, the company actually helped sponsor the translation into Japanese of that book. It's now available in, I think, four languages now worldwide. Regardless, one of the things that my co-author and I did in that book was bring the reader through every single little bit of implementation of all of the major parts of an OAuth system from scratch. We tried to be very clear that in those exercises, you're building something that is standards compliant. We are showing you this is the error path. This is the thing that you have to go through. But by no means should you ever run this thing in production. It is not intended for that. There's a lot of other bits that the book cannot go into, because it may be a 330-page, fairly dense, technical book, but there's only so much of OAuth you can cover in that amount of space.

Really, where Authlete comes in is for developers who are in that space where you may have had the thought, how hard can it be, and then you've realized how hard it can be. Or, you know from experience, trying to configure some other system, or build out some other system that there's a lot of things that can go wrong and there's a lot of things that you'd like to be able to tweak and monitor and audit as the protocol goes through all of its different motions.

Authlete really shines in this space, where the developers are wanting to build out something. You want something custom. You want to actually have it run in your environment, on your language. You don't want to have to go learn .NET in order to deploy something, or whatever language you want to do. You don't want to have to go build out something on some specific platform in order to be able to do the things that you're doing. You want to integrate it into your system in a way that makes sense to you and your environment.

Authlete really helps by taking those hard parts, all of those bits that are like, making sure all of these parameters are in the right place. If somebody's making a refresh token request and they don't send the client ID parameter, what does that mean? Turns out, it depends, which flow are you doing? What client authentication method are you doing? Did you use Depop to bind the token originally? There's a lot of questions that you need to be able to ask and have good answers for.

Because of that, Authlete can actually handle answering all of those questions for you, because what you do in your code is you take that incoming request, bundle it up into an API call and send that off to Authlete and say, “So, what do I do now? What is the next part?” From a developer's perspective, a lot of it really, it honestly feels like, if you had a library that was just do OAuth stuff, and you drop something into that library that says, “Oh, I got a token endpoint call. What's the answer? What's the correct thing to do here, given the circumstance?” The library comes back with, “Oh, this is a valid response. Here is the token that goes with that. Just hand this back to them and you're on your way.” Authlete really takes that cut.

The problem, by basically giving you that SDK to call, but it's backed by a live service. It can have state. It can manage things over time. It can have storage. It can have all of these other kinds of knowledge that you don't need to account for within your application, right? If some other decision has said, in the middle of this process that, oh, this client has actually been deactivated, don't give it a token. Authlete is managing that. It's going to say like, “Yeah, actually, no.” That you just say, “Bad request, unknown client ID. Here's the message. It's already formatted in JSON for you. Have a nice day.” That's all your code really needs to do if it wants to.

If your code wants to take the response back, like I said before, and do additional processing on that based on your own risk analysis, absolutely. That's why you have those keys. That's why you have that control at the end of the day.

[0:37:05] GV: That makes a lot of sense. I think, maybe we could contextualize it with a company, or a customer, so to speak, whether fictional, or perhaps real. Could you give an example of where Authlete’s been implemented and what that flow would have been without Authlete and with and what's been measurably improved using Authlete?

[0:37:28] JR: Absolutely. Authlete has really found a big home in the financial sector, especially in Japan where the company was founded. One of the reasons for that is that banks and other financial companies, they're really not keen to give up end-user information. They're not going to want to hand over client accounts and things like that. They really want to hold those close. Whether that be for privacy and regulatory reasons, or just corporate culture of not shipping things out. If you're a bank and you need to implement this stuff, you're either going to pay a whole lot of money to get somebody to run an entire stack for you and run it in a dedicated environment that you have total control over. There's a lot of cloud vendors that don't have that as an option that don't let you do that.

Or you're going to try and build something in-house. You're going to take an open-source application. To be clear, I love open source. It's amazing. It is what builds our society in ways that we will never fully understand. But when you're dealing with a critical security component, the cost of open source really comes with the knowledge and maintenance of building that over time. It may be easy to set it up to begin with, but then you've got to realize that, okay, so new feature comes along. How do I integrate that? How do I change that? Something was found in my source libraries that we now need to update. Well, okay, get the engineers back on and make sure that that update doesn't break anything and do all of that other stuff.

If you're in this environment where you own your user accounts, you own the authentication path, you own all of that data, and you don't want to give that up, well, then what you really need to be able to do is have a system that only jumps in when you're doing the API access, when you're doing the federated login to another application, when you're doing something that faces that particular boundary. Then any other time, you want that software out of the way. You don't want to have to deal with that.

What our customers in the financial sector have found is that Authlete gives them the ability to hold all of that information close. We don't store user accounts. We don't store names and passwords and addresses and account numbers and all of that other stuff. What they do is they tell us like, “I need an access token for the following subject identifier, with the following rights.” Then you give me the answer. You make that access token that does all of those things.

At Authlete, we don't know what any of that means. We don't care what any of that means. Our customer's code is managing that mapping between different things. That's a really, really powerful pattern for our customers, because they both retain that control and flexibility, but also, don't have to worry about the details of this interoperability layer that OAuth and OpenID really provide.

[0:40:28] GV: Would it be the case that Authlete leans more heavily into the situation? I mean, a bank is one of the more extreme versions of this, but I'm thinking of size of company, size of where Authlete fits in that, especially if you have multiple teams, multiple products, and but they all need to share some understanding of who a single customer is and what rights they have, then they go the off-server route to get that set up. Is that where an Authlete excels?

[0:40:59] JR: Honestly, I would say that that's where OAuth itself excels, where you've got multiple systems that you need to provide an abstract security layer, but you want to have one notion of who the user is and what their rights are throughout the system. Because it's all about delegation. OAuth doesn't specify what you're delegating to, or what it is that you are delegating. It just gives you the mechanisms to do that.

Really, in that case, that's when I would tell a company like, okay, this is where you start reaching for OAuth. You've got things that you're protecting. They're probably a little bit different and you want to be able to centralize that in a secure way and have that go through the authorization server.

Where Authlete really excels is once you've realized that that's the path that you're going down, Authlete excels when you start to answer the question of, all right, now, how do I want to get there? What is it that I want to do? Because Authlete it is this semi-hosted system. It really fits this particular niche, where you have something that manages your users, your customers, the people that are actually going to be authorizing applications and stuff like that. You just need to make that available out into other systems, without giving over control of those customer accounts. That's where Authlete really, really excels.

I would say, that we fit very well from very small companies that have one or two APIs that they're protecting from a handful of applications that they just – they don't want to deal with all of the intricacies of these security interop protocols. Then we scale very well to large companies with hundreds of APIs and thousands of clients, or more and millions of users. One of our customers has a – it's like this televised game show. This is my understanding. I don't really work on the customer side as much directly. But in talking with their engineers, they've got this televised game show that every once in a while, their scaling just goes through the roof, because everybody's calling in and voting for their favorites, right? Everybody's not calling in, they're logging in to the system and saying like, “No, this is the winner of this competition,” and all of that type of stuff.

They need to be able to scale very quickly, very, very, very high, and then drop it back down. We're able to give them that capability, because all of those requests are coming through and like, no, I need new access token, new this and da, da, da, da. That's only for an hour. Then it all goes away. They don't need to build out all of the infrastructure to handle that. They're also not giving over all of that user information. They're not just handing over their entire process over to us in order to just handle those types of systems.

I don't even know what the rest of that particular customer stack runs on, but I don't need to, because in my talks with their engineers, they're like, “Oh, we need to be able to get this field in here, and so that this API knows what to do.” That's where we work with them to figure out like, okay, yeah, this is this setting, this whatever. Really typical integration stuff.

[0:44:14] GV: Yeah, that's a fun example of the game show one, and one that I think definitely gives a lot more context for me and I'm sure the listeners on where this fits in.

[0:44:24] JR: I was just going to say, I'm not on the devop side, but the numbers on that one just absolutely blew my mind seeing the usage graph spike the way that it did. It's really quite something.

[0:44:35] GV: Very cool. If we look ahead/, I guess, just look around, there's a lot of players in the market now, all saying, “Well, we take the pain out of this.” They're coming at it from many different angles. We've got companies that do superior JWTs. We've had an episode on that a little while ago. Passkeys is probably the big one that's coming in across the board. I'm very interested to hear how that does or doesn't fit in with Authlete. We've got other players, let's just take Supabase as an example, where they're doing a backend as a service and authorization authentication is a huge part of that.

It's a one-way door decision for a lot of developers. You don't want to have to explain to someone why we're now undoing the authentication authorization system that we implemented and all the – quite often, I guess, there's a lot of reworking that the end user even is aware of when that happens. “Oh, we've had to reset your account and etc.” Taking all these things to account, where is Authlete maybe different and what's the – we've maybe covered it already, but I think just to vaguely summarize, what's the perfect scenario that Authlete excels with all these other known ways things could be done?

[0:45:51] JR: Let's actually take Passkeys as the example here. Passkeys are a fantastic technology in dealing with non-password-based authentication. As we were talking about, OAuth is not an authentication protocol. OpenID Connect gives you authentication, but it specifically gives you authentication that is separated from the end user's credential. Passkeys are all about the end user's credential. Being able to recognize and reuse the same device as a different credential, as a different authenticator across multiple different sites, so that those other sites don't know who you are.

OpenID Connect on the other hand is saying, you have one account and you want that account to be known across different applications. OAuth is saying that you have one account and you want that account to be able to control access to a bunch of different things. From Authlete’s perspective, if one of our customers wants to implement Passkeys, that doesn't actually change anything. We don't see that part of the process.

When I was talking before about how Authlete is semi hosted in our customers own the end-user experience, all those end points, the whole piece where the end-user logs on to the identity provider, we don't see any of that. We don't own that. We wait for the customer software to say, this is the user that is logged in, and whatever piece of software has said that the user is logged in, they put something into – our customer puts something into the API that says, “This is the user. Give me an ID token and access token that represents them.”

We're not checking the user ID, because we assume that the customer's code has already figured that out. That is not something we're figuring out for them. If we have a customer that implements Passkeys as an authentication method, none of the rest of the stack downstream changes. They implement Passkeys, they implement multi-factor authentication, they implement a risk engine-based session management, and that doesn't change the rest of the experience. Our customer gets to own that entire experience as they go through.

Now for a lot of these other systems, it really is about how much of the system do you want to hand over to somebody else to run? In some cases, yeah, you want to hand over the whole user account. You want to just say, “You know what? Somebody else deal with this mess. Whatever they have is fine and we're just going to use that.” That makes a lot of sense for a lot of systems. Otherwise, we wouldn't have big identity provider systems out there. They wouldn't survive if it didn't make sense for some people.

On the other end, you've got the people that are like, “Well, no. I don't want to hand that over. I guess, I need to figure out how to do this.” That's when you get the very small, like you own everything in the stack you implement it, a lot of it is open-source implementation type stuff. That makes sense for some cases, for the lot of cases. For years, I was the maintainer of an open-source implementation of OpenID Connect that was doing exactly that thing. It's like, you're owning the entire federation process. How ever you're building out all of your users, you are running everything yourself. That made sense for us and the team that was building it at the time, and it made sense for the people that were taking and deploying that. People still go use that out there. That's great.

Authlete is really unique in that it fits in between those in a space that people didn't really know was there. I remember that first conversation that I had with Taka way back in the day. We sat down and he starts explaining Authlete to me and how it works. I remember thinking like, this sounds so weird. Why would you do this? None of this makes sense. It didn't fit any pattern that I had heard before. I was like, why would I only take that one piece and hand it over? Why wouldn't I just hand everything over? If I'm going to go that far, I might as well, right?

The more I talked with Taka about this, the more I realized that the place that Authlete makes this cut of what's a service and what you handle yourself, honestly, it's really brilliant. It's very unique compared to a lot of other stuff that's out there. Then I realized, not long after having that conversation, that in fact, the open-source project that we were building was actually making the same cut, because we were building it out for an environment where we already had user account management set up. We already had an SSO primary login system. We just needed federation services. We just needed token delegation type stuff. We were just building on top of the existing identity platform that didn't give us those features. But with an open-source project that we built and ran and did everything ourselves.

I realized that Authlete was doing something similar, but in a different way, in a really service oriented way. It makes a lot of sense for people where you've got users, you've got accounts, you've got that managed using some stack of software. Now, you really want to do the advanced federation. You want to do advanced OAuth type of stuff, without having to necessarily learn, or maintain how to do all of that.

Just why I always have a hard time saying like, who Authlete’s competitors are, because I actually haven't found a product that slices up things in the same way that we do. Our competitors are doing things differently. I will straight up tell people that it's going to make sense to go with those in some use cases. The pattern that we're doing really isn't intended to be universal. We know that it's not. We'd be lying if we said that, oh, this absolutely makes sense for everybody everywhere. It doesn't.

The thing is though, a lot of people don't realize that this is a way that you can actually build out the system. They feel like they're pulled into either having everything hosted and then just being stuck with whatever integration points that the service provider gives you, which is probably not going to be quite enough for what you want, or building and running everything yourself, in which case, you're on the hook for maintenance, for extensions, for understanding really what the scope of everything going through your system really means to every other part of the system. That's a really huge lift.

Authlete is really floating in between those two extremes in a way that makes sense for a lot of different cases. Yeah, I'm happy that we're able to talk about why that difference is, because I know it didn't make sense to me at first. But I'll tell you, it really does now. I think that there's a lot of power behind this particular abstraction, especially in today's distributed cloud environments where you're probably building out your system from a bunch of different pieces that do different specialized things. Having a piece that is specialized on the high-security delegation and federated identity really makes a whole lot of sense.

[0:52:52] GV: I'm going to throw out an analogy here and let's see what happens. I love flying and often when it comes to things zero trust, I think of airports as a good example there. Could we almost describe it in the way that, for example, an airline, you go into check in. Now, the airline can do whatever it wants to say, “Well, I know that you are Gregor. Yes, we look at your passport. Yup, that's you.” Every airline has its own decision on how it wants to say, “Yup, we know it's you.” Ultimately, it has to supply a boarding pass. That boarding pass then has a whole bunch of information. Where can they go? What plane can they get on? Can they get into a lounge or not? The airlines don't own the boarding pass system. They just say to the boarding pass system, “Hey, we know it's Gregor. Give me a boarding pass.” Does that analogy work here?

[0:53:37] JR: I think that the boarding passes are really fascinating one, because in a lot of cases, boarding passes end up acting bearer tokens. When I show up with a boarding pass, in a lot of cases, they're not checking to make sure that I am the human being that has the name that is printed on that boarding pass. The fact that I have that boarding pass is proof enough that I was able to get the boarding pass. That's how OAuth bearer tokens work.

If you start to look around to – I've seen some airlines do this, and some, especially the ancillary things, like lounge access and whatnot, they will ask for your passport and your boarding pass at the same time. That's really a proof of possession type of thing. In that case, they're looking to see that, okay, you have the boarding pass that says what you're allowed to do. Then you have this binding between you and the thing that says that you're allowed to do to prove that you are the one that's allowed to actually have this. Therefore, you're the one that's allowed to do the thing.

I think it's a great analogy for how these OAuth and delegation systems really work at the end of the day. It's also a familiar analogy to a lot of people for how interoperability works. Because like you said, the airlines themselves, they don't own the format of the boarding pass. They don't own how everything gets put. That gets agreed upon. Every airline says, “Yup, we're going to put these bits of information and make sure that this barcode is a particular format that's readable by everybody.” That doesn't all happen by magic. That's really where the standardization comes in.

Which means, though, that if one airline decides that, “We want to buy our boarding pass printer from this other vendor, because they give us a better deal, and it looks nicer. It fits our branding better. We can control all the inks and everything that goes on it, but they make sure that all the layout and stuff is there in the right spot.” Then that makes a lot of sense for that airline, because they're able to do all of that. But the thing is the other airlines don't really care, as long as that boarding pass is standards compliant. As long as I can bring it up to the lounge, I can bring it up to the gate and it scans and it's got the information and it looks and feels right, at the end of the day, that's the interoperability that matters. The thing that I am given is able to do what it's supposed to do.

Really, beyond the analogy of this acting as an access token of a kind, the whole question of how you get that access token in the first place, it's really up to each of the individual spaces. An airport could decide, no, everybody's using the same printers, because we're just centralizing that and it's easier. That way, you can go to any counter and anything works and whatever. You could totally have something that does that.

I've seen small regional airports that do something similar. The airlines don't get to have their name up on the sign, because it's whatever desk they're at that morning, that's the counter that they're using. In other places, you'll walk in and there will be 27 counters that are dedicated to Delta. Then another 30 counters that are dedicated to United, and they will always be that airline until the airline moves out of the airport, which means that in those spaces, they have a lot more control over what that whole experience is like, how their integrations work. What the airport is basically saying is that, “All right, you have to print out a boarding pass. It needs to look like this.” You figure out how to do that. Get your printers from wherever. Get your image formatters from wherever. Get your information stores from wherever. You figure out how to build that integrated system. The important thing is that whatever you spit out from that process needs to work with everything else here.

That interoperability, that is really what OAuth means. How ever you get the access token, whatever process you do to get that needs to work with the other stuff that's out there. That's really the importance of the standards compliance and the standards engagement, which has been a huge part of Authlete’s culture since before I even joined. Like I was saying, I personally have a lot of background in the standardization space. That's how Authlete’s founders found out who I was, because I was posting onto the lists and I was engaging with the standardization process, and so were they. They were looking at the stuff that was floating around out there like, “Oh, yeah. No, this is the stuff that we're interested in doing.”

A lot of Authlete’s work is we're looking at standards as they're coming down the pipe, like stuff that's not finished yet. We've had FAPI 2 implementations, which is a high security standard set from the OpenID Foundation. We've had compliant implementations for over a year or two now, and the standard’s just now finalizing. We've been working with the standards group as the standard itself has been changing and providing that implementation feedback back into the group. That's a really important part of our company culture.

When engineers come in, it's driven by the standards. It's not just like, oh, what is it that this does and how it's built out? It's like, no. How are we engaging in the wider community of how different people are doing different things? How does that make sense?

[0:59:03] GV: Yeah. I feel we've come full circle in this discussion, which is nice, back to where did it all start, which it's the standards. Then, that obviously has to be a part of the evolution of the product as well. Where's the best place for people if liked what they've heard, or rather, they see that fit, because that's been quite a big part of this discussion is where does Authlete fit? Where does it maybe not fit? If someone's been listening and hears that fit, where's the best place for people to reach out and discover more about Authlete?

[0:59:34] JR: I'd suggest that people go to authlete.com/developers. Authlete as a product really is developer facing. It's like, the people that are using Authlete are the people that are building stuff. A lot of the resources that we have really are geared towards that. It's a very engineer-focused and engineer-driven type of company. Authlete.com/developers has a lot of great resources. You'll be able to sign up for an account and try it out and look at the other resources that we have available there. Stuff that's not only about Authlete itself, but also about the standards and the systems that we actually enable.

[1:00:12] GV: Fantastic. Justin, I've really enjoyed this conversation today. I've learned a ton. I'm sure our listeners have as well. I want to wish you and Authlete the best. I hope we get a chance to catch up again in the future.

[1:00:27] JR: Thank you so much for having me on. This has been great. I look forward to having additional conversations as we can.

[1:00:33] GV: Thank you.

[END]