Authlete and Making OAuth Accessible with Justin Richer——程序员-听播客-学英语-01

主题：Authlete and Making OAuth Accessible with Justin Richer
来源/音频链接：https://dev.to/sedaily/authlete-and-making-oauth-accessible-with-justin-richer
全文（带中文翻译和注释）：
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.
（播音员：OAuth是一个用于访问委派的开放标准。它使用户可以在不透露密码的情况下授予网站或应用程序其在其他网站上的信息的权限。OpenID Connect是OAuth之上的一个标识层。即使你编程中没有使用过OAuth和OpenID Connect，你也肯定在谷歌、脸书、Spotify和无数其他服务上使用过它们进行身份验证。）

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.
（Authlete是一种服务，它提供了一组API来实现OAuth授权服务器和OpenID Connect身份提供器。Justin Richer是Authlete的首席架构师，同时也是开发OAuth 2.0的工作组的成员。他参加播客来讨论OAuth的历史，OAuth是个委派协议，Authlete API等等。）

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.
（Gregor Vand是一位专注于安全的技术专家，也是MailPass的创始人和CTO。此前，Gregor是网络安全、网络保险和通用软件工程公司的CTO。他在亚太地区工作了近十年，可以通过他的个人资料@vand.hk找到他。）

[INTERVIEW]

[0:01:21] GV: Hi, Justin. Welcome to Software Engineering Daily.
（GV：嗨，Justin。欢迎来到Software Engineering Daily<播客栏目名>）

[0:01:24] JR: Hello. Thank you so much for having me on.
(JR：你好。感谢你邀请我来。)

