1.What is the difference between authentication and authorization?

身份验证是服务器检查用户是否确实是它声称的用户的过程。这通常在用户提供用户名和密码时完成，而当第一个用户创建其帐户时，服务器将这些凭据（用户名、密码）与存储在其数据库中的凭据进行检查。 授权是指一个实体授予另一个实体执行某项操作的权限。例如，在这种情况下，当网站想要访问用户的数据时，这些数据存储和拥有在不同的网站中。

2.What is OAuth2 meant to do?

官方上，OAuth2授权用户在通过认证服务器网站AS认证后允许客户端网站C从资源服务器网站RS访问他/她的数据。这看起来很复杂，所以为了简化，一个常见的例子是用户使用他/她的 facebook 帐户登录网站。在这种情况下，客户端网站和资源服务器网站是相同的（C=RS=访问的网站），认证服务器是facebook（AS=facebook）。请注意，这是创建的，因此 C,RS 不会学习用户的密码，同时能够对他/她进行身份验证。

3.Why is OAuth2 implicit flow insecure for authentication while still secure for authorization?

隐式流程的特殊性在于，访问令牌被提供给用户代理以转发给应用程序。因此，它完全基于重定向 URI。因此，此流程不会验证应用程序的身份，因为没有客户端机密机密性（访问令牌暴露给用户和在移动设备中运行的应用程序）

4.What is the difference between OAuth2 implicit flow and Oauth2 authentication code flow and when to use which?

如前所述，在隐式流程中，访问令牌由用户代理转发给应用程序。另一方面，在授权代码流中，客户端 Web 服务器首先获取一个授权代码（在资源所有者/用户授予访问权限之后），然后使用授权代码调用 API 传递 (clientID,secretID) 以获取访问令牌。这样做是为了在 HTTP 连接（无 SSL 加密）的情况下，中间人（路由器、代理等）无法访问访问令牌。所以，第一个适用于移动应用，而后一个适用于服务器端应用。

5.Does OAuth2 authentication code flow work for authentication?

是的，授权代码流还通过身份验证服务器对用户进行身份验证。

6.Should you use OpenID instead of OAuth2 for authentication?

是的。

OpenID用于身份验证。例如，当我们希望用户能够使用一组凭据（signle-sign on）登录多个网站时。

如前所述， OAuth用于授权。请注意，可以稍微调整 OAuth（如前面的示例，其中 C=RS），以便通过授权执行（伪）身份验证。但是，如果我们只想进行身份验证，我们可以使用 OpenID。

7.Why is google saying that their "OAuth2" framework can be used for both authentication and authorization.

我想这个设计决定背后的真正原因只能由相应的谷歌工程师给出，但我可以假设他们没有同时使用 OpenID 和 OAuth，而是选择对两种用法使用单一协议，以简化事情。但是，请注意，通过 OAuth 的身份验证是通过对某人进行身份验证，通过他/她拥有的数据来完成的。一个乏味的例子是，当我试图进入我的工作大楼时，没有人问我我的证件，因为我的员工卡显然在我的脖子上。这就是通过 OAuth 进行身份验证的方式，非常简化。因此，您可以看到，这可以做出一些假设，这些假设并不总是在每种情况下都成立。而这也是一般推荐使用 OAuth 只做授权，使用 OpenID 的原因，

一个很好的链接，描述了 OAuth 的各种流程以供参考

@RaptisDimos 给出了一个很好的答案，但我想我会花在第 3 点上。

3. 为什么 OAuth2 隐式流对身份验证不安全，但对授权仍然安全？

当您尝试将其用于身份验证时，隐式流程的问题在于客户端直接接收访问令牌，并且该访问令牌未绑定到任何特定客户端。这意味着客户端不知道这个令牌是给他还是其他应用程序。

然后使用此令牌访问所有者数据。当您想要“验证”所有者时，您通常会从他的数据中提取他的电子邮件，然后在您的应用程序（客户端）中验证他。但是，您不知道是谁将该访问令牌传递给您的客户。是真正的所有者还是托管其他服务的攻击者？

攻击示例

• Client_Good ：使用 google API 使用隐式流验证其用户的良好客户端
• Client_Bad : 使用 google API 攻击 Client_Good 的恶意客户端

Client_Bad 可以是任何服务。例如，一个网络应用程序可以让你在你的谷歌驱动器中上传图片。为了完成该任务，Client_Bad 需要来自 Google 的访问令牌。所以它会要求你给他一个。然后，您将能够使用其服务上传您的图片。

您不知道的是，您刚刚为上传图片而提供给 Client_Bad 的访问令牌也是一个有效的访问令牌，可以与 Client_Good 一起使用来验证自己的身份。现在，Client_Bad 的所有者可以在 Client_Good 中冒充您。如果 Client_Good 是一项关键服务，那么您可能会遇到严重的问题。

那为什么授权是安全的呢？

这是安全的，因为如果您授权 Client_Bad 代表您上传图片，那么无论他是直接上传还是通过其他服务来上传都没有关系。

例如，可能有第三个客户端 Client_Picture，它也只是将图片上传到您的谷歌驱动器。当您要求 Client_Bad 上传您的内容时，Client_Bad 可以将该任务委托给 Client_Picture，您不会在意，因为它达到了相同的结果。

好吧，事实上，现在大量的第 3 方可以访问您的数据，但同样，您同意 Client_Bad 可以在您提供此访问令牌时为所欲为。这就像将您的汽车钥匙传递给您的邻居一样。你给了别人使用那辆车的权利，他可能会把它借给另一个邻居一段时间，然后把它还给你。问题是您不知道，并且在您授予控制权时“同意”了这一点。

注意：有时我想知道是否没有人理解解释或者我说错了什么......无论如何，它在 OAuth2 规范的第10.16节中进行了解释，换句话说，如果有帮助的话。