每个人都可以理解的授权访问和身份认证 #8009
Merged
每个人都可以理解的授权访问和身份认证 #8009
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
辛苦啦，这么长 |
|
My pleasure~ |
|
校对认领：） |
PassionPenguin
suggested changes
Feb 8, 2021
|
|
||
| Maybe you got the job done, but you really weren't clear on **what** was happening behind the scenes, or **why** things were being done a certain way. If you'd like to build a foundational understanding of what goes on behind the scenes when using OAuth 2.0 and OpenID Connect standards, read on! | ||
| 就算你已经做完了所有工作，但你一定不清楚一系列操作的背后发生了**什么**，或者是**为什么**能用特定的方式实现功能。如果你想要对 OAuth 2.0和 OpenID 连接规范有更深、更基础的理解，那么就请继续读下去吧~ |
There was a problem hiding this comment.
Suggested change
| 就算你已经做完了所有工作，但你一定不清楚一系列操作的背后发生了**什么**，或者是**为什么**能用特定的方式实现功能。如果你想要对 OAuth 2.0和 OpenID 连接规范有更深、更基础的理解，那么就请继续读下去吧~ | |
| 就算你已经做完了所有工作，但你一定不清楚一系列操作的背后发生了**什么**，或者是**为什么**能用特定的方式实现功能。如果你想要对 OAuth 2.0 和 OpenID 连接规范有更深、更基础的理解，那么就请继续读下去吧～ |
|
|
||
| However, neither were true. I [formerly worked for Auth0](https://auth0.com), a company that manages **digital identity**. (I'm now a member of the [Auth0 Ambassadors program](https://auth0.com/ambassador-program), and a [Google Developer Expert](https://developers.google.com/) in SPPI: Security, Privacy, Payments, and Identity.) | ||
| 然而，都不是。我之前为 [Auth0](https://auth0.com) 工作，这是一个管理**数字证书**的公司。我现在是 [Auth0 大使计划](https://auth0.com/ambassador-program)的一员，也是 SPPI (安全、隐私、支付、认证)方向的[谷歌开发专家](https://developers.google.com/)。 |
There was a problem hiding this comment.
Suggested change
| 然而，都不是。我之前为 [Auth0](https://auth0.com) 工作，这是一个管理**数字证书**的公司。我现在是 [Auth0 大使计划](https://auth0.com/ambassador-program)的一员，也是 SPPI (安全、隐私、支付、认证)方向的[谷歌开发专家](https://developers.google.com/)。 | |
| 然而，都不是。我之前为 [Auth0](https://auth0.com) 工作，这是一个管理**数字证书**的公司。我现在是 [Auth0 大使计划](https://auth0.com/ambassador-program)的一员，也是 SPPI (安全、隐私、支付、认证)方向的[谷歌开发者专家](https://developers.google.com/)。 |
|
|
||
| Once a system has been able to establish this, we come to... | ||
| 在一个系统能够实现身份认证后，我们就来到了下一个概念。 |
There was a problem hiding this comment.
Suggested change
| 在一个系统能够实现身份认证后，我们就来到了下一个概念。 | |
| 当一个系统能够实现身份认证后，我们就…… |
这里不仅仅是概念吧，应该是直接到下一动词
当一个系统能够实现身份认证后，我们就开启授权访问功能？
There was a problem hiding this comment.
或者：当一个系统能够实现身份认证之后，我们就要考虑如何为它实现授权访问功能。
There was a problem hiding this comment.
或者：当一个系统能够实现身份认证之后，我们就要考虑如何为它实现授权访问功能。
|
|
||
| ## OAuth 2.0 | ||
|
|
||
| [OAuth 2.0](https://tools.ietf.org/html/rfc6749) is one of the most frequently mentioned specs when it comes to the web — and also one that is **often mis-represented or misunderstood**. How so? | ||
| 当我们谈论 web 规范的时候，[OAuth 2.0](https://tools.ietf.org/html/rfc6749)是最经常被提到的规范，也是**最容易被误解**的一个，为什么呢？ |
There was a problem hiding this comment.
Suggested change
| 当我们谈论 web 规范的时候，[OAuth 2.0](https://tools.ietf.org/html/rfc6749)是最经常被提到的规范，也是**最容易被误解**的一个，为什么呢？ | |
| 当我们谈论 Web 规范的时候，[OAuth 2.0](https://tools.ietf.org/html/rfc6749)是最经常被提到的规范，也是**最容易被误解**的一个，为什么呢？ |
|
|
||
| To understand the purpose of OAuth, we need to do go back in time. OAuth 1.0 was established in December 2007. Before then, if we needed to **access third party resources**, it looked like this: | ||
| 为了理解 OAuth 的目的，我们需要看看它的发展历史。 OAuth 1.0在2007年12月出台。在此之前，如果我们需要**访问第三方资源**，就会发生如下过程： |
There was a problem hiding this comment.
Suggested change
| 为了理解 OAuth 的目的，我们需要看看它的发展历史。 OAuth 1.0在2007年12月出台。在此之前，如果我们需要**访问第三方资源**，就会发生如下过程： | |
| 为了理解 OAuth 的目的，我们需要看看它的发展历史。OAuth 1.0 在 2007 年 12 月出台。在此之前，如果我们需要**访问第三方资源**，就会发生如下过程： |
|
|
||
| MyCalApp will then issue an **access token** to HireMe123. HireMe123 can use that access token to call the MyCalApp API within the scope of permissions that were accepted by you and create events for you using the MyCalApp API. | ||
| 然后 MyCalApp 会给 HireMe123 发送一个**访问令牌**。 HireMe123 之后使用这个访问令牌在你同意过的权限许可的范围内调用 MyCalApp 的 API 并使用 API 来创建一个事件。 |
There was a problem hiding this comment.
Suggested change
| 然后 MyCalApp 会给 HireMe123 发送一个**访问令牌**。 HireMe123 之后使用这个访问令牌在你同意过的权限许可的范围内调用 MyCalApp 的 API 并使用 API 来创建一个事件。 | |
| 然后 MyCalApp 会给 HireMe123 发送一个**访问令牌**。HireMe123 之后使用这个访问令牌在你同意过的权限许可的范围内调用 MyCalApp 的 API 并使用 API 来创建一个事件。 |
|
|
||
| **Nothing insidious is happening now!** **MyCalApp is asking the user to log in with MyCalApp**. HireMe123 is **not** asking for the user's MyCalApp credentials. The issues with sharing credentials and too much access are no longer a problem. | ||
| **此处没有什么不可告人的事情发生！** **MyCalApp 正在要求用户登录 MyCalApp** 。 HireMe123 并**没有**请求用户的 MyCalApp 证书。共享证书和过多访问权限再也不是问题了。 |
There was a problem hiding this comment.
Suggested change
| **此处没有什么不可告人的事情发生！** **MyCalApp 正在要求用户登录 MyCalApp** 。 HireMe123 并**没有**请求用户的 MyCalApp 证书。共享证书和过多访问权限再也不是问题了。 | |
| **此处没有什么不可告人的事情发生！** **MyCalApp 正在要求用户登录 MyCalApp** 。HireMe123 并**没有**请求用户的 MyCalApp 证书。共享证书和过多访问权限再也不是问题了。 |
|
|
||
| At this point, I hope it's been made clear that **OAuth is for delegated access**. It doesn't cover **authentication**. At any point where authentication was involved in the processes we covered above, login was managed by whatever login process HireMe123 or MyCalApp had implemented at their own discretion. OAuth 2.0 **didn't prescribe how** this should be done: it only covered authorizing third party API access. | ||
| 在这里，我希望 **OAuth 是一个授权访问协议**是一个足够清楚的事实，它不包含**身份认证**。在上述过程中的任一环节都不包含有身份认证，登录被 HireMe123 或是 MyCalApp 上不同的登录过程所控制。 OAuth 2.0在这里**并不规定**这个行为应该怎么做，它只是负责授权第三方访问 API。 |
There was a problem hiding this comment.
Suggested change
| 在这里，我希望 **OAuth 是一个授权访问协议**是一个足够清楚的事实，它不包含**身份认证**。在上述过程中的任一环节都不包含有身份认证，登录被 HireMe123 或是 MyCalApp 上不同的登录过程所控制。 OAuth 2.0在这里**并不规定**这个行为应该怎么做，它只是负责授权第三方访问 API。 | |
| 在这里，我希望 **OAuth 是一个授权访问协议**是一个足够清楚的事实，它不包含**身份认证**。在上述过程中的任一环节都不包含有身份认证，登录被 HireMe123 或是 MyCalApp 上不同的登录过程所控制。OAuth 2.0在这里**并不规定**这个行为应该怎么做，它只是负责授权第三方访问 API。 |
|
|
||
| This is called the **confused deputy problem**. HireMe123 doesn't know **where** this token came from or **who** it was issued for. If we recall: **authentication is about verifying the user is who they say they are**. HireMe123 can't know this from the fact that it can use this access token to access an API. | ||
| 这种问题叫做**困惑的副手问题**。 HireMe123 不知道这个令牌来自何处或者是这个令牌曾经发行给谁。如果我们还记得一开始的定义：**身份认证是关于确认这个用户是否是他自称的身份**，那么 HireMe123 无法从利用该访问令牌访问 API 的过程中得到这种信息。 |
There was a problem hiding this comment.
Suggested change
| 这种问题叫做**困惑的副手问题**。 HireMe123 不知道这个令牌来自何处或者是这个令牌曾经发行给谁。如果我们还记得一开始的定义：**身份认证是关于确认这个用户是否是他自称的身份**，那么 HireMe123 无法从利用该访问令牌访问 API 的过程中得到这种信息。 | |
| 这种问题叫做**不明的代理问题**。HireMe123 不知道这个令牌来自何处或者是这个令牌曾经发行给谁。如果我们还记得一开始的定义：**身份认证是关于确认这个用户是否是他自称的身份**，那么 HireMe123 无法从利用该访问令牌访问 API 的过程中得到这种信息。 |
There was a problem hiding this comment.
我搜了下，confused deputy problem 并没有很官方的翻译。所以，我觉得原作者的翻译也是 OK 的。
There was a problem hiding this comment.
我记得翻译成“困惑的副手问题”是可以搜到结果的，“不明的代理问题”可能不利于读者继续定位问题或者探索。那我在这里把中英文都写上好啦~
|
|
||
| This brings us to the specification called [OpenID Connect](https://openid.net/specs), or OIDC. OIDC is a spec **on top of OAuth 2.0** that says how to authenticate users. The [OpenID Foundation (OIDF)](https://openid.net/foundation/) is the steward of the OIDC standards. | ||
| 接下来我们要了解的规范叫做 [OpenID 连接](https://openid.net/specs)，也被称作 OIDC。 OIDC 是一个**基于 OAuth 2.0**的规范，它规定了如何认证用户的身份。[OpenID 基金会 (OIDF)](https://openid.net/foundation/) 是 OIDC 标准的管理者。 |
There was a problem hiding this comment.
Suggested change
| 接下来我们要了解的规范叫做 [OpenID 连接](https://openid.net/specs)，也被称作 OIDC。 OIDC 是一个**基于 OAuth 2.0**的规范，它规定了如何认证用户的身份。[OpenID 基金会 (OIDF)](https://openid.net/foundation/) 是 OIDC 标准的管理者。 | |
| 接下来我们要了解的规范叫做 [OpenID 连接](https://openid.net/specs)，也被称作 OIDC。OIDC 是一个**基于 OAuth 2.0**的规范，它规定了如何认证用户的身份。[OpenID 基金会 (OIDF)](https://openid.net/foundation/) 是 OIDC 标准的管理者。 |
|
一共 15 处出现符号后跟空格，可直接用 另外： penguin@Penguins-MBP ~ % markdown tmp.md
/Users/penguin/tmp.md
12:77-12:78 space-round-number No space between Chinese and number. 'uth 2.0和 Ope'
66:91-66:92 space-round-number No space between Chinese and number. 'uth 2.0代表用户给'
70:39-70:40 space-round-number No space between Chinese and number. 'uth 1.0在2007'
70:40-70:41 space-round-number No space between Chinese and number. 'th 1.0在2007年'
70:44-70:45 space-round-number No space between Chinese and number. '.0在2007年12月出'
70:45-70:46 space-round-number No space between Chinese and number. '0在2007年12月出台'
70:47-70:48 space-round-number No space between Chinese and number. '2007年12月出台。在'
74:64-74:65 space-round-alphabet No space between Chinese and alphabet. '试约会）。但是HireM'
74:73-74:74 space-round-number No space between Chinese and number. 'reMe123没有自己的'
94:100-94:101 space-round-alphabet No space between Chinese and alphabet. '控制第三方对于API的访'
94:103-94:104 space-round-alphabet No space between Chinese and alphabet. '三方对于API的访问权限'
100:16-100:17 space-round-number No space between Chinese and number. 'uth 2.0重新审视 '
120:121-120:122 space-round-number No space between Chinese and number. 'uth 2.0在这里'
126:12-126:13 space-round-number No space between Chinese and number. 'uth 2.0为第三方服'
128:26-128:27 space-round-number No space between Chinese and number. 'uth 2.0是负责授权'
141:40-141:41 space-round-number No space between Chinese and number. 'uth 2.0误用于身份'
141:103-141:104 space-round-number No space between Chinese and number. 'uth 2.0的基础上'
151:32-151:33 space-round-alphabet No space between Chinese and alphabet. '用户身份。ID令牌是供第'
169:1-169:4 no-empty-code-lang Language of code can not be empty.
185:1-185:4 no-empty-code-lang Language of code can not be empty.
213:1-213:4 no-empty-code-lang Language of code can not be empty.
238:1-238:4 no-empty-code-lang Language of code can not be empty.
283:24-283:40 no-space-in-link Link content can not start / end with space. ' OAuth 2.0和授权服务器'
283:34-283:35 space-round-number No space between Chinese and number. 'uth 2.0和授权服务'
301:2-301:3 space-round-alphabet No space between Chinese and alphabet. 'W我们在上面已经讲过了'
307:1-307:4 no-empty-code-lang Language of code can not be empty.
357:60-357:77 no-space-in-link Link content can not start / end with space. '基于角色的访问控制 (RBAC) '
361:4-361:14 no-trailing-punctuation Header content can not end with symbol. '资源，接下来是什么？'
373:12-373:13 space-round-number No space between Chinese and number. 'uth 2.0和 Ope'
373:88-373:102 no-space-in-link Link content can not start / end with space. ' OAuth 2.0授权框架'
373:98-373:99 space-round-number No space between Chinese and number. 'uth 2.0授权框架'
Lint total 1 files, 0 warnings 31 errors |
|
认领校对 |
|
@stuchilde 欢迎校对~ |
|
@stuchilde 别忘了有空来完成校对哈 |
evanzme
reviewed
Feb 26, 2021
| @@ -2,171 +2,169 @@ | |||
| > * 原文作者：[Kim Maida](https://dev.to/kimmaida) | |||
| > * 译文出自：[掘金翻译计划](https://github.com/xitu/gold-miner) | |||
| > * 本文永久链接：[https://github.com/xitu/gold-miner/blob/master/article/2021/authorization-and-authentication-for-everyone.md](https://github.com/xitu/gold-miner/blob/master/article/2021/authorization-and-authentication-for-everyone.md) | |||
| > * 译者： | |||
| > * 译者：[Ashira97](https://github.com/Ashira97) | |||
| > * 校对者： | |||
There was a problem hiding this comment.
Suggested change
| > * 校对者： | |
| > * 校对者：[司徒公子](https://github.com/stuchilde) |
evanzme
previously approved these changes
Feb 28, 2021
| --- | ||
|
|
||
| **Authentication is hard.** Why is this? Auth standards are well defined — but challenging to get right. And that's okay! We're going to go through it in an approachable way. We'll address the **concepts of identity step by step, building on our knowledge as we go along.** By the time we're done, you should have a foundation and know where you might want to dig deeper. | ||
| **身份认证是非常困难的**。为什么这么说？虽然身份认证标准拥有一套完善的定义，但是它也在一直接受挑战。好吧，我们将用易于理解的方式来学习这整个过程。我们会**一步一步地了解认证的概念，在逐步深入的过程中构筑自己的知识体系**。在我们结束这一过程的时候，我们会对认证相关的知识有基础的了解并且知道哪一部分知识是你更想要去深入研究的。 |
There was a problem hiding this comment.
Suggested change
| **身份认证是非常困难的**。为什么这么说？虽然身份认证标准拥有一套完善的定义，但是它也在一直接受挑战。好吧，我们将用易于理解的方式来学习这整个过程。我们会**一步一步地了解认证的概念，在逐步深入的过程中构筑自己的知识体系**。在我们结束这一过程的时候，我们会对认证相关的知识有基础的了解并且知道哪一部分知识是你更想要去深入研究的。 | |
| **身份认证是非常困难的**。为什么这么说？虽然身份认证标准拥有一套完善的定义，但要正确使用却很有挑战性。好吧，我们将用易于理解的方式来学习这整个过程。我们会**一步一步地了解认证的概念，在逐步深入的过程中构筑自己的知识体系**。在我们完成的时候，你应该有了一些基础，并知道哪一部分知识是你更想要去深入研究的。 |
|
|
||
| #### Digital Identity | ||
| #### 数字证书 |
There was a problem hiding this comment.
Suggested change
| #### 数字证书 | |
| #### 数字身份 |
翻译参照维基百科：https://zh.wikipedia.org/wiki/%E6%95%B0%E5%AD%97%E8%BA%AB%E4%BB%BD
|
|
||
| What does that mean? | ||
| 什么意思？ |
There was a problem hiding this comment.
Suggested change
| 什么意思？ | |
| 这是什么意思？ |
|
|
||
| This leads us to... | ||
| 这将引导我们走向下一个概念。 |
There was a problem hiding this comment.
Suggested change
| 这将引导我们走向下一个概念。 | |
| 这就把我们引向了... |
|
|
||
| In a broad sense, **authentication** refers to the process of verifying that a user is who they say they are. | ||
| 广义上来讲，**身份认证**指的是一个验证用户是否具有他自己声称的身份的过程。 |
There was a problem hiding this comment.
Suggested change
| 广义上来讲，**身份认证**指的是一个验证用户是否具有他自己声称的身份的过程。 | |
| 广义上来讲，**身份认证**指的是验证用户是否是他们自己声称的那个人的过程。 |
|
|
||
| Now that we know about the **anatomy** of a JWT, let's talk more about the **claims**, those statements from the **Payload Segment**. As per their moniker, ID tokens provide **identity** information, which is present in the claims. | ||
| 既然我们已经知道了 JWT 的组成部分，我们现在要学习的是**字段**。字段是**载荷段**中携带的一系列声明。正如它们的名字所表示的，ID 令牌在字段中提供了**身份认证**信息。 |
There was a problem hiding this comment.
Suggested change
| 既然我们已经知道了 JWT 的组成部分，我们现在要学习的是**字段**。字段是**载荷段**中携带的一系列声明。正如它们的名字所表示的，ID 令牌在字段中提供了**身份认证**信息。 | |
| 既然我们已经知道了 JWT 的组成部分，我们现在要学习的是 **Claims**。字段是**载荷段**中携带的一系列声明。正如它们的名字所表示的，ID 令牌在字段中提供了**身份认证**信息。 |
| * `aud` **(audience)**: the intended recipient of the JWT; for ID tokens, this must be the client ID of the application receiving the token | ||
| * `exp` **(expiration time)**: expiration time; the ID token must not be accepted after this time | ||
| * `iat` **(issued at time)**: time at which the ID token was issued | ||
| * `iss` **(发行人)**: JWT 的发行者, 例如授权访问服务器。 |
There was a problem hiding this comment.
Suggested change
| * `iss` **(发行人)**: JWT 的发行者, 例如授权访问服务器。 | |
| * `iss` **(发行人)**: JWT 的发行者, 例如授权访问服务器。 |
|
|
||
| [](https://res.cloudinary.com/practicaldev/image/fetch/s--48HiqoWr--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_66%2Cw_880/https://i.imgur.com/Nl1HyHD.gif) | ||
|
|
||
| Our entities here are: the **browser**, an **application** running in the browser, and the **authorization server**. When a user wants to log in, the app sends an authorization request to the authorization server. The user's credentials are verified by the authorization server, and if everything checks out, the authorization server issues an ID token to the application. | ||
| 在这里我们涉及到的实体有：**浏览器**，一个在浏览器上运行的**应用程序**以及一个**授权服务器**。当一个用户想要登录的时候，应用程序向授权服务器发送一个授权请求。授权服务器检测用户的证书，如果检测通过，授权服务器就会给应用程序颁发一个 ID 令牌。 |
There was a problem hiding this comment.
Suggested change
| 在这里我们涉及到的实体有：**浏览器**，一个在浏览器上运行的**应用程序**以及一个**授权服务器**。当一个用户想要登录的时候，应用程序向授权服务器发送一个授权请求。授权服务器检测用户的证书，如果检测通过，授权服务器就会给应用程序颁发一个 ID 令牌。 | |
| 在这里我们涉及到的实体有：**浏览器**，一个在浏览器上运行的**应用程序**以及一个**授权服务器**。当一个用户想要登录的时候，应用程序向授权服务器发送一个授权请求。授权服务器检测用户的凭证，如果验证通过，授权服务器就会给应用程序颁发一个 ID 令牌。 |
|
|
||
| We talked a bit about access tokens earlier, back when we were looking at how delegated access works with [OAuth 2.0 and authorization servers](#authorization-server). Let's look at some of the **details** of how that works, going back to our scenario with HireMe123 and MyCalApp. | ||
| 我们之前谈论过一点访问令牌，在那时我们主要看[ OAuth 2.0和授权服务器](#authorization-server)是如何授权访问工作的。让我们看看它们工作的**细节**，回到我们 HireMe123 和 MyCalApp 的场景中。 |
There was a problem hiding this comment.
Suggested change
| 我们之前谈论过一点访问令牌，在那时我们主要看[ OAuth 2.0和授权服务器](#authorization-server)是如何授权访问工作的。让我们看看它们工作的**细节**，回到我们 HireMe123 和 MyCalApp 的场景中。 | |
| 我们之前谈论过一点访问令牌，在那时我们主要看[ OAuth 2.0 和授权服务器](#authorization-server)是如何授权访问工作的。让我们看看它们工作的**细节**，回到我们 HireMe123 和 MyCalApp 的场景中。 |
|
|
||
| Access tokens are for the **resource API** and it is important that they are **opaque to the client.** Why? | ||
| 访问令牌主要用于**资源 API** 的调用，这时**客户端难以理解访问令牌**这一点就很重要。为什么？ |
There was a problem hiding this comment.
Suggested change
| 访问令牌主要用于**资源 API** 的调用，这时**客户端难以理解访问令牌**这一点就很重要。为什么？ | |
| 访问令牌主要用于**资源 API** 的调用，重要的是它们对客户端是不透明的。为什么？ |
|
@PassionPenguin @stuchilde 感谢两位老师的校对~ |
lsvih
reviewed
Mar 1, 2021
|
|
||
| * `sub` **(subject)**: unique identifier for the user; required | ||
| * `sub` **(主题)**: 用户的独特标识符；必填 |
There was a problem hiding this comment.
Suggested change
| * `sub` **(主题)**: 用户的独特标识符；必填 | |
| * `sub` **（主题）**：用户的独特标识符；必填 |
|
|
||
| **Access tokens** are used for **granting access to resources**. With an access token issued by MyCalApp's authorization server, HireMe123 can access MyCalApp's API. | ||
| **访问令牌**用于**许可对某资源的访问**。用一个 MyCalApp 的授权服务器发行的访问令牌， HireMe123 就可以访问 MyCalApp 的 API。 |
There was a problem hiding this comment.
Suggested change
| **访问令牌**用于**许可对某资源的访问**。用一个 MyCalApp 的授权服务器发行的访问令牌， HireMe123 就可以访问 MyCalApp 的 API。 | |
| **访问令牌**用于**许可对某资源的访问**。用一个 MyCalApp 的授权服务器发行的访问令牌，HireMe123 就可以访问 MyCalApp 的 API。 |
|
|
||
| ``` | ||
| # HTTP request headers | ||
| Authorization: 'Bearer eyj[...]' | ||
|
|
||
| ``` | ||
|
|
||
| The authorized request is then sent to the API, which verifies the token using middleware. If everything checks out, then the API returns data (e.g., JSON) to the application running in the browser. | ||
| 这一授权过的请求之后发给 API ，在 API 中使用第三方中间件来验证令牌。如果验证通过，API 就返回数据给浏览器中的应用程序。 |
There was a problem hiding this comment.
Suggested change
| 这一授权过的请求之后发给 API ，在 API 中使用第三方中间件来验证令牌。如果验证通过，API 就返回数据给浏览器中的应用程序。 | |
| 这一授权过的请求之后发给 API，在 API 中使用第三方中间件来验证令牌。如果验证通过，API 就返回数据给浏览器中的应用程序。 |
|
|
||
| I'm using the HireMe123 app and HireMe123 wants to access the third party MyCalApp API to create events on my behalf. HireMe123 has already requested an **access token** for MyCalApp from MyCalApp's authorization server. This token has some important information in it, such as: | ||
| 我正在使用 HireMe123 并且 HireMe123 想要访问第三方程序 MyCalApp 的 API 来代表我创建一个事件。 HireMe123 已经向 MyCalApp 从授权服务器请求了访问令牌**访问令牌**。这个令牌中包含有一些重要信息，比如： |
There was a problem hiding this comment.
Suggested change
| 我正在使用 HireMe123 并且 HireMe123 想要访问第三方程序 MyCalApp 的 API 来代表我创建一个事件。 HireMe123 已经向 MyCalApp 从授权服务器请求了访问令牌**访问令牌**。这个令牌中包含有一些重要信息，比如： | |
| 我正在使用 HireMe123 并且 HireMe123 想要访问第三方程序 MyCalApp 的 API 来代表我创建一个事件。HireMe123 已经向 MyCalApp 从授权服务器请求了访问令牌**访问令牌**。这个令牌中包含有一些重要信息，比如： |
|
|
||
| But MyCalApp hosts calendar accounts for **hundreds of thousands of users**. In addition to looking at the `scope` in the token, MyCalApp's API middleware needs to check the `sub` subject identifier to make sure this request from HireMe123 is only able to exercise **my** privileges to create events with **my** MyCalApp account. | ||
| 但是 MyCalApp 为**成百上千的用户**管理日历事件。除了查看令牌中的 `scope` ， MyCalApp 的 API 还需要检查 `sub` 字段标识符来确定这个来自 HireMe123 的请求仅仅能够使用**我**已有的权限来在**我的**账户上创建事件。 |
There was a problem hiding this comment.
Suggested change
| 但是 MyCalApp 为**成百上千的用户**管理日历事件。除了查看令牌中的 `scope` ， MyCalApp 的 API 还需要检查 `sub` 字段标识符来确定这个来自 HireMe123 的请求仅仅能够使用**我**已有的权限来在**我的**账户上创建事件。 | |
| 但是 MyCalApp 为**成百上千的用户**管理日历事件。除了查看令牌中的 `scope` ，MyCalApp 的 API 还需要检查 `sub` 字段标识符来确定这个来自 HireMe123 的请求仅仅能够使用**我**已有的权限来在**我的**账户上创建事件。 |
| * `aud` **(audience)**: the intended recipient of the JWT; for ID tokens, this must be the client ID of the application receiving the token | ||
| * `exp` **(expiration time)**: expiration time; the ID token must not be accepted after this time | ||
| * `iat` **(issued at time)**: time at which the ID token was issued | ||
| * `iss` **(发行人)**: JWT 的发行者, 例如授权访问服务器。 |
There was a problem hiding this comment.
Suggested change
| * `iss` **(发行人)**: JWT 的发行者, 例如授权访问服务器。 | |
| * `iss` **（发行人）**：JWT 的发行者，例如授权访问服务器。 |
|
|
||
| This is called the **confused deputy problem**. HireMe123 doesn't know **where** this token came from or **who** it was issued for. If we recall: **authentication is about verifying the user is who they say they are**. HireMe123 can't know this from the fact that it can use this access token to access an API. | ||
| 这种问题叫做**困惑的副手问题（ Confused Deputy Problem ）**。HireMe123 不知道这个令牌来自何处或者是这个令牌曾经发行给谁。如果我们还记得一开始的定义：**身份认证是关于确认这个用户是否是他自称的身份**，那么 HireMe123 无法从利用该访问令牌访问 API 的过程中得到这种信息。 |
There was a problem hiding this comment.
Suggested change
| 这种问题叫做**困惑的副手问题（ Confused Deputy Problem ）**。HireMe123 不知道这个令牌来自何处或者是这个令牌曾经发行给谁。如果我们还记得一开始的定义：**身份认证是关于确认这个用户是否是他自称的身份**，那么 HireMe123 无法从利用该访问令牌访问 API 的过程中得到这种信息。 | |
| 这种问题叫做**困惑的副手问题（Confused Deputy Problem）**。HireMe123 不知道这个令牌来自何处或者是这个令牌曾经发行给谁。如果我们还记得一开始的定义：**身份认证是关于确认这个用户是否是他自称的身份**，那么 HireMe123 无法从利用该访问令牌访问 API 的过程中得到这种信息。 |
|
|
||
| **Nothing insidious is happening now!** **MyCalApp is asking the user to log in with MyCalApp**. HireMe123 is **not** asking for the user's MyCalApp credentials. The issues with sharing credentials and too much access are no longer a problem. | ||
| **此处没有什么不可告人的事情发生！** **MyCalApp 正在要求用户登录 MyCalApp** 。HireMe123 并**没有**请求用户的 MyCalApp 证书。共享证书和过多访问权限再也不是问题了。 |
There was a problem hiding this comment.
Suggested change
| **此处没有什么不可告人的事情发生！** **MyCalApp 正在要求用户登录 MyCalApp** 。HireMe123 并**没有**请求用户的 MyCalApp 证书。共享证书和过多访问权限再也不是问题了。 | |
| **此处没有什么不可告人的事情发生！** **MyCalApp 正在要求用户登录 MyCalApp**。HireMe123 并**没有**请求用户的 MyCalApp 证书。共享证书和过多访问权限再也不是问题了。 |
Suggested change
| **此处没有什么不可告人的事情发生！** **MyCalApp 正在要求用户登录 MyCalApp** 。HireMe123 并**没有**请求用户的 MyCalApp 证书。共享证书和过多访问权限再也不是问题了。 | |
| **此处没有什么不可告人的事情发生！** **MyCalApp 正在要求用户登录 MyCalApp** 。HireMe123 并**没有**请求用户的 MyCalApp 证书。共享证书和过多访问权限再也不是问题了。 |
|
|
||
| [](https://res.cloudinary.com/practicaldev/image/fetch/s--aZl2UGDl--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_66%2Cw_880/https://kmaida.io/static/devto/authz-authn/before-oauth.gif) | ||
|
|
||
| Let's say you used an app called HireMe123. HireMe123 wants to set up a calendar event (such as an interview appointment) on your (the user's) behalf. HireMe123 doesn't have its own calendar; it wants to use another service called MyCalApp to add events. | ||
| 好比说你正在使用一个叫做 HireMe123 的应用程序。 HireMe123 想代表你设定一个日历事件（例如面试约会）。但是 HireMe123 没有自己的日历，所以它要使用另一个叫做 MyCalApp 的服务去添加日历事件。 |
There was a problem hiding this comment.
Suggested change
| 好比说你正在使用一个叫做 HireMe123 的应用程序。 HireMe123 想代表你设定一个日历事件（例如面试约会）。但是 HireMe123 没有自己的日历，所以它要使用另一个叫做 MyCalApp 的服务去添加日历事件。 | |
| 好比说你正在使用一个叫做 HireMe123 的应用程序。HireMe123 想代表你设定一个日历事件（例如面试约会）。但是 HireMe123 没有自己的日历，所以它要使用另一个叫做 MyCalApp 的服务去添加日历事件。 |
|
|
||
| There are many different standards and organizations that govern how things work on the internet. Two bodies that are of **particular interest to us in the context of authentication and authorization** are the Internet Engineering Task Force (IETF) and the OpenID Foundation (OIDF). | ||
| 有许多不同的标准和组织来管理互联网上的工作方式。在讨论身份认证和授权访问的时候，有两个组织是我们**尤其感兴趣的**，它们分别是互联网工程任务组 (IETF) 和 OpenID 基金会 (OIDF)。 |
There was a problem hiding this comment.
Suggested change
| 有许多不同的标准和组织来管理互联网上的工作方式。在讨论身份认证和授权访问的时候，有两个组织是我们**尤其感兴趣的**，它们分别是互联网工程任务组 (IETF) 和 OpenID 基金会 (OIDF)。 | |
| 有许多不同的标准和组织来管理互联网上的工作方式。在讨论身份认证和授权访问的时候，有两个组织是我们**尤其感兴趣的**，它们分别是互联网工程任务组（IETF）和 OpenID 基金会（OIDF）。 |
|
@Ashira97 您好，还有一点格式上的问题得麻烦您过一下哈 |
|
@lsvih 好的 抱歉 我在改一下~ |
|
@PassionPenguin @stuchilde 感谢两位老师的校对 格式错误太多 让二位老师费心了 |
|
我稍晚点看哈 |
|
@Ashira97 已经 merge 啦~ 快快麻溜发布到掘金然后给我发下链接，方便及时添加积分哟。 掘金翻译计划有自己的知乎专栏，你也可以投稿哈，推荐使用一个好用的插件。 |
|
收到 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
译文翻译完成，请各位大佬校对~ resolve #7918