[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?
（GV：Justin，你能来真是太好了。您是Authlete的首席架构师。我相信，你在2015年公司成立后不久就加入了他们？）

[0:01:37] JR: Yeah, that's correct.
（JR：是的，你说的没错。）

[0:01:39] GV: Japan? Yeah, fantastic. What is your background and how did you become involved with Authlete?
（GV：在日本？是的，太棒了。你的背景故事是什么？你是如何加入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.
（JR：我已经在开源标准领域工作了很长时间，主要关注网络安全、身份认证以及像OAuth 2和OpenID Connect这样的协议。当时，我在日本参加一个会议时，遇到了Authlete这家公司的创始人，在此之前我从未听说过他。Taka就这么来了，我们坐下来，他向我介绍了Authlete的业务以及他们的所作所为，解释了它与众不同的原因等等。）

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.
（他邀请我加入他们，问我是否愿意加入他们，帮助他们建造这个项目，并让它变得尽可能出色。因为Authlete是OAuth和OpenID Connect的服务提供商，但它的方式与许多其他东西有很大不同，我们稍后会详细介绍。对我来说，这真的是对我多年来一直在研究的一系列问题的一个非常独特的视角。能够深入这个领域真的非常令人着迷。）

[0:02:43] GV: Yeah. I'm curious, just what were those problems you had been working on that then led into Authlete?
（GV：是啊。我很好奇，你研究的那些问题是什么？以及后来如何导致你加入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.
（JR：这实际上是一个非常好的问题。我在学校的背景，我的学位是计算机科学，但我没有把重点放在安全上。我的重点实际上是协作系统和后来被称为社交计算的东西。这些年来，它已经有很多名字了。当我在研究这些系统时，那时我在一家研究公司工作，我们意识到我们正在构建所有这些将事物连接在一起的系统。然后安全小组会跳出来说，你们不能把所有的东西都连接在一起。这不安全。你们必须隔离一切。然后，他们基本上会关闭我们研究人员一直在构建和开发的所有伟大功能。）

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.
（但我真的相信，你还需要了解如何在保持安全的同时启用尽可能多的功能？这就是我为什么会参与安全领域。这正是社交计算、移动设备和所有其他东西开始真正出现的时候。API驱动的网站以及所有这些。这就是OAuth 1和OpenID（最初的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.
（在作为实施者与这些人合作并构建这些标准几年后，我开始加入人们谈论如何实际定义这些标准的社区。因为事实证明，为了让两台计算机相互通信，必须有人坐下来，实际上，一群人必须坐下来讨论，首先弄清楚这些计算机将如何相互通信。就在那时，我发现了这个互联网标准的世界。OAuth和OpenID以不同的方式通过这条路径。我参与了那些社区。）

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.
（GV：是的，非常有趣。我喜欢协作和安全几乎并置，因为，是的，这两者听起来不可能共存，但它们必须共存。我认为，还有一件事，你刚才提到的是“人类”这个词。安全总是有最重要的部分，这实际上也是我对安全感兴趣的原因，那就是人类如何与人们提供的安全事物进行交互，通常情况下，这不是它的设计方式。我总是觉得那个部分很有趣。）

[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.
（JR：我一直着迷于影子IT系统和这些本土解决方案的主题，因为我是拥有我构建的东西的工程师。这就是我正在建造的东西。在我当时所在的公司，我认识安全团队中的大多数人，因为他们必须不断地来和我谈论我正在构建的所有奇怪的小东西，这些东西绕过了安全系统中的假设。真的，正是这种拉扯，我发现了安全方面最令人兴奋的部分。是的，所以这就是我今天的归宿。）

[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?
（GV：我们将讨论一些一般概念，你刚刚已经提到OIDC。同样，我认为只是为了介绍背景，你会如何在高水平上描述Authlete产品？）

[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.
（JR：与目前市面上的许多其他东西相比，Authlete是一款非常独特的产品。它是托管OAuth和OpenID Connect的服务。但是，它并没有托管处理用户身份验证、帐户和属性等所有内容的整个平台，它仅仅处理OAuth和OpenID Connect协议部分。它的工作方式是构建一个身份提供器或授权服务器。当一些请求进来时，你实际上需要会说，哦，这是一个令牌端点请求，或者这是授权端点请求，或其中一个部分，这时你调用Authlete服务说，嘿，我得到了所有这些参数。Authlete，你弄清楚发生了什么。这个格式正确吗？一切都进展顺利了吗？哪些扩展是有效的？告诉我下一步该做什么。）

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.
（这意味着，作为开发人员，您实际上正在构建自己的IDP，您自己的授权服务器。但是，除了OAuth和OpenID部分之外，您的代码可以专注于所有内容。你可以专注于你的风险管理引擎。你可以专注于你的账户管理。您可以专注于对应用程序至关重要的安全层。你不必担心像这样的事情，比如，这个请求上的输入笔记是否正确签名？这是格式化的吗？我以前见过这个nonce吗？这个token真的是我在某个时候发行的吗？您的软件不必管理任何这些。<ps：Nonce是Number once的缩写，在密码学中Nonce是一个只被使用一次的任意或非重复的随机数值。在加密技术中的初始向量和加密散列函数都发挥着重要作用，在各类验证协议的通信应用中确保验证信息不被重复使用以对抗重放攻击(Replay Attack)。>）

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.
(你也不必担心添加对更多扩展和最佳实践的支持，以及诸如此类的事情。因为有了很多软件即服务类型的东西，当我们为系统添加新功能时，它就可以对你的软件可用。你可以得到所有这些，而不必把所有的控制权交给Authlete。我们不希望看到你的用户。我们不想看到你的密码和身份验证以及所有其他内容。这是由我们的客户拥有的。我们想要帮助的是客户端和令牌签名。所有这些类型的协议遵从性和管理。)

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.
（真的，当我和开发人员谈论这一点时，我喜欢称之为，它几乎就像一个SDK即服务。因为你可以使用我们的SDK，你可以使用我们的库，但我们的库实际上所做的只是反过来用正确格式的rest请求调用正确的端点。你根本不需要用我们的库来与我们集成。这是一个非常简单的API。不是像使用现成的开源API为基础来构建自己的系统，而是真正使用世界级的系统来构建自己的定制服务。这意味着，最终，所有的请求都会在到达我们之前和到达我们之后通过您自己的代码。）

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. And Your risk engine comes back and says, And, 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.
（这意味着，例如，如果你收到一个请求，Authlete说，是的，这个请求很好，一切都很好。去把令牌给他们。然后你的风险引擎回来说，实际上，那个会话是可疑的，或者这个用户帐户一直在做奇怪的活动，我们需要覆盖它。这是您的软件在返回到请求应用程序之前的最后一步能够做到的调用。这是一个非常非常强大的集成点，许多其他软件作为服务都无法提供，因为Authlete提供的模式非常独特。）

[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.
（GV：是啊。我想你刚才说过，独特可能是我想到的一件事。我认为，有很多服务都把自己包装为，如果你不想照顾用户注册、标语、授权和身份验证。让我们为你做这一切。这方面的一个问题通常是，好吧，这很好，只是你把一切都从我们身边夺走了。我们失去了对平台的太多控制，以及在这些关键时刻可能发生的事情，那就是注册。如果你在那里失去了一个用户，那就不太好了。）

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?
（此外，登录端也是如此。如果你以某种方式失去了用户，或者这种流程不完全在你的控制范围内，可能会导致一些有趣但负面的事情，我相信我们可能会在本期晚些时候看到一些Authlete如何实际处理这些事情的例子。这真是很好的高水平。我认为我们可能需要先退一步，让我们来谈谈实际上，这正在解决和使用的标准。我认为第一个，我相信很多听众在之前都听说过OAuth，但我认为你可能完全有能力帮助我们理解什么是OAuth，它实际上包含了什么，它不包含什么？）

[0:12:09] JR: I've done a lot of work with OAuth over the years, and I was part of the working group, and I am 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.
（JR：这些年来，我在OAuth方面做了很多工作，我是工作组的一员，现在我仍然是开发OAuth 2.0协议的工作组的成员，这是每个人都熟悉和使用的OAuth。即使你没有使用OAuth编程，我保证你已经使用过它。如果你使用过社交登录，或者如果你使用了一个应用程序，在你登录谷歌时随时使用服务注册，或者类似的东西，如果你使用Spotify，如果你用Steam帐户，它绝对无处不在。几乎每一部智能手机都有大量的OAuth来回运行。）

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.
（这是因为OAuth本质上是一种非常有趣的安全协议。它被吹嘘为一种授权协议，人们有时会说它是认证协议。它不是，但我们在几分钟内就会了解到。从根本上说，OAuth是一种委托协议。它不是关于授权。它设计上对授权并没有强烈的看法。OAuth是一种委托协议，也就是说，作为用户，我有一组权利，我将其中的一部分委托给一个软件来为我做事，或者像人们通常说的，代表我行事。）

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.
（这是一个非常强大的模式。因为在OAuth和真正像这样的东西出现之前，OAuth 2之前有一些尝试，OAuth 1显然，但还有当时Google、Yahoo等地方的一些其他专有协议。实际上，这里的力量在于，我不必将我所有的账户权利交给一个软件，以便让它为我做点什么。现在回想起来，哇，20年前，对吧？我觉得说2000年代中期现在是20年前很老，但我回想那个时候，运行在网络上的API，为了对它们进行身份验证，你发送用户名和密码。如果你有一个使用用户名和密码登录的用户，那么为什么不由该用户使用相同的用户名和密码呢？这是代表那个用户的。）

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.
（这里的问题是，你登录的API无法区分用户带着他们的凭据出现和恰好拥有用户凭据的软件出现。这是非常重要的问题，原因有很多。首先，你不能限制API上可以访问的内容。假设我正在给我的银行账户记录提供访问权限。我可能需要一些东西来帮助我平衡开支等等。现在有很多很好的工具可以做到这一点。但是，如果我必须提供用户名和密码，它们可以在账户上做我能做的所有事情。它们可以关闭账户，可以进行交易，可以把我的所有钱转到其他地方。所有这些事情我都不想让他们做。）

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.
（我实际上并没有很好的方法说，“好吧，我只希望你能做这些有限的事情。重要的是，我希望他们登录的系统能够区分我和我给予一些访问权限的软件。” OAuth通过基本上创建一个称为访问令牌的制品来解决这个问题，该令牌不仅包含我作为最终用户的身份，还包括软件的身份，以及系统批准的那部分可以访问该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.
（这实际上是这个三元组，谁说可以，谁在请求，以及批准了什么，对吧？有了这种数学逻辑，可以理解为什么很多人说这是一个认证协议。它感觉像是一种授权类型的语言。最终，这就是你要输入的东西。通常，后端是这个用户，这个账户，这个行为，是或不是。这不是OAuth实际在做的事情。OAuth提供了将这种权威委托给该软件的手段。）

[0:16:31] GV: OAuth has been around a long time, I believe 20 years, possibly.
（GV：OAuth已经存在很久了，我认为20年应该有了。）

[0:16:37] JR: Almost, yeah. If we count OAuth 1, that was around 2006.
（JR：差不多吧。如果从OAuth 1算起，那大概是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 1, 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.
（GV：确实如此。再次强调，可能从一个较高层次上，我想知道核心的改变是什么，因为OAuth 2已经远远超过了1版本，正如您所指出的，它至今仍在广泛使用，几乎在互联网的每个角落都可以看到。那个飞跃性的改变是什么？显然，这非常重要。）

[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.
（JR：在OAuth 1和OAuth 2之间有很多变化。首先，OAuth 1是由一群非常聪明的人在开源会议（OSCon）的一个后屋里共同制定的。他们一起提出了关于如何构建这个委托协议的想法，将其命名为OAuth，将其写成一份论文，发布到网上，人们开始构建和实现它，并且效果非常好。）

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.
（在OAuth 1发布几年后，随着人们开始构建和实施它，他们开始发现其中的一些局限性。OAuth 1在许多方面做得很正确，但也有一些不太对的地方。它有自己的专有签名机制，很容易出错，而且出错的方式很难识别。它假设始终是两个网站之间进行通信。它使用的加密技术是基于双方可以共享同一个密钥，而这个密钥对于所有的加密功能都是始终可用的。）

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.
（随着时间的推移，到了2008年、2010年，移动应用程序开始变得非常重要。基于JavaScript的，我们现在称之为SPA（单页应用程序）的东西，所有这些在OAuth世界，OAuth 1的世界中变得比以往任何时候都重要得多。OAuth 1主要是关于让一个网站能够与其他网站进行通信。在这方面，它做得还可以，但是当人们开始将其扩展到最初的用例之外时，问题就开始出现了。同样，当谷歌开始使用它，并真正将其扩展到它原本打算处理的规模之外时，问题也开始出现了。）

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?
（在OAuth 2中，我们一群人聚集在一起，在IETF（互联网工程任务组）会议上见面，因为您永远不应该让极客给自己命名，对吧？这是一个定义使互联网层运行的标准的组织。TCP/IP、TLS、HTTP等所有这些都是由IETF定义的。OAuth来到了IETF，我们就像：“我们有一个社区文档。”我们做的第一件事就是整理了一下，清理了原来设计中潜入的会话固定攻击，并将其作为像“这是一个存在的事物”一样发布出来。但那时，很多人聚在一起说：“你知道吗？我们可能可以做得更好。我们可以也许采取这些概念，采取这些模式，并以不同的方式真正解决它们。” 几个不同的团队聚在一起，就像：“如果我们这样做OAuth会怎样？如果我们改变这个方面会怎样？”）

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.
（在整个过程中，真正贯穿标准化工作的关键点是，在任何时候我们关于在哪里放置复杂性的决策时，我们都会尽可能地将它远离客户端应用程序。因为这里的核心理念是，就像你们的很多听众可能一样，大多数定期处理OAuth的人，他们作为客户端开发者处理它。你有需要调用的API，它们的文档说，你需要去实现OAuth才能调用我们。）

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.
（在这种情况下，重要的是要意识到安全不是开发者的目标。安全是开发者实现他们目标的障碍，他们想要调用他们想要的API。回到我之前所说的，我在协作系统方面的背景，我发现了同样的问题。安全模式正在阻碍我做我想做的事情，即连接数据和连接人。）

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.
（我们在设计OAuth 2时真的采取了这种心态，尽可能地使其对客户端开发者简单，但同时也使其能够以安全、可重复的方式进行操作，并且尽我们所能利用我们拥有的技术堆栈。我们从OAuth 1扩展了几个重要的概念。我之前提到了这个有限访问的整体理念。在OAuth 1中，它实际上仍然归结为你是获得访问权限还是没有访问权限。现在，你可以告诉它是特定客户端应用程序而不是我。例如，我可以说我这个版本的TweetDeck可以发送消息，但它不能公开发布，或者我想要的任何集合。这很好，但这都是受API愿意提供的限制。）

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.
（在OAuth 2中，我们明确划分了一个后来被称为OAuth范围参数的空间。范围背后的整个想法是，客户端现在可以说，嘿，这些是我想要做的事情。服务器可以对用户说，好吧，这个软件想要做什么？这些事情哪些是可行的？让用户参与这个安全对话，并有一个明确的记录，说明API是如何以可互操作的结构划分的，这是一个巨大的进步。因为我可以有一个应用程序请求读取权限，并且我只得到一个只限于读取权限的令牌。如果这个令牌被泄露，那它只会泄露这些内容。）

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.
（回到银行应用程序，我可以说我让你读取我过去六个月的记录。就这样。我有一个范围，正好是那组访问权限。这就是你将得到的所有内容。能够在协议中为这些API描述这一点是非常有力的进步。）

[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 ...
（GV：这真的很迷人。我是指，我喜欢听技术历史，这也是我为什么喜欢在SED上担任主持人的原因。我能够与实际参与制定这些技术的人交谈，无论是框架还是规范，这太棒了。我认为，事实上我们看待OAuth 2时，开发者现在认为授权，或者不完全是授权，抱歉，是委派，是——）

[0:23:13] JR: Both, really. Yes.
（JR：两者都是。）

[0:23:15] GV: - is OAuth 2. I mean, it's just fascinating.
（GV：OAuth 2的一部分，这也是很迷人的。）

[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. And 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.
（JR：我的意思是，真的很，OAuth 2的一个问题是它编码了很多模式。它并没有真正发明很多东西。它编码了人们正在做、想做或特别是人们试图通过OAuth 1做的事情，但在实践中出了错。例如，人们在使用OAuth 1时经常出错的很多事情之一就是签名机制。OAuth 2，我们决定，好的，默认一切都是持票人访问。客户端机密，实质上是一个你通过值呈现的密码，以表示“这是我的软件”。给你。而你得到的令牌是持票人令牌，这意味着你通过值呈现，没有其他任何超出拥有该值证明的东西给其他系统。这大大简化了人们能够参与的方式。）

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.
（然而，时至今日，10年，15年过去了，我们意识到我们所知道的那些系统的许多缺点正在开始困扰着人们。OAuth社区现在正在努力在整个OAuth堆栈中建立占有证明功能，建立令牌和客户端认证以及证明等等所有这些工作。实际上，它正在将这些相同的概念构建在上面，以便在需要时可以添加这些组件，并在最合适的时候进行构建。）

[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?
（GV：这很有道理。我们已经彻底讨论了OAuth。我们还有OpenID Connect，OIDC。对于一些听众来说，这可能是一个不太知名的术语，但我觉得它在今天我们讨论的所有内容中同样重要。那么，它与OAuth有什么关系，或者实际上是如何扩展OAuth的？在哪些情况下，我们会发现开发者或平台会超越纯粹的OAuth而使用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.
（JR：好吧，根据我的经验，很多说我们正在使用OAuth的开发者实际上是在使用OpenID Connect。他们会说，哦，我正在做OAuth，并且我得到了一个ID令牌。就像，好吧，你实际上是在做OpenID Connect。这是因为OpenID Connect对OAuth委托的应用非常聪明。实际上，发生的事情是，你有OAuth，你委托某些访问权限给一个软件片段。那么，如果我委托的是我是谁的 knowledge？现在在这里哪个用户的 knowledge？我将委托那个应用程序知道这一点的能力。）

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.
（因此，你采取的这个围绕提供授权的委托协议，现在提供了身份验证，因为它告诉你谁在那里。这些信息可以通过相同的渠道带回，并且可以通过相同的渠道请求。这就是OpenID Connect的真正巧妙之处。这种想法来源于几个不同的来源。有SAML实体的查找。Google有一个奇怪的混合体，它是OpenID的较旧版本，非常专注于Web重定向。OAuth 1，这是一个非常奇怪且不兼容的混合体，但Google的某个人把它拼凑在一起，它竟然能工作。）

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. And 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.
（它实际上是在OAuth 2上故意构建这些思想和实践作为应用程序。除了我得到去调用所有这些API的访问令牌外，我还得到一条消息发送回给我，即客户端，来说，嘿，这个用户现在正在登录。我们可以使用所有这些相同的范围机制、所有这些相同的令牌机制来委托同样的权威，了解谁在那里。）

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.
（例如，当我进入OpenID Connect并构建用户的个人资料时，我需要获取他们所有的扩展资料信息，包括地址和电子邮件以及所有其他东西。嗯，我可以做一个API调用来做这件事。这个API调用是由OAuth访问令牌保护的。这个访问令牌就是我在说谁是用户时得到的那个OAuth访问令牌。同一个访问令牌也可以用来获取他们的日历信息，或者查看他们的银行账户历史，或者获取他们的健康记录，或者任何其他我想与之交谈的垂直API。实际上，这两个协议组合在一起的力量就在于此，这也是为什么我相信它们真的以这种方式起飞。它们在非常重要的方面相互补充。）

[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?
（GV：是否可以说OpenID Connect与单点登录（Single Sign-On）同义，或者这两个缩写是如何工作的？）

[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.
（JR：单点登录实际上是一个更广泛的概念，OpenID Connect是实现单点登录体验的一种协议。单点登录最终真的是关于用户体验。它关乎用户不必在多个空间输入凭据，或管理不同的账户，诸如此类。因为甚至比单点登录更广泛的是联合身份验证。我可能不会有一个完整的单点登录体验。可能会有步骤来说，嘿，这个网站正在尝试在这里登录你。这样可以吗？我们需要审计这个。我们需要批准这个并设置这个等等。）

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.
（你访问不同的Google应用程序，你被OpenID Connect左跳右跳，对吧？到处都是。你没注意到，因为你登录到你的Google账户，然后你就到了所有这些应用程序中。这是联合身份验证系统实际上能给你的最强大的东西之一。如果我忽略了其他现有的联合协议，比如SAML，以及人们发明了各种奇怪的专有协议，那将是失职的。）

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.
（回答问题的答案已经非常长了。那就是OpenID Connect可以用来实现单点登录。在我看来，它可能是今天市场上最好的标准方式来实现单点登录。）

[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.
（GV：是的，这很有道理。再次，我认为对于大多数听众来说，单点登录的接触点有助于他们理解OpenID Connect如何融入他们的生活，无论他们是否意识到这一点。现在，我认为在这里已经相当清楚了，我们已经讨论了很多关于OAuth和OpenID Connect的内容。两者都需要投入很多，然后将它们实施到平台上的能力或努力也希望在此时已经得到了相对的理解。这不是一个可以忽视的努力。）

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?
（这自然引导我们谈到Authlete，或者回到Authlete。现在，让我们在了解了平台底层的基础上，谈谈Authlete。Authlete作为开发者对你有什么帮助？）

[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?
（JR：实际上，我想先谈谈我多年来的一点观察。当与很多开发者交谈时，尤其是那些从客户端角度接触OAuth的人，他们说，好吧，现在我需要在API上实现资源服务器，或者我需要实现授权服务器。客户端很容易，所以其余的部分能有多难呢？）

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.
（几年前，我有幸与他人合著了一本关于OAuth的书，书名是《OAuth 2 in Action》。实际上，Authlete这家公司帮助赞助了那本书的日文翻译。现在，我想，那本书已经在全球推出了四种语言版本。无论如何，我在那本书中与合著者做的一件事就是引导读者从头开始实现OAuth系统的所有主要部分。我们试图清楚地指出，在这些练习中，你正在构建一个符合标准的东西。我们展示给你看，这是错误路径，这是你必须经历的事情。但绝不是让你把它用在生产环境中。这并不是为了那个目的。因为书的空间有限，有很多其他的内容是无法涉及的。）

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真正发挥作用的地方是，对于那些可能有过“有多难”的想法，然后意识到有多难的开发者，或者，从经验中知道，试图配置其他系统或构建其他系统时，有很多事情可能会出错，有很多事情你希望能够调整、监控和审计，随着协议经历其不同的动作。）

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在这个领域真正闪耀，是因为开发者希望构建一些东西。你想要定制的东西。你希望它实际上能在你的环境中运行，用你的编程语言。你不想为了部署东西而不得不去学习.NET，或者你想要做什么的语言。你不想为了能够做你现在做的事情而必须在某个特定的平台上构建东西。你希望以一种对你的环境和有意义的方式将其集成到你的系统中。）

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.
（Authlete通过处理这些困难的部分，所有这些像确保所有这些参数都在正确位置的琐事，帮助你。如果有人提交刷新令牌请求，他们没有发送客户端ID参数，这意味着什么？结果是，这取决于你正在进行的流程。你正在使用哪种客户端身份验证方法？你最初是否使用Depop来绑定令牌？有很多问题你需要能够提出并得到好的答案。）

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? And 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? And 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.
（正因为如此，Authlete实际上可以为你处理所有这些问题，因为你在代码中做的事情就是将传入的请求打包成API调用，并将其发送到Authlete，说，那么我现在该怎么办？下一步是什么？从开发者的角度来看，很多东西，坦率地说，感觉真的很像，如果你有一个只需要做OAuth事情的库，然后你往里面扔一些东西，比如说，哦，我有个令牌端点调用。答案是什么？在这种情况下应该怎么做才是正确的？库会回复说，哦，这是一个有效的响应。这是与之一致的令牌。把它给他们，你就继续前进吧。Authlete真的承担了这部分工作。）

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. And 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. And That's all your code really needs to do if it wants to.
（问题在于，通过基本上给你这个调用SDK，但它背后是一个实时的服务。它可以有状态。它可以随着时间的推移管理事物。它可以有存储。它可以有所有这些你不需要在应用程序中考虑的其他知识，对吧？如果在这个过程中做出了其他决定，比如说，哦，这个客户端实际上已经被停用了，不要给它令牌。Authlete在管理这个。它会说，嗯，实际上，不行。然后你只需要说，请求错误，未知客户端ID。这个信息已经以JSON格式为你准备好了。祝你愉快。如果你的代码想要这样做，那就足够了。）

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 had been implemented and what that flow would have been without Authlete and with and what's been measurably improved using Authlete?
（GV：这很有道理。我想，也许我们可以通过一个公司或客户的例子来具体化它，无论是虚构的，还是真实的。你能举一个Authlete已经实施的例子吗？以及在没有Authlete的情况下，那个流程会是怎样的？使用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.
（JR：当然。Authlete在金融领域找到了一个非常大的市场，尤其是在日本，这是公司成立的地方。其中一个原因是银行和其他金融机构真的不想放弃终端用户信息。他们不会想交出客户账户等信息。他们真的想把这些东西掌握在自己手中。这可能是出于隐私和监管原因，或者只是不把东西发出去的企业文化。如果你是一家银行，你需要实施这些措施，你要么付很多钱给某人运行一个完整的堆栈，并在你完全控制的专用环境中运行。很多云服务提供商没有这个选项，不允许你这样做。）

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.
（如果你处在一个你自己拥有用户账户，拥有认证路径，拥有所有这些数据，并且不想放弃这些数据的环境中，那么你真正需要做的是有一个只在进行API访问，在登录另一个应用程序，在处理这个特定边界时才会介入的系统。然后其他任何时间，你都需要把那款软件放到一边。你不想处理那件事。）

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.
（我们金融领域的客户发现Authlete给了他们掌握所有这些信息的能力。我们不存储用户账户。我们不存储姓名、密码、地址、账户号码等所有这些信息。他们告诉我们，我需要一个访问令牌，其主题标识符具有以下权限。然后你给我答案。你制作那个访问令牌，完成所有这些事情。）

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.
（在Authlete，我们不知道这一切意味着什么。我们不在乎这一切意味着什么。我们的客户代码正在管理不同事物之间的这种映射。这对我们的客户来说是一个非常强大的模式，因为他们既保留了控制和灵活性，同时也不用担心OAuth和OpenID实际上提供的这种互操作性层的细节。）

[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?
（GV：Authlete是否会更倾向于这种情况呢？我的意思是，银行是这种情况的一个更极端的版本，但我考虑到公司的规模，以及Authlete在那个规模中的位置，特别是如果你有多个团队、多个产品，但它们都需要共享对单个客户是谁以及他们有什么权利的理解，然后他们采取服务器之外的途径来设置。这是Authlete擅长的吗？）

[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.
（JR：诚实地讲，我会说这是OAuth本身擅长的领域，当你需要为多个系统提供一个抽象的安全层，但又希望在整个系统中有一个统一的概念来确定用户是谁以及他们有什么权限。因为这关乎委托。OAuth没有指定你正在委托什么，或者你正在委托的内容是什么。它只是提供了这样做的方法。）

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.
(实际上，在这种情况下，我就会告诉一家公司，好吧，这就是你需要开始使用OAuth的地方。你有需要保护的东西，它们可能有点不同，你希望以一种安全的方式将它们集中起来，并通过授权服务器进行处理。)

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.
(Authlete真正的优势在于，一旦你意识到自己正沿着这条道路前行，当你开始回答如何到达那里、想要做什么等问题时，Authlete的优势就体现出来了。因为Authlete是一个半托管系统，它非常适合这样一个特定的细分市场，即你需要一个管理你的用户、客户以及实际将授权应用程序等东西的人的东西。你只需要将这个东西推广到其他系统中，而不需要将客户账户的控制权交给他人。这就是Authlete真正擅长的领域。)

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 umm... 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.
(我会说，我们从非常小的公司起步，这些公司只有一两个需要保护的API，以及少数几款应用程序，他们不愿意处理这些安全互操作协议的所有复杂性。然后我们扩展到拥有数百个API和数千名客户或更多，以及数百万用户的大型公司。我们的一个客户有一个电视节目，这是一个电视节目。这是我的理解。我并不直接从事客户方面的工作。但是在与他们的工程师交谈时，他们有一个电视节目，每隔一段时间，他们的扩展就会达到顶峰，因为每个人都给他们的最爱打电话投票，对吧？不是每个人都打电话，他们登录系统并说，不，这是这个比赛的赢家，等等。)

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. And That's where we work with them to figure out like, okay, yeah, this is this setting, this whatever. Really typical integration stuff.
(我甚至不知道该客户的其他堆栈运行在什么上面，但我不需要知道，因为在与他们的工程师交谈时，他们说，我们需要在这里得到这个字段，以便这个API知道要做什么。这就是我们与他们一起研究的地方，好的，这个设置，这个无论什么。都是非常典型的集成工作。)

[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.
(GV：是的，这是一个关于实用场景的有趣例子，我相信它为我和大家提供了一个更多关于这种情况的背景。)

[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.
（JR：我只是想说，我并不在运维这边，但那个项目的数据让我大开眼界，看到使用图表的峰值达到那种程度，真是令人印象深刻。这真的很惊人。）

[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. And 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.
（GV：非常酷。如果我们向前看，我想，只是看看周围，现在市场上有很多参与者，他们都在说，好吧，我们消除了这个痛点。他们从许多不同的角度来处理这个问题。我们有公司提供卓越的JWT。我们之前有一集谈到了这个问题。Passkeys可能是最大的一个，它正在全面推广。我非常想听听它如何与Authlete相适应或不相适应。还有其他参与者，我们以Supabase为例，他们提供作为服务的后端，而认证授权是其中的一个重要部分。）

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 kind of 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. So taking all these things to account, where is Authlete maybe different and what's the kind of 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?
（对于许多开发者来说，这是一个单向门决策。你不想不得不向某人解释我们现在为什么要撤销我们实施的认证授权系统以及所有的事情，通常情况下，我猜，有很多重新工作用户甚至意识不到。哦，我们不得不重置您的帐户等。所以考虑到所有这些问题，Authlete可能在哪些方面有所不同，以及我们已经覆盖了哪些方面，但我认为只是大致总结一下，Authlete在所有这些其他已知的方法中都能发挥出色的完美场景是什么？）

[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.
(JR：让我们以Passkeys为例。Passkeys是在非密码基础认证方面的一项卓越技术。正如我们之前讨论的，OAuth不是一个认证协议。OpenID Connect为您提供了认证，但它特别为您提供了与最终用户的凭据分离的认证。Passkeys完全关于最终用户的凭据。能够识别并重复使用同一设备作为不同的凭据，作为多个不同网站上的不同认证器，这样其他网站就不知道你是谁。)

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鈥檚 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.
（另一方面，OpenID Connect则表示，您有一个账户，并希望这个账户能在不同的应用程序中被识别。OAuth表示，您有一个账户，并希望这个账户能够控制对一系列事物的访问。从Authlete的角度来看，如果我们的客户想要实现Passkeys，这实际上并不会改变任何东西。我们看不到这个过程的部分。）

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.
（当我之前谈论Authlete在客户自己的终端用户体验中半托管时，所有这些终端点，以及终端用户登录身份提供者的整个过程，我们看不到任何东西。我们不拥有这部分。我们等待客户软件说，这个登录的用户就是某人。无论哪个软件说过用户已登录，他们都把东西放入我们的客户放入API中说，这个是用户。给我一个代表他们的ID令牌和访问令牌。）

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.
（我们不检查用户ID，因为我们假设客户代码已经解决了这个问题。这不是我们在为他们解决的问题。如果我们有一个客户实现了Passkeys作为认证方法，下游的整个堆栈都不会改变。他们实现Passkeys，他们实施多因素认证，他们实施基于风险引擎的会话管理，这不会改变其他体验。我们的客户可以拥有他们经历整个过程。）

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, 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.
（在另一端，有你这样的人，就像，“不，我不想交出这个。我想我需要想办法做到这一点。” 这时，你会得到非常小的东西，比如你拥有栈中的一切，你自己实现它，其中很多是开源实现类型的事情。在某些情况下，在许多情况下，这是有意义的。多年来，我一直是一个开源实现OpenID Connect的维护者，它正在做这件事。这就好比，你拥有整个联合过程。无论你如何构建所有用户，你都在自己运行一切。这对我们以及当时构建它的团队来说是有意义的，对那些拿走并部署它的人来说也是有意义的。人们仍然在使用它。这很好。）

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?
（Authlete在这个领域中非常独特，因为它填补了人们并不真正知道存在的空白。我记得很早以前我和Taka的第一次交谈。我们坐下来，他开始向我解释Authlete是如何工作的。我记得我当时想，这听起来太奇怪了。你为什么要这样做？这一切都没有意义。它不符合我之前听过的任何模式。我就像，为什么我只交出那一片东西？为什么我不把一切都交出？如果我要走那么远，为什么不呢？）

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.
（我越多地与Taka谈论这个问题，就越意识到Authlete在什么是服务以及你自己处理的内容方面所做的划分，坦率地说，这是非常巧妙的。与市场上很多其他产品相比，它非常独特。然后我意识到，在那天交谈后不久，事实上，我们正在构建的开源项目实际上做出了同样的划分，因为我们是为了一个我们已经建立了用户账户管理的环境而构建它的。我们已经有一个单点登录的主要登录系统。我们只需要联邦服务。我们只需要令牌委派之类的东西。我们只是在现有的不提供这些功能的身份平台之上构建。但是，通过我们构建、运行和自行完成一切的开源项目。）

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.
（我意识到Authlete正在做一些类似的事情，但以一种不同的方式，以一种真正面向服务的方式。对于那些你已经通过一些软件堆栈管理用户、账户和身份验证的情况，这非常有意义。现在，你真的想要进行高级联邦操作。你想要做高级OAuth类型的事情，而不必 necessarily学习或维护如何做到所有这些。）

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.
（我总是很难说Authlete的竞争对手是谁，因为我实际上还没有找到一个像我们这样切割事物的产品。我们的竞争对手正在以不同的方式做事。我会直接告诉人们，在某些用例中选择它们是有意义的。我们正在做的模式并不是旨在普遍适用。我们知道它不是。如果我们说，哦，这对每个人在任何地方都绝对有意义，那我们就是在说谎。并不是。）

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.
（问题是，很多人并没有意识到这是一种实际构建系统的方式。他们感觉自己要么被拉入一切都在云端托管，然后不得不接受服务提供商提供的 whatever integration points，这可能远远不足以满足你的需求，要么是自己构建和运行一切，在这种情况下，你必须负责维护、扩展，以及理解系统中每一部分通过系统到底意味着什么，对系统的其他部分有何影响。这是一项巨大的工作。）

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.
（Authlete在这两个极端之间找到了一个适合许多不同情况的合理位置。是的，我很高兴我们能够讨论这种差异为什么存在，因为我知道一开始这对我来说并不容易理解。但我会告诉你，现在这真的很明白了。我认为这种特定的抽象背后有很大的力量，特别是在当今的分布式云环境中，你可能正在从许多不同的小块中构建你的系统，这些小块执行不同的专业任务。拥有一个专门处理高安全性委派和联合身份验证的模块真的非常有意义。）

[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, yep, 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?
（GV：我这里提出一个类比，让我们看看会发生什么。我非常喜欢飞行，而且每当涉及到零信任事物时，我认为机场是一个很好的例子。我们几乎可以描述它的方式，例如，对于航空公司，你走进办理登机手续的地方。现在，航空公司可以随心所欲地说，好吧，我知道你是Gregor。是的，我们查看你的护照。是的，那就是你。每个航空公司都有自己的决定，决定如何表达，是的，我们知道是你。最终，它必须提供一张登机牌。这张登机牌包含了一堆信息。他们可以去哪里？他们可以上哪架飞机？他们可以进入贵宾室吗？航空公司不拥有登机牌系统。他们只是对登机牌系统说，嘿，我们知道是Gregor。给我一张登机牌。这个类比在这里适用吗？）

[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.
（JR：我认为登机牌是一个非常有趣的东西，因为在很多情况下，登机牌最终起到了不记名令牌的作用。当我出示登机牌时，在许多情况下，他们并不会检查以确保我是登机牌上打印的名字所对应的人类。我拥有这张登机牌这一事实已经足够证明我能够获得登机牌。OAuth携带令牌就是这样工作的。）

If you start to look around to, you know, 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.
（如果你开始观察周围的情况，你知道，我见过一些航空公司这样做，还有一些，特别是那些附加服务，比如贵宾室 access 和诸如此类的东西，他们会同时要求你出示护照和登机牌。这实际上是一种证明持有关系的事情。在这种情况下，他们想要看到，好吧，你有表明你可以做什么的登机牌。然后你有了你与表明你可以做什么的东西之间的绑定，以证明你是被允许实际拥有这个东西的人。因此，你是被允许做这件事的人。）

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, yep, 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.
（我认为这个类比很好地说明了OAuth和委派系统最终是如何工作的。对于很多人来说，这个类比也熟悉，因为它展示了互操作性是如何工作的。正如你所说，航空公司本身并不拥有登机牌的格式。他们也不拥有信息的排列方式。这些都是需要协商一致的。每个航空公司都会说，是的，我们会放置这些信息，并确保这个条形码是每个人都能读取的特定格式。这一切并不是凭空发生的。这就是标准化真正发挥作用的地方。）

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.
（我见过一些小型地区机场也有类似的做法。航空公司不能在招牌上有自己的名字，因为那天早上他们在哪个柜台，那就是他们使用的柜台。在其他地方，你会走进去，会有27个柜台专门为达美航空服务。然后还有30个柜台专门为联合航空服务，并且这些柜台将始终属于那家航空公司，直到航空公司搬出机场，这意味着在这些空间里，他们对自己的整个体验和整合流程有更高的控制权。机场基本上是在说，好吧，你必须打印出一份登机牌。它需要看起来像这样。你自己想办法做到这一点。从哪里获取你的打印机是你的事。从哪里获取你的图像格式化工具也是你的事。从哪里获取你的信息存储也是你的事。你自己想办法构建那个集成系统。重要的是，无论你从这个过程中输出什么，它需要与其他的一切兼容工作。）

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.
（那种互操作性，实际上就是OAuth的含义。无论你如何获得访问令牌，你为了获得它所采取的无论什么过程都需要与其他现有的东西兼容工作。这确实是遵守标准和参与标准制定的重要性，这也是我加入Authlete之前，Authlete的文化中一个巨大的部分。正如我所说，我个人在标准化领域有很多背景。Authlete的创始人就是通过我在列表上发帖和参与标准化过程来了解我的。他们也是在查看那些四处漂浮的东西，比如，“哦，是的。不，这是我们感兴趣做的东西。”）

So 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.
（因此，Authlete的很多工作都是我们关注即将出台的标准，比如那些还没有完成的标准。我们实施过FAPI 2，这是来自OpenID Foundation的高安全性标准集合。我们已经有超过一年或两年的时间实施了符合标准的实施，而该标准刚刚现在完成。在我们公司文化中，这是一个非常重要的部分。）

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?
（GV：是的，我觉得我们在这次讨论中已经回到了原点，这是一个很好的循环，回到了一切开始的地方，也就是标准。显然，这也必须是产品演化的一个部分。如果有人喜欢他们所听到的，或者更准确地说，他们看到了适合的地方，因为这次讨论中一个很大的部分是Authlete适合在哪里？它可能不适合在哪里？如果有人一直在听，并且听到了那种适合，那么人们应该在哪里发声，以了解更多关于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.
（JR：我建议人们去访问authlete.com/developers。Authlete作为一个产品，真的是面向开发者的。就是，使用Authlete的人是那些正在构建东西的人。我们很多资源都是针对这一点的。它是一家非常注重工程师和以工程师为导向的公司。Authlete.com/developers有很多很好的资源。你可以注册一个账户来试用，并查看我们那里可用的其他资源。这些资源不仅仅是关于Authlete本身，还包括我们实际上启用的标准和系统。）

[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.
（GV：太棒了。Justin，我非常享受今天的讨论。我学到了很多，我相信我们的听众也一样。我想祝你和Authlete都顺顺利利。我希望将来我们还有机会再相逢。）

[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.
（JR：非常感谢你们邀请我来这里。这太棒了。我期待我们能够进行更多的讨论。）

[1:00:33] GV: Thank you.
（GV：谢谢你。）

[END]